This commit updates the application to operate in a standalone mode by
modifying essential data fetching functions used by layout components
to return hardcoded dummy data, removing dependencies on a live
Shopify backend for initial page rendering and layout.
Key changes:
- `lib/shopify/index.ts`:
- `getMenu()`: Updated to return a hardcoded array of `Menu[]` items,
bypassing any calls to `shopifyFetch`. Caching directives were
removed as they are not applicable to static dummy data.
- `getCart()`: Updated to return a hardcoded `Cart` object (or
`undefined`), bypassing `shopifyFetch` and cookie-based cart ID
retrieval.
- `shopifyFetch()`: The core `fetch` call within this function has
been commented out and replaced with a `throw new Error(...)`.
This prevents any accidental live API calls and makes it clear
that such calls are disabled in this standalone configuration.
A `console.warn` is also added if the function is ever invoked.
These changes ensure that the main layout, including the navbar and
cart components, can render without external Shopify dependencies,
allowing the storefront to function with dummy data as per your current
project requirements. This should resolve build errors related to
fetching non-existent Shopify data (like menus) in an environment
not connected to a live Shopify store.
Resolves a prerendering error for the `/_not-found` page caused by
the Navbar's attempt to fetch a menu that might not exist in the
build environment (e.g., 'next-js-frontend-header-menu').
The `getMenu` function in `lib/shopify/index.ts` has been updated
to catch errors thrown by `shopifyFetch` (such as when the Shopify API
returns an error for a non-existent menu handle). If an error occurs
during menu fetching, it is now logged to the console, and `getMenu`
returns an empty array `[]`.
This allows pages using the Navbar (including `/_not-found`) to build
successfully even if the primary header menu is not found, instead of
failing the entire build process.
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.
