标签：#approuter

The symptom is simple: you open /dashboard?search=invoice&page=2 , copy an old snippet, and get undefined , stale values, or the wrong API entirely. The root cause is that Next.js now has two routing models, and the correct query-string API depends on where you read the params: App Router Server Component page: use the searchParams prop App Router Client Component: use useSearchParams() Shared client component across both routers: useSearchParams() still works Here is the exact fix for each case. The App Router server-side fix If you are inside app/.../page.tsx , use the page prop. In the current Next.js docs, searchParams is a promise in modern App Router pages. // app/dashboard/page.tsx export default async function Page ({ searchParams , }: { searchParams : Promise < { [ key : string ]: string | string [] | undefined } > }) { const { search = '' , page = ' 1 ' } = await searchParams return ( < main > < h1 > Dashboard </ h1 > < p > Search: { search } </ p > < p > Page: { page } </ p > </ main > ) } Use this when the query string affects data fetching, pagination, filtering, or metadata for the page itself. The App Router client-side fix If the component is interactive and already marked 'use client' , use useSearchParams() from next/navigation . ' use client ' import { useSearchParams } from ' next/navigation ' export default function SearchSummary () { const searchParams = useSearchParams () const search = searchParams . get ( ' search ' ) ?? '' const page = searchParams . get ( ' page ' ) ?? ' 1 ' return ( < p > Searching for < strong > { search || ' everything ' } </ strong > on page { page } </ p > ) } Two details matter: useSearchParams() is read-only. In the App Router docs, Next.js explicitly recommends the page searchParams prop if you are already in a Server Component page. The shared-component pattern that survives both routers This is the cleanest answer if you are migrating gradually or sharing a search bar between pages/ and app/ . ' use client ' impo

Sanity Embeddings semantic search in Next.js is one of those features that looks complicated from the outside but is surprisingly lean to wire up once you understand the moving parts. This post covers the current native Embeddings feature built into Sanity datasets — not the older Embeddings Index API, which Sanity is sunsetting. If you found a guide that talks about a separate embeddings-index resource you have to provision via the Management API, it is stale; skip it. What Sanity Embeddings actually is Sanity's native Embeddings feature lets you mark document types for vector indexing directly inside your dataset. Sanity handles the embedding model and the vector store; you never manage a separate service. Queries use a dedicated sanity.embeddings.query GROQ function that takes a natural-language string and returns documents ranked by semantic similarity. The feature is available on Growth and Enterprise plans as of mid-2026. The workflow has three parts: Configure which document types get indexed (dataset setting or the Embeddings pane in Sanity Studio). Run a semantic query from your Next.js route handler using the Sanity client. Render the results in a search UI component. Setting up the embeddings index in your dataset Go to Manage → your project → Embeddings (or open the Embeddings pane inside Sanity Studio if your plan surfaces it there). Create an index, give it a name (e.g. site_search ), and select which document types and fields to embed. For a blog you would typically pick post with fields title , excerpt , and body (plain text extracted from Portable Text). Sanity backfills existing documents automatically. New and updated documents are re-embedded on publish via an internal webhook — you do not configure that yourself. There is no code required for the indexing step. The index name you choose here ( site_search ) is what you will pass in the GROQ query. Querying embeddings from a Next.js route handler Create a route handler that accepts a search term,