Wow! I didn't see that before! It's actually an interesting way to use TypeScript in a useful way that doesn't feel mandatory (or maybe even require runtime glue from TS) but also doesn't impose extra costs on TS users.
-
-
Replying to @wycats @chriskrycho and
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
1 reply 0 retweets 3 likes -
Replying to @15lettermax @wycats and
Even languages that have always had static module imports still reinvent dependency injection too. They are for different things.
1 reply 0 retweets 4 likes -
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
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.
1 reply 0 retweets 2 likes -
Replying to @wycats @amatchneer and
Couldn't you stub imports with a custom module resolver?
1 reply 0 retweets 0 likes
One major difference is that modules aren't allowed to change once they are resolved, so there's no good way to reset app state without also flushing code. It's somewhat fundamental since modules are allowed to cache stuff off of their imports.
-
-
import() or Even if you wanted to be daring and build on _the platform_ if (hot.module.accepts("./base_module")) { // HMR to reset the state of the module without reloading page or affecting alt state. }
1 reply 0 retweets 0 likes -
Replying to @TheLarkInn @wycats and
Would those options be viable? I don't know why I've never thought about HMR as a testing capability for DI but given it's fn'al and patching behavior to avoid resetting all state this feels like it's kinda feasible.
1 reply 0 retweets 1 like - 1 more reply
New conversation -
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.