Deprecate this.get and this.set on test contexts - #1203
Deprecate this.get and this.set on test contexts#1203kategengler with Copilot wants to merge 3 commits into
this.get and this.set on test contexts#1203Conversation
kategengler
changed the title
this.get and this.set on test contextsthis.get and this.set on test contexts
|
Created with copilot as a placeholder 🙏 |
NullVoxPopuli
added
S-Exploring
…ontexts Correct RFC 1203
|
|
||
| ## Summary | ||
|
|
||
| Deprecate the use of `this.get` and `this.set` on the test context object in rendering tests, as a logical conclusion of [RFC #785](https://github.com/emberjs/rfcs/blob/master/text/0785-remove-set-get-in-tests.md), which introduced `render(component)` and `rerender()` as the modern replacements. |
There was a problem hiding this comment.
can this include everything that isn't this.owner?
There was a problem hiding this comment.
Probably not?
this.elementis available in some of the test contexts- users can also stash whatever they want on
this(and it is not an uncommon pattern). this.pauseTestandthis.resumeTestare very useful because when debugging it is annoying to add an import.
There was a problem hiding this comment.
oh yea, pause/resume test are very useful
this.element probably shouldn't exist tho -- because... what is it? topic for another RFC tho.
so this RFC should really just deprecate the data-manip utils
| assert.dom('[data-test-name]').hasText('Zoey'); | ||
|
|
||
| state.name = 'Tomster'; | ||
| await rerender(); |
There was a problem hiding this comment.
what is the purpose of rerender?
we can await renderSettled()
as well as
await settled()
depending on if you need to test intermediate states
There was a problem hiding this comment.
rerender already exists and came from https://github.com/emberjs/rfcs/blob/main/text/0785-remove-set-get-in-tests.md
This RFC was generated by copilot as a placeholder and needs actual writing.
|
This RFC / deprecation could be blocking for enabling use-async-scheduler, from #957 (if users are not using get/set in tests, they would still be able to use the new scheduler) |
Propose Deprecate
this.getandthis.seton Test ContextsRendered
Summary
This pull request is proposing a new RFC.
Logical conclusion of RFC #785: formally deprecates
this.get/this.seton the test context now that the modern replacements (render(component)+rerender()) have been stable since Ember 4.5.0.The old pattern is broken in three ways: it's run-wrapped (synchronous full DOM flush on every call), inconsistent with post-Octane tracked state, and causes TypeScript friction from arbitrary
thisproperty augmentation. The modern replacement is local@trackedstate passed intorender(<template>…</template>), withrerender()to await DOM updates.RFC covers: deprecation warning message,
eslint-plugin-emberlint rule, blueprint updates, and a codemod for automated migration.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