From 0dda729ba89cd874ebdd0fc1b44642af2ccacd26 Mon Sep 17 00:00:00 2001 From: Peter Wagenet Date: Tue, 15 Jul 2025 15:02:16 -0700 Subject: [PATCH] Flesh out RFC body --- text/0000-deprecate-target-action-support.md | 105 -------------- text/1041-deprecate-target-action-support.md | 144 +++++++++++++++++++ 2 files changed, 144 insertions(+), 105 deletions(-) delete mode 100644 text/0000-deprecate-target-action-support.md create mode 100644 text/1041-deprecate-target-action-support.md diff --git a/text/0000-deprecate-target-action-support.md b/text/0000-deprecate-target-action-support.md deleted file mode 100644 index 6795adf6f9..0000000000 --- a/text/0000-deprecate-target-action-support.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -stage: accepted -start-date: # In format YYYY-MM-DDT00:00:00.000Z -release-date: # In format YYYY-MM-DDT00:00:00.000Z -release-versions: -teams: # delete teams that aren't relevant - - cli - - data - - framework - - learning - - steering - - typescript -prs: - accepted: # Fill this in with the URL for the Proposal RFC PR -project-link: -suite: ---- - - - -<-- Replace "RFC title" with the title of your RFC --> -# Deprecate target action support - -## Summary - -Deprecate `send` and the corresponding target action support. - -## Motivation - -These are super-old patterns that nobody needs to use in new code. We've already deprecated the `{{action}}` modifier/helper, which was the primary way to interact with this system. - -## Detailed design - -Things this would target - -- `TargetActionSupport` mixin - - `triggerAction` -- `ActionHandler` mixin - - `send` method -- `ActionSupport` mixin - - `send` method - -> This is the bulk of the RFC. - -> Explain the design in enough detail for somebody -familiar with the framework to understand, and for somebody familiar with the -implementation to implement. This should get into specifics and corner-cases, -and include examples of how the feature is used. Any new terminology should be -defined here. - -> Please keep in mind any implications within the Ember ecosystem, such as: -> - Lint rules (ember-template-lint, eslint-plugin-ember) that should be added, modified or removed -> - Features that are replaced or made obsolete by this feature and should eventually be deprecated -> - Ember Inspector and debuggability -> - Server-side Rendering -> - Ember Engines -> - The Addon Ecosystem -> - IDE Support -> - Blueprints that should be added or modified - -## How we teach this - -> What names and terminology work best for these concepts and why? How is this -idea best presented? As a continuation of existing Ember patterns, or as a -wholly new one? - -> Would the acceptance of this proposal mean the Ember guides must be -re-organized or altered? Does it change how Ember is taught to new users -at any level? - -> How should this feature be introduced and taught to existing Ember -users? - -> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc. - -## Drawbacks - -> Why should we *not* do this? Please consider the impact on teaching Ember, -on the integration of this feature with other existing and planned features, -on the impact of the API churn on existing apps, etc. - -> There are tradeoffs to choosing any path, please attempt to identify them here. - -## Alternatives - -> What other designs have been considered? What is the impact of not doing this? - -> This section could also include prior art, that is, how other frameworks in the same domain have solved this problem. - -## Unresolved questions - -> Optional, but suggested for first drafts. What parts of the design are still -TBD? diff --git a/text/1041-deprecate-target-action-support.md b/text/1041-deprecate-target-action-support.md new file mode 100644 index 0000000000..2953315393 --- /dev/null +++ b/text/1041-deprecate-target-action-support.md @@ -0,0 +1,144 @@ +--- +stage: accepted +start-date: 2025-07-15T00:00:00.000Z +release-date: # In format YYYY-MM-DDT00:00:00.000Z +release-versions: +teams: + - framework +prs: + accepted: # Fill this in with the URL for the Proposal RFC PR +project-link: +suite: +--- + +# Deprecate TargetActionSupport + +## Summary + +Deprecate `send` and the corresponding TargetActionSupport. + +## Motivation + +These are legacy patterns that are no longer recommended in modern Ember code. The primary way to interact with this system was the now-deprecated `{{action}}` modifier/helper. The modern approach is to use standard class methods (optionally decorated with `@action`) and to pass functions directly, following the Data Down, Actions Up (DDAU) pattern. + +See also: [Target Action Support deprecation guide](https://deploy-preview-1410--ember-deprecations.netlify.app/deprecations/v6.x/#target-action-support) + +## Detailed design + +This RFC proposes to deprecate and remove the following: + +- `TargetActionSupport` mixin, specifically the `triggerAction` method +- `ActionHandler` mixin, specifically the `send` method +- `ActionSupport` mixin, specifically the `send` method + +These mixins and methods are legacy patterns that predate modern Ember features like native classes, tracked properties, and Glimmer components. Their primary use case was to support the `{{action}}` helper/modifier, which has already been deprecated. + +### Deprecation Process + +1. Mark the affected mixins and methods as deprecated in the next minor release, with clear deprecation warnings and migration guides. +2. Update documentation to reflect the deprecation and recommend alternatives (such as closure actions, service injection, or direct method calls). +3. Remove the deprecated APIs in a future major release. + +### Migration Path + +- For `send` and `triggerAction`, recommend direct method invocation or using closure actions. +- Provide codemods or lint rules to help users identify and migrate away from these patterns. + + +### Example Migration + +**Before:** + +```js +// Using send +this.send('doSomething'); +``` + +**After:** + +```js +// Direct method call +this.doSomething(); +``` + +**Before:** + +```js +// Using triggerAction +this.triggerAction({ action: 'save' }); +``` + +**After:** + +```js +// Direct method call or closure action +this.save(); +// or pass a closure action +@action +save() { /* ... */ } +``` + + +### Deprecation Message + +When these APIs are used, emit a deprecation warning: + +``` +The use of `send`/`triggerAction`/target action support is deprecated. See https://deploy-preview-1410--ember-deprecations.netlify.app/deprecations/v6.x/#target-action-support for migration details. +``` + +### Ecosystem Implications + +- **Lint rules:** Add rules to `ember-template-lint` and `eslint-plugin-ember` to flag usage of these APIs. +- **Features replaced/obsolete:** The `{{action}}` helper/modifier and related mixins are already deprecated or replaced by modern patterns. +- **Ember Inspector:** Remove or update any features that rely on these APIs. +- **Server-side Rendering, Ember Engines, Addon Ecosystem, IDE Support:** No direct impact, but documentation and blueprints should be updated to avoid these patterns. + +--- + + +## How we teach this + +This deprecation is a continuation of Ember's modernization, moving away from legacy patterns toward direct method calls and closure actions. The recommended terminology is "direct method invocation" and "closure actions". + +**Guides and Documentation:** +- Remove references to `send`, `triggerAction`, and the affected mixins from the Ember Guides and API docs. +- Add a deprecation guide (see above) and migration examples. +- Update blog posts and tutorials to avoid these patterns. + +**For Existing Users:** +- Announce the deprecation in release notes and community channels. +- Provide codemods, lint rules, and clear migration paths. + +**For New Users:** +- Ensure new learning materials do not mention or rely on these legacy APIs. + +--- + + +## Drawbacks + +- Some legacy apps and addons may still rely on these patterns, so deprecation and removal could require migration effort. +- Removing these APIs may break code that uses dynamic action dispatching via `send` or `triggerAction`. +- There is a risk of fragmenting documentation and learning resources during the transition period. + +--- + + +## Alternatives + +- Do nothing: Continue to support these legacy APIs, but this increases maintenance burden and hinders Ember's modernization. +- Deprecate but do not remove: This avoids breaking changes but leaves deprecated code in the framework indefinitely. +- Replace with a new abstraction: No clear need, as modern JavaScript and Ember patterns already provide better alternatives. + +**Prior Art:** +Other frameworks (React, Vue, Angular) encourage direct method calls or use of closures for event handling, rather than a dynamic action dispatch system. + +--- + + +## Unresolved questions + +- Are there any edge cases or internal uses of these mixins that need special handling? +- Should we provide an official codemod for migration, or rely on lint rules and manual refactoring? +- Are there any third-party addons that would be significantly impacted and need outreach or support?