Application State - #2237
Application State#2237NullVoxPopuli wants to merge 1 commit into
Conversation
✅ Deploy Preview for ember-guides ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
54c5aa1 to
3a49063
Compare
There was a problem hiding this comment.
I'm sad this doesn't show up as a mv :(
b1826a9 to
6c4596f
Compare
|
|
||
| Ember gives you two ways to tie state to the owner: a plain class, described on this page, and a [Service](../services/). | ||
| Prefer the plain class because plain classes will participate in the import graph and naturally fit in to automatic bundle splitting (unlike services). | ||
| Use a Service only for the small, minimally required, set of state that the application needs to boot. |
There was a problem hiding this comment.
Thanks for the read (again). This section is very interesting to me – As long time ember user, I have never considered plain es module class state as a good alternative to Services (except for a few cases of caches I use). This also begs the question for me in this read: Why should I not replace all services with plain classes?
What is special about services that makes them better fit for "the state that the application needs to boot.", than plain classes? (Isn't there a way to make es class es available on app boot?).
There was a problem hiding this comment.
why should I not replace all services with plain classes
if they are not needed for boot, I argue you absolutely should use plain classes. The closer we get to vanilla javascript the better, and more at-home developers will feel.
What is special about services that makes them better fit for "the state that the application needs to boot.", than plain classes? (Isn't there a way to make es class es available on app boot?).
if your vanilla class adheres to the same static api interface, you don't need to use Service from @ember/service at all, your intuition is correct here. (all you need is a static create function).
So in that regard, there is almost an argument for ditching Service entirely -- however the convenience of the interface abstraction is nice.
I drew the line at "minimally required state", such as the router service, because:
- existing convention (we don't really have a convention for application state outside of this)
- libraries may want to access the service, and given the worries brought up in the explicit service injection RFC, I think we can just teach to use the "string-service" system if someone can't get a hold of their dependency graph, or if they truely have no way to get a hold of a static reference (that isn't a string)
There was a problem hiding this comment.
thanks for the explanation. makes sense. I like that it shows a future of simple vanilla javascript, where Ember is not shy to get out of the way and embraces the platform.
There are some teaching downsides in explaining two concepts for application state, though – at least at the same level. The proposed text for the class based approach jumps straight into Owner, singleton, (and WeakMap), which may quite a steep learning curve?
We should maybe also run the thought: How should plain class state be taught when / if Service ever become more plain (i.e. keep most of the ergonimics, but get the benefits of cutting the cord of string based DI, etc.)
2 participants
This is necessarily entangled with
NOTE: these things make dealing with state easier than ember's docs currently describe (and remove some boilerplate in this PR):
linkfrom@ember/lifetimeto remove the boilerplate of setOwner + associateDestroyableChild emberjs/rfcs#1067@servicedecorator to give us the behavior from the below-linked codeI can, ofc, pursue shipping the RFCs above, but I would like more engagement from the core teams, and the RFCs will ofc need to be accepted