Make @service able to be used in templates #1118
Conversation
…helper-manager-for-service.md
| - **API Surface**: Another way to access services | ||
| - **Template Verbosity**: `{{#let}}` adds nesting for method calls | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
write about how service can actually be a resource
|
|
||
| Add helper manager capabilities to `@ember/service`'s `service` export, enabling direct template usage while maintaining backward compatibility with existing service injection patterns. | ||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
Explain why service can't just work with the default helper manager (default helper manager doesn't know about the owner)
- re-shaping services as resources would solves this (internal change)
alternatively, we could make the default helper manager setOwner on the function
(then we don't need a separate helper manager)
|
Discussed during RFC review. No opposition to this design, but also interested in ways to make service-access possible in the JS scope using a more resource-based or cell-like API. |
NullVoxPopuli
added
S-Exploring
| import Component from '@glimmer/component'; | ||
| import { service } from '@ember/service'; | ||
|
|
||
| export default class extends Component { | ||
| @service theme; | ||
|
|
||
| // Boilerplate just to expose the service | ||
| get exposedTheme() { | ||
| return this.theme; | ||
| } | ||
| } |
There was a problem hiding this comment.
Why making the example more verbose than it needs to be?
In the HBS, the Service could be reached via just this.theme.
| import Component from '@glimmer/component'; | |
| import { service } from '@ember/service'; | |
| export default class extends Component { | |
| @service theme; | |
| // Boilerplate just to expose the service | |
| get exposedTheme() { | |
| return this.theme; | |
| } | |
| } | |
| import Component from '@glimmer/component'; | |
| import { service } from '@ember/service'; | |
| export default class extends Component { | |
| @service theme; | |
| } |
|
Btw there's already https://github.com/buschtoens/ember-service-helper and it can also return bound methods https://github.com/buschtoens/ember-service-helper/blob/main/addon/helpers/service.js . Not sure how useful that is. |
|
aye, I have something similar here: https://github.com/universal-ember/ember-primitives/blob/main/ember-primitives/src/helpers/service.ts
method invocation not working from templates without being bound is considered a bug and its one of my top to-dos to fix once the monorepos merge. |
|
RFC Review: What do the types look like? Does it work in template, as a decorator, and with stable decorators? |
Propose Make @service able to be used in templates
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
Exploringlabel 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
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP