Support for multiple "types" of Pages

[Jamiewarb]

I can see several different ways teams may want to compose pages:

1. In the CMS:
   a. Entirely in the CMS, using modular content blocks (either inner + outer or just outer)
   b. By selecting a Template that provides set fields in the CMS, and renders a matching template in the codebase
   c. By providing set fields for an entire document schema type, and rendering a template for that schema type in the codebase
2. In the Codebase
   a. Entirely in the codebase, optionally with a document in the CMS for linking to as a reference (but that isn't used for content)

I would like to support all models out of the box, for all content types that generate a page.

Here's current notes on strategy. These are not exhaustive, and need further thinking:

1. In the CMS

a. Entirely in the CMS

• Documents created here should have a dynamic URL, that can be changed in the CMS
• Content is added to these documents, which is used to render the entire page
• The frontend makes a request to the CMS for a document with a matching slug, and renders the generic 'page' file

b. Select a Template per Document

• Documents created here should have a dynamic URL, that can be changed in the CMS
• A template is selected, which decides which fields are displayed to edit.
• Content is added to these documents via the fields shown.
• The chosen template is rendered on the frontend.

I believe this is the hardest one to support, and needs further thinking. Would we need to make a groq query for all data all templates could possibly support using conditional projections? Or would we make two queries: one for the template for the page, wait for it to resolve, then another for the properties for that template?

What if different schema types have different available templates? What if there's no overlap? How do we keep this optimised? What if the particular page URL is for 1.a or 1.c? How does that affect our initial query strategy?

c. Template for Schema Type

• Documents created here should have a dynamic URL, that can be changed in the CMS
• Fields are shown for this schema type
• Content is added via those fields
• The frontend renders the template for that schema type

Similar to 1.b, would we need to make a groq query with different fields for all schema types? Is it one big groq query to support 1.a, 1.b and 1.c? Is that maintainable? Performant?

How do we merge this with 1.b? This is the second hardest to support, but easier as we can reason ahead of time what template this schema type should use, so can hardcode that in.

2. In the Codebase

a. Entirely in the codebase

• These pages have a static URL that cannot be changed in the CMS
• These page draw content from other places in the CMS to display
• A schema type specifically for link references can be created, and added to the internal link fields, allowing these pages to still be selected as internal links. The URLs for these hard-coded pages are added to this schema type.

---

Initially we should focus on 1.a and 2.a, as these are the easiest to support.

We can then look at ways to support 1.b and 1.c in a performant and maintainable manner

[liamb13]

In the past I've done a double call. So try to fetch type a, if that fails try to fetch type b. But this could quickly become problematic for multiple templates.

I wonder if templates could be included in another query, either dedicated or part of something else?

With caching and a prefetch it could be performant.

That could potentially even be used as part of the '404' check.

Something like;

1. Prefetch all pages, returning template and slug (or some identifier). Returned as template sets.
2. When a route is hit, find it in the template sets, if non existent throw a 404.
3. If it's found, fetch that document with a template specific query.

I often end up using conditional projections because they work and by separating files and masking the mess with template literals I've hardly ever noticed. Until it's debugging time, and I actually try to inspect the enormous call made. Functions potentially could handle the conditionals in a more optimised way?

[liamb13]

Potentially for C - could prefixing fields be an option? And again handle the query/functionality with code. Adding reusability across templates. Would still leave design decisions somewhat free rein, but automate the queries a little. This may only work for very simple types though, but using staff profiles as an example;

• Staff name field would be field.text.name

• Role as field.text.role

• Staff photo as field.image.photo

Then like the modular content, build modular queries (somehow) and determine how to query the properties from that opening prefix.

The alternative would be to create a custom query for each and every document type.