What is the intended purpose of the "templates" folder in the Next.js Starter Storefront module structure?

[jungsikjeong]

I noticed that the Next.js Starter Storefront uses a templates folder inside each module (e.g., src/modules/account/templates/Copy to Clipboard, src/modules/order/templates/Copy to Clipboard).

At first, I assumed this folder was meant for SSR (server-side rendered) components, but I found that some template components use client-side hooks like useState and useActionState, meaning they are CSR components as well.

Could you clarify the intended design pattern or convention behind the templates folder? Is it:

A separation of concerns pattern (page fetches data → template handles UI)?
Related to the Template Method design pattern?
Simply a naming convention with no strict SSR/CSR distinction?
Any clarification on the intended architecture would be greatly appreciated!

What is the recommended pattern for data fetching in page.tsx vs template components in the Next.js Starter?

I've noticed two different data fetching patterns used in the Next.js Starter Storefront:

Pattern A: page.tsx fetches data and passes it as props to the template

Code

// page.tsx
export default async function ReturnRequestPage(props: Props) {
  const order = await retrieveOrder(params.id)
  const [shippingOptions, returnReasons] = await Promise.all([...])
  return <ReturnRequestTemplate order={order} shippingOptions={shippingOptions} returnReasons={returnReasons} />
}

Pattern B: page.tsx only handles metadata, and the template component handles its own data fetching

Both patterns seem to be used across the codebase. Could you clarify:

Is there a recommended or preferred pattern?
Are there specific use cases where one is preferred over the other (e.g., SEO, performance, complexity)?
Is there a convention or architectural guideline behind this decision?
Any clarification on the intended architecture would be greatly appreciated!

[mubashirdawood]

1. The Role of the templates Folder

The convention is to separate Routing/Orchestration from UI Layout.
Page (page.tsx):
Acts as the entry point and "Controller." It handles URL params, search params, and initial data fetching.
Template:
Acts as the "View." It defines the visual structure of a full page or a major section.
Why not just components?
By using a templates folder, the team distinguishes between small, reusable atoms/molecules (buttons, inputs) and high-level, page-specific layouts that aren't meant to be reused elsewhere.
SSR vs. CSR:
There is no strict rule here. A template can be a Server Component or a Client Component (with 'use client'). Its identity is defined by its scope (the whole page) rather than its rendering mode.

2. Data Fetching:
Pattern A vs. Pattern B
The "best" pattern depends on Suspense and User Experience.
Pattern A: Page fetches, Template displays (Preferred)
Use Case: When the data is critical for SEO or when you want to avoid "layout shift."
Pros: Simple props flow; the page won't render until the data is ready (good for initial load).
Architecture: Keep the page.tsx as the "Data Fetcher" so the template stays focused on UI.
Pattern B: Template fetches its own data
Use Case: When part of the page is slow or non-essential for SEO (e.g., "Related Products" or "Account History").
Pros: Allows you to wrap the Template (or parts of it) in , showing a loading skeleton immediately while the data streams in.
Architecture: Used for "Sequential Data Fetching" or when a template is used in multiple routes that fetch data differently.