Jules wip 9832509343613941747 #1461
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… done so far and provide feedback for Jules to continue.
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.
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 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.
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[]>`.
|
@google-labs-jules[bot] is attempting to deploy a commit to the Vercel Solutions Team on Vercel. A member of the Team first needs to authorize it. |
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.
…mode
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.
|
ok |
… done so far and provide feedback for Jules to continue.
Resolves a TypeScript type error in `lib/shopify/index.ts` where the dummy data for `getCart`'s `lines.merchandise.product` did not match the `CartProduct` type. Specifically, properties like `availableForSale`, `description`, `descriptionHtml`, and `images` (array) were removed from the nested `product` objects within the dummy cart lines. The `featuredImage` property was ensured to be a single object conforming to the `Image` type. This change aligns the dummy cart data with the type definitions in `lib/shopify/types.ts`, fixing the build error: "Object literal may only specify known properties, and 'X' does not exist in type 'CartProduct'."
Feat: Implement dummy data mode controlled by environment variable This commit introduces a dummy data mode for the storefront, controlled by the `NEXT_PUBLIC_USE_DUMMY_DATA` environment variable. When this variable is set to `true`, the application will use hardcoded dummy data instead of making live calls to the Shopify API. Key changes: - Added `NEXT_PUBLIC_USE_DUMMY_DATA=true` to `.env.example`. - Restored `lib/shopify/index.ts#shopifyFetch` to its original implementation that can make live API calls. - Modified all data fetching functions in `lib/shopify/index.ts` (e.g., `getMenu`, `getCart`, `getProduct`, `getProducts`, `getCollection`, `getCollectionProducts`, `getPage`, `getPages`) to check `process.env.NEXT_PUBLIC_USE_DUMMY_DATA`. If true, they now return appropriate hardcoded dummy data. Otherwise, they proceed with the original Shopify API call logic. - Modified all cart mutation functions in `lib/shopify/index.ts` (`createCart`, `addToCart`, `removeFromCart`, `updateCart`) to also respect this environment variable. In dummy mode, they log the action and return a dummy cart state, bypassing actual API calls and cookie manipulations. A shared dummy cart constant was introduced for consistency. This allows the application to be run and tested in a standalone configuration without requiring a live Shopify backend, resolving previous build errors related to API call failures in such environments.
This commit resolves the Vercel build error: "Error: The 'use cache' directive must be at the top of the function body." The following functions in `lib/shopify/index.ts` were updated to ensure that if they use Next.js caching, the `'use cache';` directive is the very first statement in the function body, preceding any conditional logic for dummy data mode: - `getCollection` - `getCollectionProducts` - `getCollections` - `getProduct` - `getProducts` - `getProductRecommendations` Additionally, dummy data mode handling was added to `getProductRecommendations` to align with other data fetching functions. Functions fully converted to dummy data providers (like `getMenu` and `getCart` when in dummy mode) were confirmed to not use these directives, which is correct.
…product list
Resolves a TypeScript type error in `lib/shopify/index.ts` within the
dummy data logic for the `getCollectionProducts` function:
"Type 'Product | undefined' is not assignable to type 'Product'."
The error occurred when attempting to use `genericProducts[0]` without
first ensuring that the `genericProducts` array (fetched from a dummy
`getProducts({query: "generic"})` call) was not empty.
The logic has been updated to check if `genericProducts.length > 0`
before accessing `genericProducts[0]`. If the array is empty,
`dummyCollectionProductsList` is set to an empty array, preventing
the assignment of `undefined` to a variable typed as `Product[]`.
…duct[0] Resolves a TypeScript type error in `lib/shopify/index.ts` within the dummy data logic for the `getCollectionProducts` function: "Type 'Product | undefined' is not assignable to type 'Product'." The error occurred when attempting to use `genericProducts[0]` to populate `dummyCollectionProductsList` without definitively confirming that `genericProducts[0]` was not `undefined` (i.e., when the `genericProducts` array was empty). The logic in the fallback case for dummy data in `getCollectionProducts` has been confirmed/updated to explicitly check `genericProducts.length > 0` before accessing `genericProducts[0]`. If the `genericProducts` array is empty, `dummyCollectionProductsList` is correctly assigned an empty array, preventing the type error.
…Products Resolves a persistent TypeScript type error in `lib/shopify/index.ts` within the dummy data logic for the `getCollectionProducts` function: "Type 'Product | undefined' is not assignable to type 'Product'." The error occurred when attempting to use `genericProducts[0]` to populate `dummyCollectionProductsList`. Previous guards like checking `genericProducts.length > 0` were insufficient in the Vercel build environment's TypeScript context. This commit implements a more explicit check: 1. `genericProducts[0]` is assigned to `firstProduct` (typed Product | undefined). 2. `firstProduct` is then checked for `!== undefined` before being used. 3. If `firstProduct` is not undefined, it's safely used to create the `dummyCollectionProductsList`. Otherwise, an empty array is assigned. This more explicit narrowing of the type should satisfy TypeScript's strict checks in all environments.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.