How to get dynamic route params from Server Components?

[rinald-ta]

Summary

With the new app router, dynamic parameters are provided to certain server components like layout and page through the params prop. For other server components used inside a layout or page, it appears that it is necessary to pass any dynamic params as props, since context doesn't work for server components.

I am also aware that there is a useParams hook, but that only works for client components.

Am I missing something here? Is there a cleaner way to provide dynamic params (or search params) to nested server components in a page? Is prop drilling the only option for now?

Additional information

No response

Example

No response

[icyJoseph]

Hi,

This is in the docs, and the solution is to just use JavaScript.

• https://nextjs.org/docs/getting-started/react-essentials#sharing-data-between-server-components

Since Server Components are not interactive and therefore do not read from React state, you don't need React context to share data. Instead, you can use native JavaScript patterns for common data that multiple Server Components need to access. For example, a module can be used to share a database connection across multiple components:

Though it is not very easily found I guess.

So you could do for example:

// app/store.tsx
const createStore = () => {
  let data: string | null = null;

  const setData = (next: string) => {
    data = next;
  };

  const getData = () => {
    return data;
  };

  return { setData, getData };
};

export const store = createStore();

And then at say:

// app/[foo]/[bar]/page.tsx

import { Outer } from "../../Outer";
import { store } from "../../store";

export default function Page({
  params,
}: {
  params: { foo: string; bar: string };
}) {
  const { foo, bar } = params;
  store.setData(`/${foo}/${bar}`);
  return <Outer />;
}

And then you'd have:

import { Inner } from "./Inner";

export const Outer = () => {
  return <Inner />;
};

Where, finally, Inner, just reads the data:

import { store } from "./store";

export const Inner = () => {
  return <div>{store.getData()}</div>;
};

[VaghikSoghomonyan]

Hey,
Thanks for sharing this! It’s a cool way to handle data between server components. But I’m a bit worried about what happens when two users hit the server at the same time. Looks like there could be a race condition with the shared store module where one user’s data might overwrite the other's. Since the store isn’t tied to individual requests, data could get mixed up, right?

Is there a way to tie the data store to each request to avoid this? Or maybe there's another workaround to keep the data straight when multiple users are making requests at the same time?

[icyJoseph]

Hi,

Yeah, someone else already run into that issue. And they shared a package they used to get around it, let me find it for you.

[icyJoseph]

Here you go:

• https://github.com/manvalls/server-only-context#readme

For context on the issue: #50405

[ludo237]

Try to avoid unnecessary store as much as you can as a good practice

[eric-burel]

The store described in this post is not user specific and currently corresponds to Next.js unstable_cache basically. To avoid props drilling it's more usual to rely on React cache which is scoped to the current user request (= one server render), which powers the server-only-context lib shared just a few comments above.

[smail-boundaoui]

export default function ServerComponentPage({ params, searchParams }) {
console.log(params)
console.log(searchParams)
return
}

[smail-boundaoui]

https://nextjs.org/docs/app/building-your-application/routing/dynamic-routes#optional-catch-all-segments

[Basovs]

I didnt understood this solution provided by @smail-boundaoui ... Can some1 explain?

[Muhammad-Umar-Khan]

@Basovs what you need help with?

[zjy365]

Yes, this is correct, the reason is here https://nextjs.org/docs/app/api-reference/file-conventions/page

[anotheroneofthese]

You might miss it in the documentation smail-boundaoui linked, but in later versions of NextJS you need to specify that it is a Promise.
For example, using an API route to the page /api/[id]/details, you might want:

export async function GET(
  _: NextRequest,
  { params }: { params: Promise<{ id: string }> },
  { searchParams }: { searchParams: Promise<{ id: string }> }
) {
  // rest of your code
}

[fallenleavesguy]

by the way. if you are using next-intl, you can get locale by using import { useLocale } from "next-intl";

[Eunit99]

How to use?

import { useLocale } from "next-intl";

...

  console.log(useLocale()); // en

[rechenberger]

Hey everybody,

just built a library to handle this problem:
https://www.npmjs.com/package/@sodefa/next-server-context
It uses AsyncLocalStorage

