Skip to content

Commit

Permalink
Merge branch 'master' into advance-rfc-0756
Browse files Browse the repository at this point in the history
  • Loading branch information
ef4 authored Feb 3, 2023
2 parents a7a1462 + 3df1986 commit 5677cc0
Show file tree
Hide file tree
Showing 16 changed files with 1,451 additions and 43 deletions.
16 changes: 8 additions & 8 deletions .github/PULL_REQUEST_TEMPLATE/advance-to-ready-for-release.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,16 +28,16 @@ Each Ember core team will be requested as a reviewer on the PR to move into this

- [ ] Implementation is complete according to plan outlined in the RFC, with any adjustments noted in the RFC
- [ ] Any necessary learning materials have been updated
- [ ] The Ember team is ready to commit to the stability of any interfaces exposed by the current implementation of the feature
- [ ] The Ember team is ready to commit to the stability of any interfaces exposed by the current implementation of the feature. This is the go/no go decision for any feature flags, but the flags should only be turned on when moving to Released.
- [ ] Criteria for moving to the Recommended Stage has been filled out
- [ ] This PR has been converted from a draft to a regular PR and the `Final Comment Period` label has been added to start the FCP
- [ ] Each [team](https://github.com/emberjs/rfcs#relevant-teams) has been added as a reviewer to the PR at the start of the FCP
* [ ] Framework @emberjs/framework
* [ ] Data @emberjs/ember-data-core
* [ ] CLI @emberjs/cli
* [ ] Learning @emberjs/learning-core
* [ ] Typescript @emberjs/typescript-core
* [ ] Steering @emberjs/steering
- [ ] Each [team](https://github.com/emberjs/rfcs#relevant-teams) has been added as a reviewer to the PR at the start of the FCP. Reviews are not required by the end of the FCP. This is a notification step.
* Framework @emberjs/framework
* Data @emberjs/ember-data-core
* CLI @emberjs/cli
* Learning @emberjs/learning-core
* Typescript @emberjs/typescript-core
* Steering @emberjs/steering


## Criteria for moving to Recommended (required)
Expand Down
2 changes: 1 addition & 1 deletion .github/PULL_REQUEST_TEMPLATE/advance-to-released.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,6 @@ An RFC is moved into "Released" when the above is verified by consensus of the r

## Checklist to move to Released

- [ ] The work is published in stable versions of the relevant package(s)
- [ ] The work is published in stable versions of the relevant package(s), with any feature flags toggled on.
- [ ] Deviations from the original RFC are noted in the RFC
- [ ] Release packages and dates are updated in the RFC frontmatter
19 changes: 15 additions & 4 deletions .github/READTHIS.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,8 @@ This has various checks to ensure new the RFC has correct metadata, filename, et
This should be tested when updating actions/find-added-or-modified-rfcs or any of
the actions used within that action. See [testing](#testing).

Test the following:
#### Testing Steps

- [ ] Adding a new RFC. A new pull request should be opened with a new RFC, the
first job should correctly determine that an RFC has been added and the other
jobs should run.
Expand All @@ -34,7 +35,8 @@ whether the pull request adds a new RFC. If it does, it labels the pull request
This should be tested when updating actions/find-added-or-modified-rfcs or any of
the actions used within that action. See [testing](#testing).

Test the following:
#### Testing Steps

- [ ] Adding a new RFC. A new pull request should be opened with a new RFC, the
first job should correctly determine that an RFC has been added and the other
jobs should run. The label `S-Proposed` should be added.
Expand All @@ -57,7 +59,8 @@ If an RFC stage was modified, this triggers the open-advancement-pr.yml workflow
This should be tested when updating actions/find-added-or-modified-rfcs or any of
the actions used within that action. See [testing](#testing).

Test the following:
#### Testing Steps

- [ ] Adding a new RFC. Merging a pull request that adds an RFC should open a
pull request to advance to the next stage using the correct template.
- [ ] Updating an RFC stage. Merging a pull request that modifies an existing RFC's
Expand All @@ -74,7 +77,15 @@ This workflow runs on workflow_dispatch and can be triggered from the GitHub UI.
It takes a path to an RFC and will open a PR to advance it to the next stage, if
applicable.

Test the following:
RFCs that already existed before the implementation of
[Staged RFCs](https://github.com/emberjs/rfcs/blob/master/text/0617-rfc-stages.md)
did not get advancement PRs to their next stage. To create an advancement PR you
can manually run the workflow from the Github UI.

![Screenshot of the Github UI for manually triggering a workflow](./doc-assets/advance-rfc.png)

#### Testing Steps

- [ ] In the UI, on this workflow, trigger with a path of an existing RFC. A pull
request should be opened to advance the RFC to the next stage.
- [ ] In the UI, on this workflow, trigger with a path of an existing RFC at the
Expand Down
2 changes: 1 addition & 1 deletion .github/actions/setup-rfcs-tooling/action.yml
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ runs:
with:
repository: emberjs/rfcs-tooling
path: rfcs-tooling
ref: 'v2.1.0'
ref: 'v2.1.1'

- uses: actions/setup-node@v3
with:
Expand Down
Binary file added .github/doc-assets/advance-rfc.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
35 changes: 20 additions & 15 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ The process is intended to provide a consistent and controlled path for new
features and changes to enter the framework. RFCs can be created by any member
of the community.

---
---
## Quick links for Pull Requests for proposed and advancing RFCs
[Quick links for Pull Requests for proposed and advancing RFCs]: #quick-links-for-pull-requests-for-proposed-and-advancing-rfcs

Expand Down Expand Up @@ -82,7 +82,7 @@ If that period is successful, with no new unaddressed concerns raised, the RFC
is merged and is now in the [Accepted] stage.

An RFC that does not achieve consensus to be accepted may enter a
[Final Comment Period](#final-comment-periods-fcp) to move the RFC to the
[Final Comment Period](#final-comment-periods-fcp) to move the RFC to the
[Closed] stage.

### Merged Proposals
Expand Down Expand Up @@ -276,30 +276,30 @@ Ember.
Following the RFC repository is the best way to keep up with the proposed
changes to Ember and with the implementation of accepted changes.

Watching the repository will alert you to any newly created RFCs. Setting up
notifications on a particular pull request will help you follow the progress of
Watching the repository will alert you to any newly created RFCs. Setting up
notifications on a particular pull request will help you follow the progress of
that RFC.

RFCs in [Final Comment Periods](#final-comment-periods-fcp) are labeled with
[Final Comment Period](https://github.com/emberjs/rfcs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3A%22Final+Comment+Period%22)
and are announced on the [Ember twitter account](https://twitter.com/emberjs).

[Quick links](#quick-links-for-pull-requests-for-proposed-and-advancing-rfcs)
[Quick links](#quick-links-for-pull-requests-for-proposed-and-advancing-rfcs)
are provided at the top of the README to help you review what you are interested in.


## Commenting on an RFC
[Commenting on an RFC]: #commenting-on-an-rfc

Comments are the very heart of the RFC process. Comments are the primary way community
members and core team members can provide feedback and collaborate on the design
of a feature.
Comments are the very heart of the RFC process. Comments are the primary way community
members and core team members can provide feedback and collaborate on the design
of a feature.

Comments should also be used to ensure the author has completed the RFC template
and addressed implications of the feature across the Ember project, including
documentation, addons, and tooling.
Comments should also be used to ensure the author has completed the RFC template
and addressed implications of the feature across the Ember project, including
documentation, addons, and tooling.

Comments should be constructive and respectful, following our
Comments should be constructive and respectful, following our
[Community Guidelines](http://emberjs.com/guidelines/).

## Creating an RFC
Expand Down Expand Up @@ -398,15 +398,15 @@ shepherding its progress. [Read more about the Champion's job](#champion-respons
## Implementing an RFC
[Implementing an RFC]: #implementing-an-rfc

Coordination and tracking of implementation of an RFC is done primarily on the
Coordination and tracking of implementation of an RFC is done primarily on the
pull request to advance the RFC to the [Ready for Release] stage.

The author of an RFC is not obligated to implement it. Of course, the
RFC author (like any other developer) is welcome to work on the implementation.

If you are interested in working on the implementation for an [Accepted]
RFC, but cannot determine if someone else is already working on it,
please ask (e.g. by leaving a comment on the pull request to advance the RFC to
please ask (e.g. by leaving a comment on the pull request to advance the RFC to
the [Ready for Release] stage).

### Editing merged RFCs
Expand All @@ -423,7 +423,7 @@ about this feature." This note is not intended to be updated across time.
- Updating any part of the RFC prose, in order to keep a written record of the
changes and rationale.

Major changes should have a new RFC. The old RFC is moved to the [Discontinued]
Major changes should have a new RFC. The old RFC is moved to the [Discontinued]
stage when the replacement is merged.

## Reference
Expand Down Expand Up @@ -521,6 +521,11 @@ champion at any time.
- [ ] Prepare for advancing the RFC to the next stage if applicable (e.g.
opening a placeholder PR)

For RFCs opened before the implementation of
[Staged RFCs](https://github.com/emberjs/rfcs/blob/master/text/0617-rfc-stages.md)
did not get advancement PRs to their next stage. See the
[automations docs](https://github.com/emberjs/rfcs/blob/master/.github/READTHIS.md#trigger-opening-advancement-pryml) for instructions on how to trigger the advancement workflow.

#### Move to FCP to Close
- [ ] Achieve consensus to move to "FCP to Close" from relevant core teams
- [ ] Comment in the RFC to explain the decision
Expand Down
2 changes: 1 addition & 1 deletion text/0226-named-blocks.md
Original file line number Diff line number Diff line change
Expand Up @@ -123,7 +123,7 @@ them, and the mental/teaching model behind how it all works.
- Angle-bracket syntax does not support passing positional params

Implementation-wise, these varying semantics will be defined/implemented via
[Component Managers](https://github.com/emberjs/rfcs/blob/custom-components/text/0000-custom-components.md#componentmanager).
[Component Managers](https://github.com/emberjs/rfcs/blob/master/text/0213-custom-components.md#registering-component-managers).

## Multi-block Syntax

Expand Down
15 changes: 9 additions & 6 deletions text/0236-deprecation-ember-string.md
Original file line number Diff line number Diff line change
@@ -1,17 +1,20 @@
---
stage: recommended
stage: released
start-date: 2017-07-14T00:00:00.000Z
release-date: 2020-12-28T00:00:00.000Z
release-date: 2023-01-12T00:00:00.000Z
release-versions:
ember-source: v3.24.0

ember-source: v4.10.0
teams:
- framework
- typescript
prs:
accepted: https://github.com/emberjs/rfcs/pull/236
accepted: 'https://github.com/emberjs/rfcs/pull/236'
ready-for-release: 'https://github.com/emberjs/rfcs/pull/892'
released: 'https://github.com/emberjs/rfcs/pull/897'
project-link:
meta:
tracking: https://github.com/emberjs/rfc-tracking/issues/26
tracking: 'https://github.com/emberjs/ember.js/issues/20340'
legacy-tracking: 'https://github.com/emberjs/rfc-tracking/issues/26'
---

# Summary
Expand Down
7 changes: 4 additions & 3 deletions text/0373-Element-Modifier-Managers.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,13 +16,13 @@ project-link:

## Summary

This RFC proposes a low-level primitive for defining element modifiers. It is a parent to the [Modifiers RFC](https://github.com/emberjs/rfcs/pull/353).
This RFC proposes a low-level primitive for defining element modifiers. It is a parent to the [Element Modifiers RFC](https://github.com/emberjs/rfcs/pull/811).

## Motivation

Ever since Ember 1.0 we have had the concept of element modifiers, however Ember only exposes one modifier; `{{action}}`. We also do not provide a mechanism for defining your own modifiers and managing their life cycles.

As [pointed out](https://github.com/emberjs/rfcs/pull/353#issuecomment-417769349) in the [Element Modifiers RFC](https://github.com/emberjs/rfcs/pull/353) we should expose the underlying infrastructure that makes element modifiers possible. Based on our experience, we believe it would be beneficial to open up these new primitives to the wider community. The largest benefit is that it allows the community to experiment with and iterate on APIs outside of the core framework.
As [pointed out](https://github.com/emberjs/rfcs/pull/353#issuecomment-417769349) in the original [Modifiers RFC](https://github.com/emberjs/rfcs/pull/353) we should expose the underlying infrastructure that makes element modifiers possible. Based on our experience, we believe it would be beneficial to open up these new primitives to the wider community. The largest benefit is that it allows the community to experiment with and iterate on APIs outside of the core framework.

This RFC is in the same spirit as the [custom components RFC](https://github.com/emberjs/rfcs/blob/master/text/0213-custom-components.md).

Expand Down Expand Up @@ -458,7 +458,8 @@ What is proposed in this RFC is a low-level primitive. We do not expect most use
In the long term, there is a risk of fragmentating the Ember ecosystem with many competing modifier APIs. However, given the Ember community's strong desire for conventions, this seems unlikely. We expect this to play out similar to the data-persistence story – there will be a primary way to do things (Ember Data), but there are also plenty of other alternatives catering to niche use cases that are underserved by Ember Data.

## Alternatives
Instead of focusing on exposing enough low-level primitives we can just ship the high level API as described in [RFC#353](https://github.com/emberjs/rfcs/pull/353).
Instead of focusing on exposing enough low-level primitives we can just ship the high level API as described in [RFC#811](https://github.com/emberjs/rfcs/pull/811).

## Unresolved questions

TBD?
2 changes: 1 addition & 1 deletion text/0440-decorator-support.md
Original file line number Diff line number Diff line change
Expand Up @@ -171,7 +171,7 @@ Stage 1 decorators will be considered a first class Ember API. They will be
supported until:

1. A new RFC has been made to introduce a new decorator API as a parallel API to
the stage 1 decoraters.
the stage 1 decorators.
2. A deprecation RFC has been created for Stage 1 decorators.

They will follow the same deprecation flow, and same SemVer requirements, as any
Expand Down
59 changes: 59 additions & 0 deletions text/0790-deprecate-ember-data-ajax.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
---
stage: accepted
start-date: 2022-01-29
release-date: Unreleased
release_versions:
teams:
- data
prs:
accepted: https://github.com/emberjs/rfcs/pull/790
project-link:
suite:
---

# EmberData | Deprecate ajax requests

## Summary

Deprecates use of `ajax` methods in favor of `fetch` to request API data.

## Motivation

Currently, `ember-data` maintains two methods for users to fetch data from their backend - fetching with `jQuery.ajax` and `fetch`. Confusion further exists in the adapters if users implement functionality to change out of the box behaviour. They can override [`ajax`](https://github.com/emberjs/data/blob/e076e0ae71ae6426ca53ad3c5501a0af7ceca883/packages/adapter/addon/rest.ts#L1091-L1126) methods but without a clean interface to operate with, what they really may be doing is overriding how fetch works.

With Ember 4.0 dropping jQuery, we should take a hard stance on dropping the use of `ajax` in the next major release.

## Detailed design

The first step is putting in place a deprecation if an adapter uses `ajax` to make a request. Since `ember-data` switched the default behaviour to use fetch in 4.0, this deprecation will only apply to those who have overrided the default with `useFetch = true` in their adapters.

Second, we will expose fetch related methods on the adapters that are equivalent in use and flexibility as the current `ajax` options. Note the [`minimum-adapter-interface`](https://github.com/emberjs/data/blob/master/packages/store/addon/-private/ts-interfaces/minimum-adapter-interface.ts) does not assert the method by which a request is made. As a result, how we design and implement these methods should not have an effect on those users who have implemented their own adapter.

In 5.0, all `ajax` methods and supporting infrastructure will be removed. The list of affected methods includes:

- ajax
- _ajaxRequest
- _ajax
- ajaxOptions
- _ajaxUrl

Moreover, we may rename methods not part of the minimum-adapter-interface. Moreover, we expect to implement the following methods with [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch), although could be changed in the actual implementation.

- fetch
- fetchOptions
- fetchSuccess
- fetchError
- fetchUrl

## How we teach this

This is best taught through a deprecation guide. Users using `ajax` will need to install `ember-fetch` or rely on the default global `fetch` API provided by the browser. This has some implications, for example, with how query params are serialized. Users will have to be careful to ensure the behaviour of their API changes with any changes that result from switching to fetch.

## Drawbacks

Some user's technology stacks may be entirely dependent on `ajax` for requesting API data. This isn't necessarily an easy switch and may require multiple improvements to various layers to use `fetch`. For those users, we can document how they can still implement their own adapter to use `ajax`. This will involve overriding the existing `fetch` methods. For example, if your API still needs to be serviced with `ajax` to perhaps take advantage of [ajax options](https://api.jquery.com/jquery.ajax/#jQuery-ajax-url-settings) or [ajaxPrefilter](https://api.jquery.com/jquery.ajaxprefilter/), simply override the existing `fetch` methods. The goal of this refactor would be to ensure users who still need to use `ajax` has a happy path to doing so.

## Alternatives

- Continue providing and exposing public-ish adapters methods as `ajax`.
- Provide both `fetch` and `ajax` methods together in the adapters.
Loading

0 comments on commit 5677cc0

Please sign in to comment.