The core routes should be set up as configurable when generating a new theme with the theme script (see Theme Generation). However, this document will discuss how to structure a new configurable page route should you need to add one.
A page.tsx should be simple in its content, rendering some required components and exposing any requirements for data fetching accessed via the NextJS App Router (eg searchParams for an index page or an id / slug for a show page) which is then handled in a child component.
This page must call await init(domain) at the beginning of the component in order to instantiate Homeflow APIs like Hestia when a page is visited for the first time. The domain can be accessed from the page params and run through decodeURIComponent before passing to init.
Eg.
export default async function BranchesIndex({
params: { domain },
}: {
params: { domain: string };
}) {
const decodedDomain = decodeURIComponent(domain);
await init(decodedDomain);
The page.tsx should return ThemePage, a wrapper component which reduces code duplication across routes by consolidating common data requests required by most pages and exposing to its children by returning a function as children.
Eg. usage
return (
<ThemePage pageName={PageName.PropertyList} theme="rigel">
{({ agency, pageConfig }) => {
if (!agency) return notFound();
return <PropertyListSite pageConfig={pageConfig} searchParams={searchParams} />;
}}
</ThemePage>
);
As you can see from the example, page should then return the site version of the page, eg <route-page>.site.tsx (see Server / Client requirements ).
A user-friendly naming convention has been chosen to name routes in admin to avoid confusion with technical terms like index pages as well as with pages where the singular and plural are not clear, eg. staff. For show pages we use the singular name of the resource, eg. Branch, and for index pages we use the resource name followed by list, eg. BranchList.
As both admin and the site need to render a page that displays with the same content, the data requests for the page will be moved to a <Route>Page component, eg. PropertyListPage which can then be used to wrap the return content of both <route-page>.site.tsx and <route-page>.admin.tsx. A theme can create its own -page for a route if the page has specific data requirements that other themes do not require. However, for pages like the property index it is like that the requirements will be the same across all themes so you can import from #theme/pages/ for such pages.
<route-page>.site.tsx and <route-page>.admin.tsx should then have the same structure, eg. section areas and core content rendered in the same order, but with the difference being that .admin will render sections with <LazyOrderableSections> (@/components/orderable/lazy-orderable-sections.component.tsx) to render sections client side with admin functionality and .site with <Area> (@/components/area.tsx) to render sections server side via mongoDB.