Dependency Injection
Answered
Spectacled bear posted this in #help-forum
Spectacled bearOP
Hey everyone, new to Next here, coming from a Golang background, I'm just wondering how to make server components decoupled. I see majority of the time, people use global database clients and just import them into the file then use directly in the component, but I find this hard to maintain, so I'm wondering if there is way to inject dependencies into components on the server.
Answered by Asian black bear
Yeah no, when working with React, particularly Next, the artificial line between frontend and backend becomes blurry. Oldschool testing approaches to force unit and integration tests are pretty detrimental and of no value. Typically you'd go for E2E testing to cover entire user journeys to test realistic scenarios instead of plugging mocked services into one another.
14 Replies
Asian black bear
React isn't designed like Angular for example. DI isn't a common pattern and it's not really a problem.
Spectacled bearOP
Yeah I thought so, is there atleast a way to pull from a global container that changes based on environment variables or what not?
Asian black bear
There surely are packages for this, but it's probably not as ergonomic and I personally didn't have any use cases in the past years working on huge software that would have benefited from it. If you describe a real scenario where you think you'd make use of DI it might be possible that somebody can tell you how to approach it more idiomatically.
Spectacled bearOP
I'm just a big DDD fanboy. But specifically for testing/maintainability reasons.
Asian black bear
Yeah no, when working with React, particularly Next, the artificial line between frontend and backend becomes blurry. Oldschool testing approaches to force unit and integration tests are pretty detrimental and of no value. Typically you'd go for E2E testing to cover entire user journeys to test realistic scenarios instead of plugging mocked services into one another.
Answer
Asian black bear
And testing for instance against a database on a test server becomes a task of "replace the env var that holds the database connection string" instead of attempting to inject a separate test-only implementation of the repository/services.
Any attempt of you for example to introduce a container (say via a global context) will make things arguably less maintainable and can even be detrimental to the performance of the app itself.
Keeping the dependencies local rather than grabbing them from high up the component tree is easier to maintain as it's obvious where things are coming from.
This is particularly noticeable when working with server components when combining them with request memoization.
Spectacled bearOP
I would imagine that this most likely is the case. I still would feel more comfortable with a global Repository than a specific ORM's database connection.
But yes, I understand thank you.
Asian black bear
If you feel more comfortable with such a conventional architecture then you should in all seriousness check out Angular.
It uses the very classic approach of DI via constructor injection that is commonly used in Spring for example.
Spectacled bearOP
Yes, I am aware, I don't like the extreme opionations however. But its all well, I can make do for the most part.