Deprecate "ember component" - #1216
Conversation
Co-authored-by: Katie Gengler <katie@kmg.io>
| | 🌐 | `getComponentTemplate` | stays | | ||
| | 🌐 | `setComponentManager` | stays | | ||
| | 🌐 | `capabilities` | stays | | ||
| | 🌐 | `@ember/component/template-only` | stays | |
There was a problem hiding this comment.
Does this export make sense without classic components?
There was a problem hiding this comment.
practically, it is really only used by
- build tooling (emitted)
- TS (for importing
TOC)
I "have plans" to bring @glint/template in to ember-source -- perhaps under @ember/types, but that's a project that needs more dedicated focus as TS is a bit hinky
Co-authored-by: Katie Gengler <katie@kmg.io>
Co-authored-by: Katie Gengler <katie@kmg.io>
Co-authored-by: Katie Gengler <katie@kmg.io>
Co-authored-by: Katie Gengler <katie@kmg.io>
Co-authored-by: Katie Gengler <katie@kmg.io>
Co-authored-by: Katie Gengler <katie@kmg.io>
Co-authored-by: Katie Gengler <katie@kmg.io>
Updated migration steps for deprecating Ember components, ensuring clarity and consistency in the instructions.
NullVoxPopuli
changed the title
NullVoxPopuli
added
Final Comment Period
S-Exploring
| ## Alternatives | ||
|
|
||
| - do nothing -- we keep shipping the `EventDispatcher`, the classic class machinery, and two-way bindings to every app forever, and [#1116](https://github.com/emberjs/rfcs/pull/1116)/[#1117](https://github.com/emberjs/rfcs/pull/1117) can never complete their removals. | ||
| - extract the classic component into a userland package -- `setComponentManager` exists, so a `classic-component` package with its own component manager is _technically_ possible, and would give stuck apps an escape hatch past the major. This is compatible with (not an alternative to) this RFC, and could be community-maintained the way [ember-legacy-built-in-components](https://github.com/emberjs/ember-legacy-built-in-components) was for RFC #671. Notably though, such a package could not support the `click()`-style event methods without shipping its own event dispatcher. |
There was a problem hiding this comment.
If we extracted classic components into a userland package (along with its own event dispatcher) would that cause any headaches at a framework level when removing deprecated code? Any app I've touched in the last 7+ yrs has been steadily moving away from classic components so not positive it's necessary, but curious about the technical headaches around making that possible ...
There was a problem hiding this comment.
the last time we tried to move @ember/string to an external package, it was a bit of a nightmare for compatibility between all the build tools and environments, and interleaving of compatibility layers -- I think getting @ember/string compatibility working cost more time than if we had told people to "just use change-case" (or similar).
However,
If classic app / broccoli were deprecated and unsupported, perhaps it could be an option, because Vite prefers declared packages over the virtual packages (why you don't have @glimmer/tracking or rsvp in your package.json, for example -- because rn, they are provided by the framework's build tooling)
So,
my preference is to deprecate and abandon ember-component altogether
also because I want the machinery it relies on to be cleaned up (which is for future RFCs), and that would not be possible if we still had to support it forever (but in a separate addon) -- there is a lot more ember-component relies on than the event dispatcher 🙈
3 participants
Propose deprecating "ember component"
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
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