Add deprecation guides for observers #1407
Conversation
❌ Deploy Preview for ember-deprecations failed.
|
|
Looks like .hbs code blocks aren't allowed. Is this intentional? |
|
|
||
| In contrast, if a computed property is defined with its own setter, you **can** use a native JavaScript assignment to update it. Ember will correctly intercept this and run your setter logic. | ||
|
|
||
| ```javascript |
There was a problem hiding this comment.
should these examples also have the modern native class equiv? this would help AI scanning later as we want to get rid of EmberObject
|
|
||
| Then, use this modifier in your Glimmer component's template: | ||
|
|
||
| ```hbs |
| To trigger reactivity (like re-computing a dependent computed property) when changing a plain property, you **must** use the `set` function. A native JavaScript assignment (`person.firstName = 'Jane'`) will change the value but will **not** trigger reactivity. | ||
|
|
||
| ```javascript | ||
| import { computed, set } from '@ember/object'; |
There was a problem hiding this comment.
I think instead of telling people to use set we should tell people to handle this case by refactoring their @computed away.
There was a problem hiding this comment.
Yeah, that's a good call
There was a problem hiding this comment.
Depending on where folks are with their migration, it could be good to have both -- the migration we have here -- but also how we would do it today using @tracked.
We could even use <details> to allow people to choose their own adventure (and not overwhelm them with a skyscraper of code blocks)
| set fullName(value) { | ||
| const [firstName, lastName] = value.split(' '); | ||
| // Note: `set` is still used inside the setter itself | ||
| set(this, 'firstName', firstName); |
There was a problem hiding this comment.
set is not imported 🙈
| since: 6.5.0 | ||
| --- | ||
|
|
||
| The `addObserver` and `removeObserver` methods from `@ember/object/observers` are deprecated. Instead of using observers, you should use tracked properties and native getters/setters. |
There was a problem hiding this comment.
we need another use case for before/after:
- ember-concurrency's
waitForuses observers
and whatever these do:
- ember-animated
- ember-data
- ember-power-select
There was a problem hiding this comment.
waitFor can be implemented via a rAF loop
|
We discussed that this is another place where it's probably important to expose well-curated and suitably-low-level-looking API for doing integrations with the auto tracking system that are not just our own DOM renderer. That would enable cases like the ember-concurrency example to do efficient integration without polling, rAF etc. |
RFC: emberjs/rfcs#1115