Resolves a TypeScript error in `app/search/page.tsx`:
"Type error: Argument of type 'any[] | undefined' is not assignable to
parameter of type 'SetStateAction<any[]>'."
The `getSearchResults` function has been updated to:
1. Explicitly define its return type as `Promise<any[]>`.
2. Ensure that all code paths return an array, defaulting to an empty
array `[]` if no specific or generic results are found, or if the
query is empty/whitespace.
This guarantees that `setResults` always receives an array, satisfying
the type constraints of `useState<any[]>`.
This commit applies the Next.js 15 PageProps convention (where `params`
and `searchParams` are Promises) to all relevant dynamic server route
page components. This resolves the build error:
"Type '...' does not satisfy the constraint 'PageProps'.
Types of property 'params' are incompatible.
Type '{...}' is missing the following properties from type 'Promise<any>': then, catch, finally, [Symbol.toStringTag]"
The following pages were updated:
- `app/content/[slug]/page.tsx`
- `app/product/[handle]/page.tsx`
- `app/search/[collection]/page.tsx`
In each of these files, the props interface was updated to define
`params` and `searchParams` as Promises, and the component logic
was modified to `await params` to access their resolved values.
`app/search/page.tsx` was verified as a Client Component using
`useSearchParams()` and did not require these changes.
This commit resolves a persistent TypeScript build error:
"Type 'ContentPageProps' does not satisfy the constraint 'PageProps'"
in `app/content/[slug]/page.tsx`.
The `ContentPageProps` interface has been updated to include the
`searchParams` property, aligning it with the expected structure
for Next.js page components in the App Router. This ensures
compatibility with Next.js's internal type definitions for async
server components.
This commit resolves the persistent TypeScript build error:
"Type '...' does not satisfy the constraint 'PageProps'.
Types of property 'params' are incompatible.
Type '{ slug: string; }' is missing the following properties from type 'Promise<any>': then, catch, finally, [Symbol.toStringTag]"
which occurred in `app/content/[slug]/page.tsx`.
The Next.js 15 documentation states that `params` and `searchParams`
props for Page components are now Promises. The `ContentPageProps`
interface and the `ContentPage` component have been updated accordingly:
- `params` is now typed as `Promise<{ slug: string }>`.
- `searchParams` is now typed as `Promise<{ [key: string]: string | string[] | undefined }>`.
- The `params` object is now `await`ed within the async component
to retrieve its value before being used.
This change ensures the component's props definition correctly aligns
with the requirements for async server components with dynamic routes
in Next.js 15.
This commit resolves a persistent TypeScript build error:
"Type 'ContentPageProps' does not satisfy the constraint 'PageProps'"
in `app/content/[slug]/page.tsx`.
The `ContentPageProps` interface has been updated to include the
`searchParams` property, aligning it with the expected structure
for Next.js page components in the App Router. This ensures
compatibility with Next.js's internal type definitions for async
server components.
This commit introduces the initial skeleton structure for several frontend pages as per the e-commerce starter kit plan:
- Home Page: Modified to support CMS-configurable sections (mocked).
- Content Pages: Added dynamic route for CMS-based content (mocked).
- Product Detail Page: Displays product information (mocked).
- Product List/Category Page: Displays products with mock filters/search.
- Search Page: Implements mock Relewise-powered search.
- Login Page: Basic login form structure.
- My Page: Sections for orders, quotes, downloads, profile (mocked).
- Cart & Checkout Page: Cart management and checkout form structure (mocked).
Additionally, this commit includes:
- A fix for a TypeScript type error in `app/content/[slug]/page.tsx` related to `PageProps` by introducing an explicit `ContentPageProps` interface.
- Addition of basic navigation links in the main navbar to improve site traversability.
We're making some updates to Next.js Commerce. Everything prior to this commit marks what we're calling [`v1`](https://github.com/vercel/commerce/releases/tag/v1) as a point in time to be able to reference and still use going into the future. The current architecture of Commerce is a multi-vendor, interoperable solution, including:
- [Shopify](https://shopify.vercel.store/)
- [Swell](https://swell.vercel.store/)
- [BigCommerce](https://bigcommerce.vercel.store/)
- [Vendure](https://vendure.vercel.store/)
- [Saleor](https://saleor.vercel.store/)
- [Ordercloud](https://ordercloud.vercel.store/)
- [Spree](https://spree.vercel.store/)
- [Kibo Commerce](https://kibocommerce.vercel.store/)
- [Commerce.js](https://commercejs.vercel.store/)
- [SalesForce Cloud Commerce](https://salesforce-cloud-commerce.vercel.store/)
All features can be toggled on or off, and it's easy to change between commerce providers. To support this, we needed to create a ["commerce metaframework"](d1d9e8c434/packages/commerce/new-provider.md) where providers could confirm to an API spec to add support for Next.js Commerce. While this worked and was successful for `v1`, we have different design goals and ambitions for `v2`.
**What You Need To Know**
- `v1` will not be updated moving forward. If you need to reference `v1`, you will still be able to clone and deploy the version tagged at this release.
- `v2` will be shifting to be a single provider vs. provider agnostic. Other providers are welcome to fork this repository and swap out the underlying `lib/` implementation that connects to the selected commerce provider (Shopify). This architecture was chosen to reduce the surface area of the codebase, remove the intermediate metaframework layer for provider-interoperability, and enable usage with the latest Next.js and React features.
- We will be sharing more about `v2` in the future as we continue to iterate before the marked release.
