From the perspective of quickly shipping your product, what would you say are the biggest things from Webpack missing in Ember that are slowing you down?
-
-
I totally get the frustration of wanting to do something in your app and feeling held back by your tools.
1 reply 0 retweets 2 likes -
Emma the problem is that for Ember to go full webpack the "right way" they need to use modules top down, which is (last I worked with the cli team and ember team) is a pretty tough feat. Glimmer is promises of the future however. Just know we actively want to have webpack+ember
1 reply 0 retweets 1 like -
Replying to @TheLarkInn @wycats and
Ember makes a very valuable yet discrete tradeoff: Compat at the cost of being held back a little, but with a much more stable moving ecosystem.
1 reply 1 retweet 3 likes -
Replying to @TheLarkInn @wycats and
Dependency Injection would need (or should in my subjective opinion) be repalced with ESM, and that's a whole archetectural rewrite almost.
3 replies 0 retweets 2 likes -
Replying to @TheLarkInn @nucknyan and
Some cases of DI might want to be rewritten as pure modules, but DI *state* would still want to be separately managed. Also, cases where you use DI to swap out different versions of a service wouldn't necessarily be able to reference a module name directly.
1 reply 0 retweets 0 likes -
Replying to @wycats @TheLarkInn and
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:
1 reply 0 retweets 0 likes -
Replying to @wycats @TheLarkInn and
import Fetch from "app/services/fetch"; import { service } from "@ember/injections"; export default class {
@service(Fetch) fetch; handle() { this.fetch // an instance of fetch } }3 replies 0 retweets 2 likes -
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>
1 reply 0 retweets 0 likes -
Replying to @TheLarkInn @wycats and
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.
1 reply 0 retweets 1 like
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.
0 replies 0 retweets 0 likesThanks. 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.