A new reactive primitive: Cell

[NullVoxPopuli]

Propose a new reactive primitive: Cell

Rendered

Summary

This pull request is proposing a new RFC.

To succeed, it will need to pass into the Exploring Stage, followed by the Accepted Stage.

A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.

An FCP is required before merging this PR to advance to Accepted.

Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.

Exploring Stage Description

This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.

An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an Exploring label applied.

An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.

Accepted Stage Description

To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.

If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.

When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.

Checklist to move to Exploring

• The team believes the concepts described in the RFC should be pursued.
• The label S-Proposed is removed from the PR and the label S-Exploring is added.
• The Ember team is willing to work on the proposal to get it to Accepted

Checklist to move to Accepted

• This PR has had the Final Comment Period label has been added to start the FCP
• The RFC is announced in #news-and-announcements in the Ember Discord.
• The RFC has complete prose, is well-specified and ready for implementation.
  • All sections of the RFC are filled out.
  • Any unanswered questions are outlined and expected to be answered before Ready for Release.
  • "How we teach this?" is sufficiently filled out.
• The RFC has a champion within one of the relevant teams.
• The RFC has consensus after the FCP period.

[NullVoxPopuli]

NOTE: related RFC, tracked-storage-primitive, in implementation here: emberjs/ember.js#20814

[josemarluedke]

I’d like to suggest that we consider alternative names for this feature, such as ref (as seen in frameworks like Vue) or signal (used in Preact, Angular, and others). These names are already familiar to many developers, especially those coming from different frameworks. Adopting such terminology could not only smooth the learning curve but also enhance the "searchability" of the feature in the future, making it easier to discover in documentation and discussions across the broader JavaScript ecosystem.

Aligning with these well-known terms could also foster greater consistency across frameworks, benefiting both new and experienced developers who are already familiar with these patterns.

I also think this feature is a great addition to Ember. As reactive state management becomes a standard in modern frameworks, it's exciting to see Ember adopt this approach, providing developers with more flexibility and a declarative way to build dynamic UIs.

[josemarluedke]

I’d also like to propose introducing a new package for this feature, following a similar approach to the one in RFC #1068. Specifically, we could create a package like @ember/reactive or @ember/reactivity to house this feature and any future reactive state management utilities.

By using a clear, scoped package like @ember/reactive, we can create a dedicated space for related functionality, making it easier to extend and maintain as the Ember ecosystem evolves. This would also allow for more modular imports, helping developers adopt the feature in a clean and consistent manner, such as:

import { ref } from '@ember/reactive';
// or
import { Cell } from '@ember/reactive';

Additionally, this package could pave the way for moving @glimmer/tracking into @ember/reactive in the future, providing a more unified approach to reactive programming within the Ember ecosystem. It would help maintain the modularity and organization of Ember's core features, ensuring that reactive state management tools are accessible in one place.

[NullVoxPopuli]

I like where your head's at!
I'm probably a fan of standardizing on new stuff going in @ember/reactive tbh.

As I've been looking to implement Cell in

• [ Pending RFC ] create Cell glimmerjs/glimmer-vm#1682

And a similar RFC in:

• RFC: 669, @glimmer/tracking/primitives/storage ember.js#20814

I've found that a lot of stuff has a chain-of-re-exports... which is a bit annoying to work with.

The underlying private packages from glimmer-vm export enough things where we could implement new APIs in ember -- but the tricky part is that if we want new default keywords, they need to go in the VM -- unless the VM provides a way to ember to add keywords (without build-time transforms, hopefully).

So, this is probably an organizational thing we just need to fix.
There has been talk of combining the repos -- but that's a giant task that someone probably just needs to do (and hopefully without losing the DX that @wycats has been working on in the VM lately).

But this organizational split is probably why the re-exports exist in the first place -- glimmer-vm needs access to things, but we want better (and public) import paths for our users.

I’d like to suggest that we consider alternative names for this feature, such as ref (as seen in frameworks like Vue)

I don't really agree with ref, because it's a very overloaded term outside of the vue ecosystem.

• short for "reference"
• when searching for "ref javascript", you decidedly get React results, and ref in react is an "element placeholder" (usually), but is also their concept for class properties.
  • ref javascript -react is the new search, and then you find out about "pass by reference", "referential integrity", etc (good stuff to learn if folks don't know already!)
• "pass by reference"?
  • a bonus here: all signal-based libraries are "reactive by reference", in that there is no deep reactivity unless an API explicitly creates deep tracking for each nested reference

or signal (used in Preact, Angular, and others).

Until the signals proposal lands, I'm personally wary of landing on the name "Signal". The proposal in TC39 isn't even sure it wants to stick with that name.
Additionally, in all the ecosystems using Signals, they all have wildly different APIs, so I think having a specific name for a specific shape of API would be beneficial as to not confuse with the other ecosystems -- since there is currently not alignment on how these things should work.

While the purpose of the Signals proposal is to unify the frameworks, within each ecosystem, developers are not meant to use signals directly, exactly, but to continue to use each of their ecosystem concepts and APIs. This makes Signals more of a low-level platform feature that app developers could use, and they would just work, but the benefits of using the ecosystem-specific APIs are far greater -- greater ergonomics, greater SEO, etc.

This is why Svelte has "Runes", and why some other reactive frameworks are continuing to use "stores" (or "refs" in vue's case).

For frameworks, Signals are an implementation detail rather than the user-facing API.

Aligning with these well-known terms could also foster greater consistency across frameworks, benefiting both new and experienced developers who are already familiar with these patterns.

This is what the TC39 Signals Proposal is for: once implemented, frameworks can / should change out their underlying primitives for the platform-based signals implementation. No app dev would have to change a single piece of their code, but they'd suddenly be able to use raw signals if they want, and things would just work.

The distinction is important, because already a Cell has more APIs than than a Signal.

As currently proposed at TC39, a Signal instance (for app-devs), has only the following APIs:

• get()
• set()

And that's it.

The Cell here has:

• current
• read()
• set()
• update()
• freeze()

So with the different set of APIs, and intent to make cell-usage ergonomic in templates (Signals would not be (until we get some kind of expression syntax)), I think it makes more sense to purposefully differentiate the name.

I also think this feature is a great addition to Ember. As reactive state management becomes a standard in modern frameworks, it's exciting to see Ember adopt this approach, providing developers with more flexibility and a declarative way to build dynamic UIs.

❤️ 🎉