Context

[NullVoxPopuli]

Implementation: emberjs/ember.js#21450

Intent to supersede

• Expose Component Render Tree Iterator for Component Manager #1155
• Public API for render-tree-based scope exploration #1154
• Add context API #975

Propose Context

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.

[les2]

For consuming, an alternative API could be:

@service
someThing;

on the provider side, you could use:

@provide('key')
get someThing() {
   return 'hi';
}

Use case I'm thinking of:
I often have some API for my component and i need to pass it down multiple layers.

class Modal extends Component {
   @tracked closed = false;
   
   @provide('service:modalApi')
   get modalApi() {
      return { close: () => { this.closed = true;}; } 
   }
}

For anything that's embedded in a modal, they could react to it (optionally):

class Thing extends Component {
   @service('modalApi', { optional: true })
   modalApi;
   
   <template>
       {{#if this.modalApi}}<h1>i'm in a modal!</h1>{{else}}<p>I'm not.</p>{{/if}}
   </template>
}

Of course, the tag-based / template-based <Provide API works too for cases when you don't have a backing class.

This allows only the provider-side to adopt new APIs (if service is required, it's just @service modalApi; You could also replace / shadow any service for children. This is very evil but I could see it being useful.

If overloading the behavior of @service is not appreciated (I suspect the majority will instinctively find it to be a terrible idea) -- you could just use a @consume decorator instead.

On the consumption side, I think that considering "consume" in the abstract just a service is pretty cool.

In certain backend frameworks, you can declare "services" with scopes -- session-scoped, request-scoped, or singleon/global -- the consumer doesn't decide that, only the provider. The framework injects the appropriate object as configured.

• Optionality of the consumed quantity will be useful.

--- Okay, that's enough rambling. ----

Writing this up in a way that I thought about it helped me understand the demand for the feature in the proposal. The bikeshedding I have provided on the shape of the solution doesn't impact the core need for such an API. As such, I hope this proposal succeeds.

[les2]

I sometimes -- perhaps just as often if not more -- want the reverse!

The children provide something for the parent. This calls for the "dreaded" (IMO) <Foo @registerApi={{this.setFooApi}} /> pattern that allows the host component for <Foo to get a reference to it.

// in the host
@consume('fooApi') foo;

<template><Foo /></template>

maybe foo does:

class Foo extends Component {
   @provide('fooApi')
   get foo() { return this.makeApi(); }
   
   // alternatively
   constructor() {
      super(...);
      provide(this, 'fooApi:' + this.args.name, this.makeApi());
   }
}

This is offtopic! just wanted to say there's an inverse provide/consume relationship that requires boilerplate.

[NullVoxPopuli]

consume can already work in the class, but not as a decorator -- no argument is needed, it's just ctx.consume() and you get the value.

on Provide using a decorator -- it breaks the "block scope" semantics that we get with the DOM, so I feel it would be too magical, and potentially leaky, to implement that way.

on decorators in general, for type safety, it's easier to avoid them since we can't have decorators force a type on their decorated property.

This is offtopic! just wanted to say there's an inverse provide/consume relationship that requires boilerplate.

your example from your second comment would be written as:

const fooApi = makeContext();

class Foo extends Component {
  makeApi = () => {/* ... */};

  <template>
    <fooApi.Provide @value={{ (this.makeApi) }}>
      {{yield}}
    </fooApi.Provide />
  </template>
}

<template>
  <Foo>
    {{log (fooApi.consume)}} -- logs whatever makeApi returns
  </Foo>
</template>

[patricklx]

could it be enhanced to support keyed values? non-keyed could also just work

<template>
<fooApi.Provide @key="api" @value={{ (this.makeApi) }}>
  <fooApi.Provide @key="theme" @value={{ (this.makeTheme) }}>
      {{(ctx.consume 'api')}}
      {{(ctx.consume 'theme')}}
  </fooApi.Provide />
</fooApi.Provide />
</template>

consume would walk up until it find the right provider