Reactivity: resources

[NullVoxPopuli]

• finalize design
  • depends on scheduler design for having clear answers to timing semantics (what behaviors can we expect when during which parts of the scheduling phases)
  • See thread (and sub-threads) about official class-based option: https://discord.com/channels/480462759797063690/1161669019162648647/1202530820963958784

Blocks:

• routing
  • Routing: Analysis #20
• modifiers
  • Reactivity: Modifiers #18
    • Include modifiers by default #12
• services

the idea of resources is that they're the "destroyable" primitive, a more ergonomic way to do setOwner + associateDestroyableChild + registerDestructor (from @ember/destroyable) -- and would be an implementation detail for many higher-level things

---

open questions

• property access vs "being a value"
  • NVP: Why not both? there is no ergonomic difference between accessing properties on this vs accessing properties on anything else, imo. Accessing properties on this and making them "look like" the reactive thing (like @tracked) requires the usage of a decorator to hide the inner getter/setter.
• should we base everything off ECMA resources?
  • supporting these is a good idea
    • NVP: but there is a current lack of convention around them (so I don't think they should be "the" resource implementation -- our resources could build on top of them though), (and Symbol.dispose isn't available yet). To use these, we'd have to require that folks define getters on their return object, like:

      function Greet(name) {
        return {
          get someValue() {
            return `hi, ${name}`;
          }
          [Symbol.dispose]() { /* ... */ }
        }
      }
      
      <template>
        {{Greet "NVP"}} -- can't work with ECMA resources, renders the object
      
        we'd have to do this:
        {{#let (Greet "NVP") as |x|}}
          {{x.someValue}}
        {{/let}}
      </template>

  • do we want a consistent property-access only story around reactivity in general? (something @chancancode brought up, against using arrow functions for deferring reactivity instead of getters)
    NVP: I think we need to document how reactivity works in general (we haven't yet! 🙈 ), and maybe this is a power-user technique, idk. Personally, I'm yet to be convinced on the importance of unifying on one-off classes / getters / properties instead of arrows. (this is slightly tangential to resources, but the patterns created by resource ergonomics so far have made us realize we have a lot of unanswered questions around reactivity in general)

---

See also:

• ember implementation
  • https://github.com/NullVoxPopuli/ember-resources/
  • prior implementations
    • https://github.com/NullVoxPopuli/ember-modify-based-class-resource/
    • https://github.com/pzuraq/ember-could-get-used-to-this
• universal implementation
  • https://www.starbeamjs.com/guides/fundamentals/resources.html
• ECMA - Stage 3
  • https://github.com/tc39/proposal-explicit-resource-management
• Original tracking issue Reactivity: resources ember.js#20096
• ECMA Signals (may still be a private repo)
  • https://github.com/proposal-signals/proposal-signals
    • (at least 2 years out, so don't worry -- mostly posting this for ideas, and to show that resources require ownership linkage (as discussed "somewhere" (iirc) w/r/t cleanup behavior))

[kategengler]

Possibly descoped from Polaris after discussion at 2024 f2f.