Add a section for using vanilla classes with dependency injection #1974
Conversation
✅ Deploy Preview for ember-guides ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Thanks for writing these docs! ❤️ |
Co-authored-by: Lukas Nys <nyslukas@gmail.com>
Co-authored-by: Lukas Nys <nyslukas@gmail.com>
Co-authored-by: Lukas Nys <nyslukas@gmail.com>
Co-authored-by: Lukas Nys <nyslukas@gmail.com>
Co-authored-by: Lukas Nys <nyslukas@gmail.com>
Co-authored-by: Lukas Nys <nyslukas@gmail.com>
Co-authored-by: Lukas Nys <nyslukas@gmail.com>
|
|
||
| #### With arguments | ||
|
|
||
| If your native class needs arguments, we can change the above example to instantiate the class like this: |
There was a problem hiding this comment.
From here down seems like useful content, but maybe unrelated to services. Not sure where else it could go. Do we have a cookbook section?
There was a problem hiding this comment.
yeah, it's more related with "how to in general work with native classes in general reactive systems" -- which we don't have a section for about reactivity patterns, derived data, or anything like that.
there was a whole cookbook project, rfc and such, I don't have context as to where that's at tho
Co-authored-by: Krystan HuffMenne <kmenne+github@gmail.com>
Co-authored-by: Krystan HuffMenne <kmenne+github@gmail.com>
Co-authored-by: Lukas Nys <nyslukas@gmail.com>
Co-authored-by: Lukas Nys <nyslukas@gmail.com>
|
|
||
| export class VanillaClass { | ||
| @service shoppingCart; | ||
|
|
There was a problem hiding this comment.
If the class is going to use a service, it really should have the owner passed in to the constructor and do the setOwner in the constructor like glimmer components imo
There was a problem hiding this comment.
I don't really agree :-\
if the responsibility of setting up the owner is always in the constructor then it's impossible to abstract reasonably, as one might to do here: https://ember-resources.pages.dev/funcs/link.link
| ``` | ||
|
|
||
| With this technique, the tracked data provided by `this.arg.foo` is lazily evaluated in `VanillaClass`, allowing the `VanillaClass` to participate in lazy evaluation and auto-tracking like every where else you may be used to in an app. | ||
|
|
There was a problem hiding this comment.
I don’t love these suggestions here. These are the problems I was bringing up in the spec channel in discord the other day. We can discuss more in the meeting today
There was a problem hiding this comment.
we only have two ways to pass reactive data (in js) without consuming it:
- wrapper class/object/whatever (with getters)
- arrow function
curious what solutions you think there may be
I noticed this was missing, and it's hugely important and powerful.
(and our discord api bot didn't find anything useful when I asked, here: https://discord.com/channels/480462759797063690/1157084708442755102/1169635166390587493 )
As I was writing this though, I was realizing that the guides need a whole section on managing reactivity, how to think about lazy evaluation in an auto-tracked world, etc.
I've started brainstorming topics over here: NullVoxPopuli/website#117
and I'll more than likely write something over on my blog before writing something for the guides -- but it's just a big gap I noticed as I was trying to explain concepts in this PR.
If I missed something please lemme know!
Related content that I can never find through search: #1715