Resources

[NullVoxPopuli]

Propose Adding resources as a low-level reactive primitive

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.

[johanrd]

Thank you! Built-in reactive resource management will be a good addition to the reactivity ergonomics of Ember❤️

One thing I feel could get a clarification in the RFC, is the (short term and long term) relationship between reactive resources in Ember and the javascript Explicit Resource Management proposal. Since there is some conceptual and term-overlap with the native proposal, I am curious to read about what needs to be kept Ember-specific, both for teachability and the potential for polyfilling until eventually cut from the scope of Ember?

[bryanaka]

Really like the direction of this. We make use of ember-resources and I think this is going in a direction that is digestible for newer devs coming into the code. Thank you for putting this together!

The context not being preserved in fat arrows used in decorators tripped me up when reading through, but made sense as soon as I reached that section.

Suggestion, and I don't know how hard this would be so grain of salt, would be nice to have an ember eslint config where you can enforce resource = use(this, ResourceFactory()) if set and not allow the decorator use. I could see that getting confusing for some teams if you have both syntaxes, but I don't feel strongly enough to not bless the decorator version either.

[NullVoxPopuli]

reactive resources in Ember and the javascript Explicit Resource Management proposal.

Explicit Resource Management already works in ember today, and I'm not sure we need to do anything to support it.

Like, you can already do:

class Demo extends Component {

 doThing => async () => {
    let using _ = animateLoading();
    
   // async / await / fetch
   
   // by the end, animateLoading does its cleanup
 }

  <template>
     <button onclick={{this.doThings}}>do it</button>
  </template>
}

This is because Explicit Resource Management is for behaviors you invoke -- where as the Resources in this proposal represent values with lifetime.

In the Explicit Resource Management example above, there is no value and the lifetime is just the execution of the function and no more.

One thing we could do in the future as a different RFC is add support for Symbol.dispose:

export default class Demo extends Component {

  [Symbol.dispose]() {
     // willDestroy, who?
  }
}

[NullVoxPopuli]

ember eslint config where you can enforce resource = use(this, ResourceFactory()) if set and not allow the decorator use.

is there a reason you'd want to avoid decorators? My hope is that TS will finally support type-changing decorators by the time this lands 🙈 and then there is no issue with the types vs vanilla usage at all.