Even languages that have always had static module imports still reinvent dependency injection too. They are for different things.
-
-
Replying to @eaf4 @15lettermax and
I think part of that is because most languages don't have the shared runtime state thing that ES modules do? ES modules and CommonJS both seem to encourage sharing state through a module
2 replies 0 retweets 0 likes -
What's an example of sharing state through a module?
2 replies 0 retweets 0 likes -
Replying to @amatchneer @eaf4 and
If two modules import the same module, they get the same copy, which they can use as a location for shared state. I saw this used a lot in Node to solve similar problems to DI
2 replies 0 retweets 0 likes -
Replying to @nucknyan @amatchneer and
As an example, you might have a module which stores the database connection for your app, and then you just import connection from './db' and always get the same one
1 reply 0 retweets 0 likes -
Replying to @nucknyan @amatchneer and
It's a lot like ember services, honestly
2 replies 0 retweets 0 likes -
Replying to @nucknyan @amatchneer and
And it is classical Singleton ... from backend dev perspective I find Ember services totally OK .. and See
@chriskrycho reply - it has nice integration with TypeScript add-on.@wycats please, don't tear down the DI :)2 replies 0 retweets 1 like -
This discussion highlights the high levels of empathy needed in our community. To ppl who have worked in many frameworks and languages, features like our DI are obvious wins. To ppl who are getting started, they are extra learning steps. Both perspectives need to be represented.
2 replies 0 retweets 1 like -
Yea, seems like this must have gotten clouded. Definitely not talking about removing DI at all, only recommending that the DI process involve importing the service rather than `foo: service()` just magically working. `foo: service(Foo)` would be more explicit and TS-friendly
2 replies 0 retweets 2 likes -
Replying to @15lettermax @SDen9 and
As long as you’re describing the import of the *interface* and not assuming it’s also always the *implementation*, this seems good.
1 reply 0 retweets 1 like
Or you could use build-time DI to change the meaning of the import, but that has serious tooling issues. I think this aspect (imports are always talking about a single concrete impl) is underappreciated, and figures into Ember's much-praised testing story.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.