Yeah I won't fault the addon API at all. I love it, I just have gripes with the feeling that ember is constantly reinventing things that it seems (1) everybody else coalesced on a solution for and (2) nobody else can benefit from our reinvention
-
-
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
-
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
- 7 more replies
New conversation -
-
-
Ah okay yeah that's legit if they are both a module etc and if unused services somehow end up somewhere they could be removed. Also things to consider, supporting capability to lazily load a service when needed, so anywhere takes a service takes a ()=>Promise<Service>
-
It may not be the average case but it's the first class flexibility to modularize and break code up async that makes perf ez to refactor one line at a time.
-
I think it makes sense for services to be async under the hood, but once a component is loaded, it should have all services sync available (otherwise every component method would need to be async
) -
What if like, the methods not needed until some click event etc. Is it assumed "put it in another component?" Purely curious.
End of conversation
New conversation -
-
-
Love this!
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.