And the addon API doesn't even have that direct of a relationship to Broccoli, in the same way that the Ember component lifecycle makes sense even if it wasn't generating DOM at the end.
Some sort of build-time DI would be necessary (so that importing from "services/fetch" would be able to be swapped out if needed), but then we could end up with something like:
-
-
import Fetch from "app/services/fetch"; import { service } from "@ember/injections"; export default class {
@service(Fetch) fetch; handle() { this.fetch // an instance of fetch } } -
Note that an import *roughly* like this is already necessary for
@typescriptlang to have enough info to be usable for services today (`@service fetch!: Fetch;`) so rationalizing DI in something like this way would be
from where I stand. -
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.
-
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
- 8 more replies
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.