RFC: serialization of route loaders data #227
Replies: 5 comments 9 replies
-
|
Would it affect the "prefetching" strategy? If the data is lazy loaded, it will introduce an extra delay visible to the user while the data is fetched, which will affect negatively the user experience. It would have to be tested/benchmarked, but my feeling is that the extra time it takes to serialize data that is unused is less affecting the UX than a whole new server call (extra delays on user interaction) to fetch the data when needed. Also, should it be the other way around? By default it's serialized (like it is right now) when we can make sure data won't be needed, but you can pass an option (e.g. |
Beta Was this translation helpful? Give feedback.
-
|
👍 but maybe Also, we have the reverse problem with contexts, where we always skip them if we don't see them being used during SSR. Maybe there we should add These could be slightly breaking changes to add to v2.0 |
Beta Was this translation helpful? Give feedback.
-
|
It feels like this will mean developers must always think about the potential UX interaction delays when using data from a routeLoader$ If we reverse this proposal to allow an option called ‘lazy: true’ then it’s clear the data will only be fetched when it’s needed and that it will potentially impact UX. |
Beta Was this translation helpful? Give feedback.
-
|
Probably this is for a different RFC, but we need a mechanism where we can invalidate routeloader data, separate from browser cache. q-data is only requested for SPA, which means we have full control. If we determine a loader should be updated, we can fetch it with no-cache. We can even decide to show the old data in the meantime, or to block on the load. What we need on the client is:
For 1 we could use a simple timeout. We should also allow some function$ that returns a boolean? For 2 we can create a nested object that represents the paths, including aliases and wildcards. At each level it lists the loaders. If there are no loaders from a certain path, the subtree is empty. The loader configuration is provided as part of the leader result, because you only need to know it when you already loaded is data. The loader config requires finding all loader exports in the routes at build time. We can do this by checking the display names of exported QRLs. |
Beta Was this translation helpful? Give feedback.
-
|
The PR has been merged |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
What is it about?
Reducing the size of the initial rendered HTML, by being smarter at which data to serialize from the route loaders.
What's the motivation for this proposal?
Problems you are trying to solve:
Let's say we have the following route loader:
Currently we are able to tree shake (or "Data Shake" ™) route loaders data in some simple cases, for example if only a portion of that data is being used.
Example:
But when the component has a condition which affects its rendering, there is no way for Qwik to know whether its data will be required by one of the children of that component (or grandchildren), so the optimizer marks a component as dynamic and all loaders data are serialized, even if the data are not required later.
Due to the
{condition.value ? <Child /> : <div/>}condition, the component is marked as dynamic. This is because we don't know if the<Child />component calls theuseProductDetails(). In that case, we need the data for the<Child />component.Goals you are trying to achieve:
Any other context or information you want to share:
Proposed Solution / Feature
What do you propose?
The loader data will never serialized from context. After SSR, the data will always be discarded.
If a child component uses the route loader again, we will lazy load the data as needed.
Additionally, provide an option
serializationStrategy: 'never' | 'always' | 'auto'torouteLoader$to serialize the state anyway if developers want it.export interface CommonLoaderActionOptions { readonly id?: string; readonly validation?: DataValidator[]; + readonly serializationStrategy?: SerializationStrategy; }Code examples
In above example the
useProductDetailsdata are not serialized.If the
Childcomponent is rendered, the data are lazy loaded through the server.In above example the
useProductDetailsdata are serialized, becauseserializationStrategy: alwaysoption is passed.If the
Childcomponent is rendered, the data are reused from state.Links / References
No response
Beta Was this translation helpful? Give feedback.
All reactions