Pinia data fetching? and when to use clientonly
so I have a nuxt application that uses a pinia action to load some data from an API. is this an okay way to do it? the data needs to be available in several routes. also, I'm wondering how folks decide if a route should wait for this data or if it should use clientonly and suspense manually? essentially I want the data fetched once the user navigates to (or is redirected to from the oauth sign in page) the dash route and then for that same data to be available for all sub-routes of /dash
2 Replies
Hi @Mae. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Using a Pinia action to load data from an API in a Nuxt application is a common and valid approach, especially when the data needs to be shared across multiple routes. Nuxt supports Pinia as a state management solution, and you can initialize or fetch data in a Pinia store and then access it from any component or page that needs it. This is particularly useful for global or user-specific data, such as user profiles or settings, that should persist across different parts of your app State Management.
When to use client-only fetching:
- If the data is not required for SEO or initial page render, or if it depends on client-only context (like user authentication after OAuth), you can use the
- Use Pinia for shared state. - Use client-only fetching if SSR is not needed. - Use SSR/blocking fetch if you want to guarantee data before render. - Handle loading states if using client-only or lazy fetching. Let me know if you need a code example for this pattern! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
server: false option with useFetch or your Pinia action to fetch data only on the client. This means the data will not be available until after hydration, so you must handle loading states appropriately Client-only fetching.
When to block navigation (SSR) vs. client-only:
- If you want the route to wait for the data before rendering (e.g., the dashboard should not show until user data is loaded), you can fetch the data server-side or use the default behavior of useFetch/useAsyncData, which blocks navigation using Vue's <Suspense>. This ensures the data is available on first render, both for SSR and CSR Suspense.
- If you prefer a snappier navigation and are okay with showing a loading state while the data loads, use the lazy: true option or useLazyFetch/useLazyAsyncData. This will not block navigation and lets you control the loading UI Lazy.
Best practice for your scenario:
- For data that should be fetched once when the user lands on /dash (after OAuth) and then be available for all /dash/* subroutes, you can:
1. Fetch the data in a Pinia action when the user lands on /dash.
2. Store it in Pinia state.
3. Access the state in all subroutes/components as needed.
- If the data is not needed for SSR or SEO, consider using server: false and/or lazy: true to fetch it client-side and avoid blocking navigation.
- If you want to ensure the data is always available before rendering /dash and its subroutes, fetch it server-side or block navigation using the default behavior.
Important: Avoid using useAsyncData or useFetch inside Pinia actions for side effects, as this can cause issues with repeated execution and SSR hydration. Instead, use $fetch inside your Pinia actions for direct API calls, and use the Nuxt composables in your components/pages for data fetching that should be SSR-aware docs: add context for useAsyncData side effects.
In summary:- Use Pinia for shared state. - Use client-only fetching if SSR is not needed. - Use SSR/blocking fetch if you want to guarantee data before render. - Handle loading states if using client-only or lazy fetching. Let me know if you need a code example for this pattern! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@278717080952504322> Kapa.ai is still learning and improving, please let me know how I did by reacting below.