Next.js Discord

Discord Forum

Do we really need context in next 14+ to share user data across pages ?

Answered
Northeast Congo Lion posted this in #help-forum
Open in Discord
Northeast Congo LionOP
This is just straightforward question. With NextJS latest updates since v14 I wonder if we still need to use the Context API to share user data among components/pages.
Or can it just be replaced with regular fetch call backed with Nextjs built-in caching features or the cache function from React ?
Answered by B33fb0n3
@Northeast Congo Lion to conclude everything:
- If you are using a context provider inside your layout it should persists it's state
- Fetch request for the specific page as you never know if the person was already on another "sign in - required" page
- Both works fine so do whatever feels best for you
Is your initial question answered like that?
View full answer

17 Replies

@Northeast Congo Lion This is just straightforward question. With NextJS latest updates since v14 I wonder if we still need to use the Context API to share user data among components/pages. Or can it just be replaced with regular fetch call backed with Nextjs built-in caching features or the cache function from React ?
you can use provider and that's possible and works fine, but it would also work to fetch data again. Both works fine so do whatever feels best for you. When using fetch, you can leverage from caching, when using the context, you can leverage the clientside states
Northeast Congo LionOP
Regarding performance and security which one would you choose since using context means also using localStorage to keep the data across navigation ?
American black bear
I don't think context uses localStorage
Security should be the same as long as you check authorization on server
@Northeast Congo Lion Regarding performance and security which one would you choose since using context means also using localStorage to keep the data across navigation ?
If you are using a context provider inside your layout it should persists it's state and of course: check auth on the server, don't cache it and don't check it in your layout. Valid locations are: middleware, page, server action, route handler
@American black bear I don't think context uses localStorage
Northeast Congo LionOP
A little misunderstanding here I'm not saying context uses localStorage, I said to keep the data across page refresh and navigation localStorage would be involved.
Got it on the security aspect, thanks!
@B33fb0n3 If you are using a context provider inside your layout it should persists it's state and of course: check auth on the server, don't cache it and don't check it in your layout. Valid locations are: middleware, page, server action, route handler
Northeast Congo LionOP
So using layout with the context we can bypass localStorage even on page refresh ?
The whole point here is not actually validation. I want to know what you guys prefer when it comes to sharing user data across in a reliable and efficient way.
Do you go for a getUserData() inside pages or layouts and rely on caching or useUserData() with the Context API
Northeast Congo LionOP
Ok fair enough, so you would not rely on Next built caching ? I think fetch requests are automatically cached if you don't opt out.
@Northeast Congo Lion Ok fair enough, so you would not rely on Next built caching ? I think fetch requests are automatically cached if you don't opt out.
not rely on Next built caching
you can rely on the caching from nextjs, but it's a data cache. So it's shared with other users. And you don't want to share your auth data with other users.

fetch requests are automatically cached
you are right for <next14. For next15 they are opt in
Northeast Congo LionOP
it's a data cache. So it's shared with other users
Got it ✅
@American black bear it doesn't have to be in localStorage since you can create context in a parent layout
Northeast Congo LionOP
Thanks I didnt now that it was possible
@Northeast Congo Lion to conclude everything:
- If you are using a context provider inside your layout it should persists it's state
- Fetch request for the specific page as you never know if the person was already on another "sign in - required" page
- Both works fine so do whatever feels best for you
Is your initial question answered like that?
Answer
Northeast Congo LionOP
Yes sure, it's definitely fully answered
Thanks for your time and kindness
happy to help