DEV Community

Using React Context in NextJS Server Components

Browny on May 24, 2023

Most React applications rely on context to share data between components, either directly via createContext, or indirectly via provider components ...

Read full post

Jonathan Ludeña • Sep 8 '23

I have a Provider to which an environment variable (api key) is inserted. Do you think it could work to protect this API key from being rendered on the client side? I am using React's GoogleRecaptcha v3 provider to wrap a form

Browny • Sep 11 '23

Protecting sensitive information like an API key in a React application is crucial to prevent it from being exposed on the client side. However, when using a React Provider to manage environment variables, you should be aware that anything you include in your client-side JavaScript code, including environment variables, can potentially be accessed by users with the right knowledge and tools. Therefore, it's essential to use additional security measures to protect sensitive data.

Jonathan Ludeña • Sep 12 '23

Could you recommend some way in which you have been able to protect this information on the client side. I've been thinking about using secrets, but they can be used from the server side, and react's Recaptcha version 3 provider inserts it from a provider component. If you can help me, I would really appreciate it.

Browny • Sep 12 '23

It is important to know that context providers primarily work on the client side within the react application. They allow you to control which data is shared or passed down to components. You define the methods you want to expose via the context provider and only components explicitly accessing the context will receive the data. While context providers do not inherently exposes data to the client, you should still be cautios about what data you put into context and who have access to it.

Here are some the practices I would reccomend.

Server-Side Rendering (SSR):
Utilize server-side rendering to render the initial HTML page on the server and inject the API key on the server side. This way, the API key won't be visible in the client-side JavaScript. You can use libraries like Next.js for SSR in React applications.

Environment Variables:
Store sensitive data like API keys as environment variables on the server-side.
NextJs has built-in support for enviroment variables or you can leverage on the env support from your deployment provider.
These environment variables should be kept confidential and not exposed in your client-side code. You can access these server-side environment variables when making API calls on the server.

Proxy Server:
Implement a server-side proxy that handles API requests to the third-party service. Your React application can make requests to your proxy server, which will then use the API key to communicate with the external service. This way, the API key is never exposed on the client side.

Limited Scope API Key:
If possible, obtain or generate an API key that has limited permissions or access rights. This way, even if it were exposed, it would have minimal impact. For example, if your API key is only used for read operations, restrict it to read-only access.

Encryption:
If you must include the API key in your client-side code, consider encrypting it and decrypting it on the server when needed. This adds an additional layer of security.

Protect API Key Storage:
Make sure that your API key is not stored in a way that can be easily accessed or retrieved from your client-side code. Avoid storing it in local storage, session storage, or cookies, as these can be accessed by client-side scripts.

Use Google reCAPTCHA Securely:
When using Google reCAPTCHA, follow Google's guidelines and best practices for handling API keys and client-side integration. Google provides guidance on how to keep your API key secure when using their services.

I hope this helps.

Gildemberg Leite • Mar 15

It's a valid tip, but it doesn't allow using the context, but rather importing the context provider into a server component.

Scott Mackenzie • Jul 28 '23

Super helpful. Thanks for clarifying. I guess the default/initial output of any provider matters since it will be the first thing seen before the client takes over?

Browny • Aug 6 '23

Yeah
That's correct

Snehil • Nov 8 '23

If the parent of a server component is a provider, which is a client component; would it benefit from being a server component?
e.g.
in Parent > ChildA > ChildB('use client'), parent and childA can benefit from server components.
by doing the above, Parent > ContextProvider('use client') > ChildA > ChildB('use client'), does ChildA benefit from being a server component as its wrapped in a client component..

Mister Singh • Jan 4

yes ChildA in your example does benefit. this is because if ChildA is a server component, it is still being built on the server and gets all benefits of sever side rendering like fetch memoization, data cache, & full route cache.
with that said it is import to know how ChildA was put in the parent context provider client component. it needs to go in as part of the children. this means that it is not being imported in childA, but rather being passed in from above as a prop. this is what allows it to be server side rendered.
there is so important that they even named this pattern. It is called the interleaving pattern.
in general you can benefit by reading this part of the documentation
nextjs.org/docs/app/building-your-...

George Fonseca • Nov 14

It seems like the context is reset every time it navigates to another route. Am I missing something?

./app/layout.tsx
... return ( <html lang={params.lang}> <body className={roboto.variable}> <SessionContextWrapper>{children}</SessionContextWrapper> </body> </html> );

Ebenezer Amaraiwu • Mar 30

is there a way to do async operations inside Provider wich is client component , here is what i want to achieve

'use client'

import authicatedUser
import { createContext, useContext } from 'react'

interface User {
  id: string
  fullName: string
  username: string
  role: string
}

const UserContext = createContext<User | undefined>(undefined)

export const useUserContext = () => {
  const user = useContext(UserContext)

  if (user === undefined) {
    throw new Error('useUserContext must be used within a UserProvider')
  }
}

export default async function UserProvider({
  children,
}: {
  children: React.ReactNode
})
const { user } = await authenticatedUser()
{
  return <UserContext.Provider value={user}>{children}</UserContext.Provider>
}

Browny • May 25 '23

Please don't hesitate to leave a comment if you find this post useful or have a suggesstion.

Salih Dhaifullah • Jan 2 • Edited

is this will make all the components client side rendered

Mister Singh • Jan 4

no. this does not make all children components automatically client side.
children components will be server side by default and client side if they are so marked.
this happens because the context provider wrapping component did not import the children component, there are in fact just passed in as props and all the provider component is doing is deciding where to place them so they render there.
hope that helps

Annan Junior • Nov 5

I have context that I want to pass its values throughout my Next js app.
I have the context in the layout.tsx file. Within the layout.tsx file, I also have my Navbar, Header and Footer components. Now the issue is, the context values can be used in the aforementioned components, but not in the children component. In development everything works fine but in production (trying to host it on Vercel), I get issues that the context values are not accessible. It doesn't even work with ClerkProvider as well so obviously the problem is not from my context provider. Please help me fix it.

Arian94 • May 5

"If these providers include the "use client" directive, they can be rendered directly inside of your Server Components."

I think the word "rendered" should be "pre-rendered" in this sentence.
A client component cannot literally be rendered inside a server component.

Jan Prchal • Jan 31

By using a context provider at the root of your app, could there be a decreased rendering speed at the initial load? Assuming that all the server-side components will be shown only after the state provider had done its thing in the browser? Could there be a speed benefit by using something like zustand where you don't need to use a provider? Thanks.

minami • Nov 12

It's just a copy of Official document.