Reactivity: an early draft of *everything* we've learned since Octane #965
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Sergey Astapov <[email protected]>
Co-authored-by: Sergey Astapov <[email protected]>
|
|
||
| ## Summary | ||
|
|
||
| Leading up to the Octane Edition, we laid out a plan to get rid of `<object>.get` and `<object>.set` in favor of `@tracked` class properties, which paved the way for writing reactive code in a way that is _the most_ "just javascript" out of our framework peers at the time, |
There was a problem hiding this comment.
Suggested change
| Leading up to the Octane Edition, we laid out a plan to get rid of `<object>.get` and `<object>.set` in favor of `@tracked` class properties, which paved the way for writing reactive code in a way that is _the most_ "just javascript" out of our framework peers at the time, | |
| Leading up to the Octane Edition, we laid out a plan to get rid of `<object>.get` and `<object>.set` in favor of `@tracked` class properties, which paved the way for writing reactive code in a way that is _the most_ "just javascript" out of our framework peers at the time. |
|
|
||
| ## Motivation | ||
|
|
||
| The ember ecosystem has a number of "third-party" abstractions for some core reactive primitives, that could benefit (from teaching, performance, and cohesion perspectives) from being pulled in to a cohesive set of utilities from one source. This will help with longer-term goals of [simplifying imports](https://github.com/emberjs/rfcs/pull/946) -- today we have a _pit of exhaustion_ when it comes to how many imports are needed to make components. |
There was a problem hiding this comment.
Suggested change
| The ember ecosystem has a number of "third-party" abstractions for some core reactive primitives, that could benefit (from teaching, performance, and cohesion perspectives) from being pulled in to a cohesive set of utilities from one source. This will help with longer-term goals of [simplifying imports](https://github.com/emberjs/rfcs/pull/946) -- today we have a _pit of exhaustion_ when it comes to how many imports are needed to make components. | |
| The ember ecosystem has a number of "third-party" abstractions for some core reactive primitives, that could benefit (from teaching, performance, and cohesion perspectives) from being pulled into a cohesive set of utilities from one source. This will help with longer-term goals of [simplifying imports](https://github.com/emberjs/rfcs/pull/946) -- today we have a _pit of exhaustion_ when it comes to how many imports are needed to make components. |
| - define integration points | ||
| - manager pattern is fallback, rather than default | ||
|
|
||
| [starbeam]: https://www.starbeamjs.com/ |
There was a problem hiding this comment.
It's not a vital or really required change but, to keep things consistent, should this "link-reference"
- be moved into the section where it is first introduced? (just below,
### Preface) - at the bottom of the file?
|
|
||
| ### Preface | ||
|
|
||
| Before getting in to details of what **each thing is, how it works, and how we'll integrate and support it**, we need to go over some _equivalence_, because there is some overlap between [Starbeam][starbeam] and exports from `ember-modifier` and `ember-resources`. |
There was a problem hiding this comment.
Suggested change
| Before getting in to details of what **each thing is, how it works, and how we'll integrate and support it**, we need to go over some _equivalence_, because there is some overlap between [Starbeam][starbeam] and exports from `ember-modifier` and `ember-resources`. | |
| Before getting into details of what **each thing is, how it works, and how we'll integrate and support it**, we need to go over some _equivalence_, because there is some overlap between [Starbeam][starbeam] and exports from `ember-modifier` and `ember-resources`. |
| expect(num.current).toBe(0); | ||
| ``` | ||
|
|
||
| In `@glimmer/tracking`, `@tracked` can be thought of as a wrapper of `cell` |
There was a problem hiding this comment.
Suggested change
| In `@glimmer/tracking`, `@tracked` can be thought of as a wrapper of `cell` | |
| In `@glimmer/tracking`, `@tracked` can be thought of as a wrapper of `cell`. |
| } | ||
| } | ||
| ``` | ||
| which would be the exact same as what folks are used to today in Ember: |
There was a problem hiding this comment.
Suggested change
| which would be the exact same as what folks are used to today in Ember: | |
| which would be the exact same as what folks are used to today in Ember: | |
| } | ||
| ``` | ||
|
|
||
| Also note that originally, the cell API was motivated by and being a way to |
There was a problem hiding this comment.
?
Suggested change
| Also note that originally, the cell API was motivated by and being a way to | |
| Also note that originally, the cell API was motivated by being a way to |
Comment on lines
+314
to
+315
| In ember-modifier, a modifier is an arrow function registered with a _modifier manager_ | ||
| for each created modifier. |
There was a problem hiding this comment.
Looks redundant.
Suggested change
| In ember-modifier, a modifier is an arrow function registered with a _modifier manager_ | |
| for each created modifier. | |
| In ember-modifier, a modifier is an arrow function registered with a _modifier manager_. |
| }); | ||
| ``` | ||
|
|
||
| This is the _least_ typing of the options, and it make make sense to keep this API |
There was a problem hiding this comment.
Suggested change
| This is the _least_ typing of the options, and it make make sense to keep this API | |
| This is the _least_ typing of the options, and it makes sense to keep this API |
| - `TrackedWeakSet` | ||
| - etc? | ||
|
|
||
| Note: performance issues, incomplete implementation as ecma advances |
There was a problem hiding this comment.
For clarity.
Suggested change
| Note: performance issues, incomplete implementation as ecma advances | |
| Note: performance issues, incomplete implementation as ECMAScript advances |
6 tasks
NullVoxPopuli
commented
Mar 23, 2024
|
|
||
| We have an opportunity to improve a lot of performance in how ember renders by collapsing abstractions. | ||
|
|
||
| The "third-party" libraries are: |
There was a problem hiding this comment.
tracded-toolbox, too
There was a problem hiding this comment.
also, ember-async-data, and one of its utility classes is duplicated in ember-data
|
Superseded by #1122 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
wip, no looking, shhh
Rendered
What finally motivated me to get this going:
TODO:
propose primitives
(as separate imports as to not force the need for tree-shaking)
${}/local-copy${}/dedupe-tracked${}/tracked-reset${}/deep${}/map${}/weak-map${}/set${}/weak-set${}/object${}/array${}/async${}/resourcepropose flexibility