Best practices for using page structure builder in Sanity and decoupling from traditional CMS thinking.
Now I have a design for a client on the homepage it's showing latest projects and news.
Because for a blog for instance you won't use a page structure builder but just output everything because the layout is the same.
But a page like contact or about or homepage can look different.
Now do I use the page structure on type "page" all the time for creating pages as a best practice?
Or can I tell Sanity that only exclude the page builder (array) from a specific page ID/Slug?
you can and should decouple the 1:1 thinking of other cms’ -> use the page builder for quick contained landing pages, setup overall informational
settingsingleton doc, with fields for about us etc. as well as impressum text, social links, contact info and more.and then you have a doc type called person which is basically the team with name, email, short bio etc, then you have testimonial docs, news & project docs, with title, slug, body and publish date and all the other fields;
Then in your front end you dynamically load different parts of your document types or page parts into your pages.
You get
setting.impressum(block content) and
contactinfo for the page route
/impressum
for
/aboutyou get
"team": *[_type == 'person']{name, team, profileImage)"aboutText": *[_type == 'setting'].aboutText"testimonials": *[_type == 'testimonial' && useForAbout == 'true']{sourceName, body, image)"news": *[_type == 'news' && featured == 'true']{title, team, excerpt)[0...3]|order(_publishAt, desc)All Projectswill will lead to
/projectswhere you will need
"projects": *[_type == 'project']|order(finishDate, desc){title, team, image, client, description, slug)/project/SLUGwhere you get the data from one specific project with a
bodyand so much more info.And then for landingpages, which you generate with
[slug].tsxin nextJS you query for the
contentarray and render it there.
I hope this is clear
😅
testimonialBannerSectionwhich can have 3 testimonials in a slider or whatever. Now you set it up as an object with an array of
max 3items which are
referencesto your
testimonials💥In your front-end you need to setup a special query for those things then.
And on next you would have something like: app - projects/blog/about - page.tsx and use the queries which are needed on each page and based on how you structured it?
But in the app root folder the page.tsx file just output the data which is needed on that page?
So its easier actually not to have page structure data unless tou have one global page
We can also have a short zoom and go through your content structure/plan (record and then share it?)
So its easier actually not to have page structure data unless tou have one global pageYes, but sometimes no… It really depends on what the needs are and also thinking on how this will scale
I usually use some sort of flow chart (figjam or miro) to mix and match
This is something I do sometimes, its just notes to explain things …
https://www.figma.com/community/widget/1066408362543146472
This one right? Going to check it out! I want to get out of that complex thinking mindset.
😅
Was this answer helpful?
Sanity – Build the way you think, not the way your CMS thinks
Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.