I noticed that in the website template, collections are used instead of globals for serving pages and that it seems to be the recommend way of doing it.
However if you have for example 2 seperate pages like a contact page and an about page, both which are wildely different and each uses a very unique layout. Would there still be any upside of using a collection and creating a layout from building blocks that are only used once for each of those places? I hope i made sense 🙂
I always use a global for my pages
Because I typically need separate field structures per-page that I would otherwise need to make blocks for
I only use collections for repeating content
Thats what i was thinking. I couldnt see if i had missed something obvious in how payload was supposed to be used in terms of best practice. But i guess i havent then
Hey @notchr , hope you're having a good weekend.
So does Payload team typically use blocks for most/all content to provide the option of re-using that block structure, if the client wants to create a page that may be unrelated to previous pages - therefore the more block layout options the higher the chance of the content editor finding something suitable? It's just to provide more content layout options, as opposed to using a global that doesn't provide that advantage? Am I understanding correctly?
Globals is for pages that is unique (eg homepage), while Collections is for pages that can have multiple entries, like BlogPosts
Globals can also be used for configuration, like for Navigation structure (menu)
@taun2160 Globals are good for non-repeating structured content (though, they can definitely have repeating fields). Collections are good for repeating structured content
If you create a "Pages" collection, it's going to be arguably difficult to have customization per-page without some interesting conditional block logic
Where in a global, it can be specific to a page
I think in a normal scenario, a site will have a reasonable amount of pages that need to be custom tailored
While sites with 100's of content items generally keep them structurally consistent
Blocks are great for repeating content that require the same block structures
But when you start creating custom blocks for specific pages that are built using a Collection, things quickly become tedious
Thanks Chris. So if the admin creates a new page (generated by slug), they select a layout block and that is rendered using the renderBlocks component. So that's for cases where their page desires extends beyond the global pages, such as adding new products that render it's own page per product slug? It's for scalability and customizability right? That way the client doesn't have to return to the dev and request changes.
I feel like it would be rather simple to have a select field such as “layout” that conditionally renders different group fields that have specific fields for a “layout”. Using the collection approach.