feat(core): allow synchronous values for stream Resources - #67382
Conversation
36e3d85 to
2ce9752
Compare
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. |
2ce9752 to
2071eab
Compare
2071eab to
d702b7b
Compare
d702b7b to
a4b2585
Compare
|
|
||
| // @public | ||
| export type ResourceStreamingLoader<T, R> = (param: ResourceLoaderParams<R>) => PromiseLike<Signal<ResourceStreamItem<T>>>; | ||
| export type ResourceStreamingLoader<T, R> = (param: ResourceLoaderParams<R>) => Signal<ResourceStreamItem<T>> | PromiseLike<Signal<ResourceStreamItem<T>>> | undefined; |
There was a problem hiding this comment.
nit: Should we have a helper type in core somewhere that's type Awaitable<T> = T | PromiseLike<T>;? I think this could be useful elsewhere as well. It's too bad there isn't a built in like there is "Awaited"
| return; | ||
| } | ||
|
|
||
| this.state.set({ |
There was a problem hiding this comment.
We can share this with the block below if we rearrange things so stream is the final signal and we use something like rawStream or loaderResult for the raw loader output. It'd make the flow here clearer.
thePunderWoman
left a comment
There was a problem hiding this comment.
reviewed-for: public-api
a4b2585 to
4ca1ece
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.
87a6c47 to
ddcf536
Compare
|
caretaker note: I'll need to submit cl/877332112 at the same time as this change |
|
This PR was merged into the repository. The changes were merged into the following branches:
|
The time has come. Note: angular#67382 introduced a breaking change where you could notice some sublte timing change on how `value` is set when using `rxResource` or a `stream` on a `resource`
The time has come. Note: angular#67382 introduced a breaking change where you could notice some sublte timing change on how `value` is set when using `rxResource` or a `stream` on a `resource`
The time has come. Note: #67382 introduced a breaking change where you could notice some sublte timing change on how `value` is set when using `rxResource` or a `stream` on a `resource`
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
|
I've added the breaking change label to this change since this was indeed breaking some unit tests that relied on the assuption that resource will only resolve the value asynchronously. |
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