… And this results in a weak ecosystem because I can't borrow tools directly from other ecosystems, just ideas. And ideas are frankly near-worthless when I'm trying to build a product quickly
-
-
This also seems preferable independent of TS because explicit imports are the direction JavaScript itself is moving (has moved). You have to type a bit more, and it's less magic, but IMO sticking to the emerging language patterns is worth the extra typing
-
Even languages that have always had static module imports still reinvent dependency injection too. They are for different things.
-
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
-
What's an example of sharing state through a module?
-
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
-
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
-
It's a lot like ember services, honestly
-
But storing the state in a module makes swapping it out for testing harder (and even has consequences for FastBoot, which resets the state between instances without having to reload all the code). We should make it closer to normal imports but still a class imo.
- 5 more replies
New conversation -
-
-
@davewasmer your input might be useful here
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.
from where I stand.