---

How to use:

/app/[myParam]/page.tsx

import { pageContext } from '@sodefa/next-server-context'
import { NestedServerComponent } from './NestedServerComponent'

export default pageContext.Wrapper(({ params, searchParams }) => {
  return (
    <>
      <h1>MyPage</h1>
      <NestedServerComponent />
    </>
  )
})

/app/[myParam]/NestedServerComponent.tsx

import { pageContext } from '@sodefa/next-server-context'

export const NestedServerComponent = () => {
  const { params, searchParams } = pageContext.getOrThrow()
  return <div>NestedServerComponent: {params.myParam}</div>
}

[eric-burel]

Did you benchmark this? What bothers me is that you are creating an AsyncLocalStorage, on top of the one already created by Next.Js, so you may pay an overhead price twice. Using React cache lets you use the AsyncLocalStorage that Next.js already creates for you instead of writing your own, I would favour that (server-only-context approach). But a benchmark would help telling if I am wrong or not.
Your tool might be cool to setup observability though.

[DenisBessa]

That's a very cool idea and library. But I'm worried about the implications of using it for PPR and other Next.js optimizations. Does anybody has some info about it?

[mercurydiogo]

Is there a native Next.js solution for this yet? If not, what might be the reason it hasn't been done? Feels like a pretty common problem in my mind

[shanehoban]

Yes, see a couple of comments above: #51818 (comment)

[mercurydiogo]

This is for a page though, not a component. Right?

[shanehoban]

Yes but pages/routes are where these parameters come from, so you can pass them to child components of the page that are still server rendered, or use hooks (when unable or not within scope for whatever reason) in a client component.

[shanehoban]

To clarify, a standalone server component would be unaware of route parameters without being passed them specifically from the page/route that they originate from.

[mercurydiogo]

Yes but pages/routes are where these parameters come from, so you can pass them to child components of the page that are still server rendered, or use hooks (when unable or not within scope for whatever reason) in a client component.

Yes, this is what is in the docs. But why shouldnt you be able to use conditional logic on the parameter (in a server component) without prop drilling just like usual useParams.

I don't understand why this is a technical challenge for nextjs

I'm sure I'm just missing something fundamental, but I don't understand what.

If anyone could elucidate me, I'd be much appreciated

[laurent512]

Any update on that ? Quite important to me to get dynamic url segment inside server components without deep props drilling :/

[devajakamerus]

You could simply reuse the asynclocalstorage that the framework uses internally and access request details thru it. Similar to how cookies() and headers() work. Probably not the best idea but works fine, this definitely should be builtin.

`import { staticGenerationAsyncStorage } from "next/dist/client/components/static-generation-async-storage.external";

export default function Test() {
const store = staticGenerationAsyncStorage.getStore();
if (!store) {
return null; // ...
}
return (
< main>

Request url was : {store.urlPathname}

< /main>
);
}
`
E: i don't know why the formattin just breaks, well you get the idea

[indicozy-eyewa]

A better approach I see is to use headers in middleware:

// middleware.js
  const res = NextResponse.redirect(url);
    res.headers.set('x-store', storeCode);
    return res

// server side
  const headerModule = require('next/headers');
  return headerModule.headers().get('x-store');

[mhmdAljefri]

I prefer using cookies in middleware.ts and then get value of it there for themes and local as well. but it can be used as you need.

// middleware.ts
export function middleware(request: NextRequest) {
  const response = NextResponse.next();
  response.cookies.set('lang',getLocalByRoute );

  return response
};

and in SSC

import { cookies } from "next/headers";

export default function ButtonWithTranslations() {
  const lang = cookies().get("lang")?.value || "en";

  // rest code
}

[EricWVGG]

I'm trying so hard to be an optimist about this whole "server components" thing, and then I crash into a problem so dumb and obvious…

I absolutely cannot believe the App Router got pushed out the door without this sort of basic functionality. Every solution I've seen on this page makes sense but is ultimately a creaky hack over something that is just fundamental to the very concept of a server component. Augh.

[DrPye]

Using default javascript patterns instead is not a creaky hack.

Just move back to the pages router until your more comfortable with RSC