feat(core): allow synchronous values for stream Resources#67382
feat(core): allow synchronous values for stream Resources#67382JeanMeche wants to merge 1 commit intoangular:mainfrom
Conversation
36e3d85 to
2ce9752
Compare
| expect(() => res.value()).toThrowError(/Resource completed before producing a value/); | ||
| }); | ||
|
|
||
| it('should report sync error synchronously (after tick) ', () => { |
There was a problem hiding this comment.
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)', () => { |
There was a problem hiding this comment.
This is somewhat of a breaking change. Before that the error was only visible on tick.
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.
2ce9752 to
2071eab
Compare
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