-
-
Notifications
You must be signed in to change notification settings - Fork 353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve data fetching tool integration with the HTML stream? #1689
Comments
@brillout Can you share what the DX would look like for fetching data on layout-level with If |
It's only meant for generating the cache key for data-fetching tools that use a cache such as TanStack Query.
Would |
Here is the example I'd like to achieve: https://svelte-layout-data.netlify.app/ The submenu under
To me, the opportunity of nested layouts is not just to avoid duplicating markup, but to avoid duplicating data fetching code across multiple page hooks. I can work around things for my use case, but I feel like Vike's data loading story for nested layouts would be improved with layout hooks. The way Svelte handles this is very elegant. Layouts can define data fetching hooks, just like pages. Here is the routing / data-fetching hierarchy for the above example.
Full repo here, in case you'd like to look in more depth. |
By the way, I think the question of where layout data fetching happens is orthogonal to whether nested layouts need to rerender on route change. I think I'm advocating for an implementation that allows layouts to have their own (I think avoiding re-rendering nested layouts is a nice optimization, but it's separate and could come later. In the meantime, devs could continue relying on query caching and/or component memoization to make route changes cheap.) |
You can use config inheritance to avoid that.
Precisley: if you colocate
I think you have a point about nested layouts and data fetching, let me think about it. |
After mulling it over a bit, I agree with you. I went ahead and created a feature request for it: #1833 - Make So you'll be able to have this: # Data shared across all pages
pages/+data.js
pages/+Layout.js
# Data shared across all setting pages
pages/settings/+data.js
pages/settings/+Layout.js
# Data only used by one page
pages/settings/privacy/+data.js
pages/settings/privacy/+Page.js Would that work for you? In the meantime, is using
Hm, I think Vike can (and I think should) do some caching for
In the example above:
Edit: +data cache update: #1833 (comment). |
@brillout excellent news!
I'm glad you brought up using config inheritance to co-locate
Yes, I can work around this in the meantime, but I will be very excited to migrate to cumulative (And your Thanks for being open to consider this! |
Thank you for the constructive conversation! We're a little bit busy with a couple of priorties at the moment, but I do consider #1833 high priority so you can expect this coming reasonably soon. Btw. in case your company is up for it, we're loooking for sponsors (#1350), it makes a massive difference for us. |
By using Vike extensions, such as vike-react-query and soon vike-react-telefunc, you can fetch data on a component-level (thus on a layout-level as well).
Since TanStack Query is caching independently the URL, it just works. That said, there is potential for improving the caching behavior.
Note
Data fetching Vike Extensions already have a cache (they always need to), so it's just a matter of configuring the cache.
Technical details.
Approach A
vike-{react,vue,solid}
provides a new component hookuseDataCacheKey()
that returns a key composed of:Vike extensions can then use the key to cache data. In other words, the behavior is exactly as the website visitor expects: data is re-fetched only when navigating the relevant parts of the UI.
Approach B
Alternatively,
vike-{react,vue,solid}
wraps the nested layouts in a stateful wrapper component (e.g. using React'suseState()
). Upon navigation, the state of the appropriate wrapper components is updated to trigger a re-render of nested layouts (the page and outer layout aren't re-rendered). But, so far, I think Approach A is superior. (For example, I don't see how Approach B can support the use case when the user clicks on the active link merely to refresh the page.)The text was updated successfully, but these errors were encountered: