Skip to content

feat(core): allow synchronous values for stream Resources#67382

Open
JeanMeche wants to merge 1 commit intoangular:mainfrom
JeanMeche:resource-stream-sync
Open

feat(core): allow synchronous values for stream Resources#67382
JeanMeche wants to merge 1 commit intoangular:mainfrom
JeanMeche:resource-stream-sync

Conversation

@JeanMeche
Copy link
Member

@JeanMeche JeanMeche commented Mar 2, 2026

In order for resources to allow caching in SSR context (eg in the TransferState), resource need to be able to set their value synchronously.

If the resource value is not set synchronously, the resource will be in in a "loading" state which is responsible for destroying the server-hydrated resolved DOM.

Related to #62897

@angular-robot angular-robot bot added detected: feature PR contains a feature commit area: core Issues related to the framework runtime labels Mar 2, 2026
@ngbot ngbot bot added this to the Backlog milestone Mar 2, 2026
@JeanMeche JeanMeche force-pushed the resource-stream-sync branch 18 times, most recently from 36e3d85 to 2ce9752 Compare March 2, 2026 21:29
expect(() => res.value()).toThrowError(/Resource completed before producing a value/);
});

it('should report sync error synchronously (after tick) ', () => {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is somewhat of a breaking change. Before that the error was only visible on tick.

expect(count).toBe(1);
});

it('should report error synchronously (after tick)', () => {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is somewhat of a breaking change. Before that the error was only visible on tick.

@JeanMeche JeanMeche requested a review from alxhub March 2, 2026 21:32
@JeanMeche JeanMeche marked this pull request as ready for review March 2, 2026 21:32
@pullapprove pullapprove bot requested a review from atscott March 2, 2026 21:32
@atscott
Copy link
Contributor

atscott commented Mar 2, 2026

else users will observe flickers when resource switches between 'loading'/'resolved'

I think it should be clear that this goes deeper than a "flicker". its first render will destroy the server-hydrated resolved DOM. This might cause flashing (or it might not) but it does cause event replay, user interaction in the meantime, etc to be lost. The flicker could be addressed in a different way (e.g. not having macrotask scheduling) but the hydration issue cannot be addressed by a change to scheduling.

In order for resources to allow caching in SSR context (eg in the TransferState), resource need to be able to set their value synchronously.

If the resource value is not set synchronously, the resource will be in in a "loading" state which is responsible for destroying the server-hydrated resolved DOM.
@JeanMeche JeanMeche force-pushed the resource-stream-sync branch from 2ce9752 to 2071eab Compare March 2, 2026 23:06
@JeanMeche JeanMeche mentioned this pull request Mar 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: core Issues related to the framework runtime detected: feature PR contains a feature commit

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants