Add ErrorBoundary RFC - #1
Closed
megothss wants to merge 10 commits into
Closed
Conversation
Add RFC proposing a built-in <ErrorBoundary> component for catching synchronous render errors in the Glimmer VM.
- Remove Discourse mention, generalize to plugin architectures - Fix Solid.js and Preact documentation links - Add Svelte to framework parity list - Fix "only major framework" claim (Angular/Lit also lack it) - Remove vague route-level recovery subsection - Clean up unmaintained addon reference - Promote reference implementation into dedicated PoC section
Illustrate render failure blast radius with a concrete example
Add RFC emberjs#513 to prior discussion section, remove @onerror callback from unresolved questions
Comment on lines
+24
to
+26
| ### No built-in error recovery | ||
|
|
||
| If a component's getter throws during render, or a helper invocation fails, the entire render pass aborts. The DOM may be left partially rendered, and there's no way for the app to recover gracefully. The user is left staring at a broken page. |
There was a problem hiding this comment.
This heading & paragraph feels like it's just repeating exactly the same info as the paragraph above? Maybe just drop it?
Comment on lines
+67
to
+69
| ### Graceful degradation | ||
|
|
||
| ErrorBoundary enables progressive enhancement patterns. Wrap non-critical UI sections (widgets, sidebars, third-party embeds) in boundaries so that failures degrade gracefully while the rest of the app stays interactive. |
There was a problem hiding this comment.
This heading & paragraph seems to be repeating the same problem again. I think we can delete it.
|
|
||
| ErrorBoundary doesn't catch: | ||
|
|
||
| - Modifier install/update errors: modifiers run in `transaction.commit()` after the VM execution phase completes, outside the boundary's try/catch scope |
There was a problem hiding this comment.
This is kinda surprising. Surely we'd want modifier to have their errors caught? Otherwise they'll break the whole app?
Owner
Author
There was a problem hiding this comment.
Modifiers usually do not break the app. They run async and it's hard to catch/rollback them because they may be altered the DOM themselves
Drop two Motivation subsections that restated the opening paragraph. Answer the modifier question directly rather than calling the omission intentional. Modifiers run after the boundary's try has exited, and one may already have mutated the element, so recovery does not mean the same thing it does for render output. Say plainly that this is the most significant known gap. Add an Alternatives section on block syntax. The component form was chosen because it needs no tooling change, not because a keyword is the wrong answer. Rewrite Proof of concept: the prototype leaned heavily on AI assistance, is not a proposed implementation, and is not offered as a pull request against Ember. Ask reviewers to judge the API on its own merits. Retitle around the capability rather than the component, since the component is the proposed shape and not the substance of the proposal. Set start-date to the day the PR is opened, matching how the field is used in practice.
Owner
Author
|
Superseded by the upstream proposal: emberjs#1235 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add RFC proposing a built-in component for catching synchronous render errors in the Glimmer VM.
Propose {{RFC_NAME}}
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