| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Was @try {} / @catch {} considered? Why was @boundary {} / @error {} preferred? |
Sorry, something went wrong.
|
Error Boundaries are a common concept in frontend frameworks and try/catch felt more "imperative" to us. |
Sorry, something went wrong.
| import * as t from './r3_ast'; | ||
|
|
||
| /** Pattern used to identify a boundary `let` parameter. */ | ||
| const LET_PATTERN = /^(let\s+)(.*)/; |
There was a problem hiding this comment.
It looks like this wasn't resolved?
Sorry, something went wrong.
| export interface ErrorDetails { | ||
| readonly boundary?: { | ||
| readonly type: Type<any>; | ||
| readonly reset: () => void; |
There was a problem hiding this comment.
Note for: we need to settle on either retry or reset for consistency
Sorry, something went wrong.
There was a problem hiding this comment.
Is the a precedent anywhere for this? @atscott Didn't you use something similar for reseting/retrying route resources, or was that reloading?
Sorry, something went wrong.
There was a problem hiding this comment.
I think maybe you're referring to reload, potentially? There was something in there to trigger reloads on resources in an error state.
Sorry, something went wrong.
There was a problem hiding this comment.
Ah okay. Maybe reset is most appropriate then? reload and retry to me imply some kind of network request operation, whereas reset more accurately reflects the fact that we're simply resetting some internal framework state?
Sorry, something went wrong.
Add the runtime primitives `ɵɵboundaryCreate` and `ɵɵboundaryUpdate` to the core instructions, which handle synchronous view destruction and provide the `ON_ERROR` interceptor hooks. Also include the initial compiler AST representations for the new syntax including the Lexer tokenization and HTML Parser integration. This lays the foundational structure for `@boundary` prior to code generation. Co-authored-by: Matthieu Riegler <kyro38@gmail.com>
Add support for `@boundary` blocks in the template type-checking pipeline.
Add support for the new `@boundary` and `@error` control flow blocks in the Angular Language Service. This includes: - Updating outlining spans to handle boundary blocks correctly. - Adding classification visitor methods for semantic tokens. - Adding template target visitor methods for navigation and hover support. - Updating the TextMate grammar to recognize `@boundary` and the `when` clause.
…ation Added some tests to ensure error boundaries work with SSR and hydration.
|
This PR was merged into the repository. The changes were merged into the following branches:
|
Sorry, something went wrong.
angular#70463) Add the runtime primitives `ɵɵboundaryCreate` and `ɵɵboundaryUpdate` to the core instructions, which handle synchronous view destruction and provide the `ON_ERROR` interceptor hooks. Also include the initial compiler AST representations for the new syntax including the Lexer tokenization and HTML Parser integration. This lays the foundational structure for `@boundary` prior to code generation. Co-authored-by: Matthieu Riegler <kyro38@gmail.com> PR Close angular#70463
…ngular#70463) Add support for `@boundary` blocks in the template type-checking pipeline. PR Close angular#70463
Add support for the new `@boundary` and `@error` control flow blocks in the Angular Language Service. This includes: - Updating outlining spans to handle boundary blocks correctly. - Adding classification visitor methods for semantic tokens. - Adding template target visitor methods for navigation and hover support. - Updating the TextMate grammar to recognize `@boundary` and the `when` clause. PR Close angular#70463
…ation (angular#70463) Added some tests to ensure error boundaries work with SSR and hydration. PR Close angular#70463
This was missing from angular#70463
This was missing from #70463
) * feat(keys-manager): support @boundary/@error error-boundary block Adds forward-compat support for Angular's upcoming @boundary/@error error-boundary block (angular/angular#70463, targeted for Angular 22.2), mirroring the existing @switch/@if handling. - compiler-compat.ts: guarded TmplAstBoundaryBlock/TmplAstBoundaryErrorBlock structural types + type guards, so it compiles today and picks up the real compiler exports transparently once shipped. - utils.ts: wired the new block into the generic block-walker so both directiveExtractor and structuralDirectiveExtractor traverse into it with no extractor-specific changes. - compiler-compat.spec.ts: guard-rejection unit tests. - verify-keys-manager-compat.mts: added a real @boundary/@error fixture, gated by a new supportsBoundaryBlock(version) check (mirrors the existing supportsGroupedCases gate for Angular 21.1). - ci.yml: new keys-manager-compat matrix entry pinned to '>=22.2.0-next.0 <22.3.0', marked experimental (continue-on-error) since it tracks an unreleased Angular prerelease; verified locally against the real @angular/compiler@22.2.0-next.7. * chore(keys-manager): track stable Angular 22.2 in compat matrix Angular 22.2 is released, so the @boundary/@error support no longer needs prerelease handling. - ci.yml: drop the experimental >=22.2.0-next.0 matrix entry; the floating '22' entry now resolves to 22.2 and gates merges. - verify-keys-manager-compat.mts: revert the '='-safe arg parsing and the --legacy-peer-deps prerelease handling, no longer needed. - Reword comments from future to past tense. * fix(keys-manager): parse compat script args at first = The script advertises --angular=<range>, but split('=') truncated any value containing its own '=', such as '>=22.2.0 <22.3.0'. Split each option at its first '=' only so the full range reaches npm. * test(keys-manager): add @boundary/@error extraction spec
| Back | FazBrowse Home | New Git URL |
Introduces a declarative way to catch rendering errors in templates using the new @boundary block, preventing local failures from crashing the entire application hierarchy.
@boundary { <complex-chart [data]="data" /> } @error (let err = $error; let r = $retry) { <p>Failed to load chart: {{err.message}}</p> <button (click)="r()">Retry</button> }Additionally, this adds programmatic error handling for dynamically created views by introducing an onError option to ViewContainerRef.createComponent,createEmbeddedView and the standalone alone createComponent function:
Additional changes:
Note: most of design & implementation was done by @alxhub.
Note2: Docs on the feature will be addressed in a follow-up PR.