Hi @saprykinse,
Welcome to the Dato forums!
Can you please describe your use case here in more detail (like what you are trying to accomplish on the frontend)? âComponentsâ can have a lot of different meaningsâŚ
If youâre trying to model something like a WYSIWYG page builder where you can have, say, a âHeroâ component with a background image, a description, and a CTA button, all as one frontend <Hero/>
component, then yes, you can model that as a block inside DatoCMS and let your editors use it to compose modular pages via drag-and-drop.
However⌠the answer isnât quite that simple (it never is, right?
)
It not only depends on the particular project, but also what your goals are, both for your frontend and your editors. While that example WYSIWYG page builder block system above is one way to model a schema, itâs not necessarily the âbestâ (or even most popular) way of doing it. Thatâs how some customers think of a CMS, especially if theyâre coming from the Wordpress / Wix / Squarespace etc worlds.
But in a headless system like ours, there doesnât necessarily need to be a 1:1 connection between a frontend component and model or block in the CMS. In fact, more often than not, they can be quite different.
Let me give you a contrived exampleâŚ
Letâs say your frontend is an ecommerce store (like our ecommerce demo that you can play around with), full of different products.
The same product would ideally be only defined one time inside DatoCMS, with all the fields youâd expect: name, price, images, etc.
And on a product page on your frontend, youâd just use those fields normally.
But maybe you also want to mention the product on other pages⌠like maybe you want to showcase it in a âbusiness casualâ collection. Inside DatoCMS, then, youâd make a new schema for that kind of âshowcaseâ page, which can have its own fields (like a title and description). Then maybe itâd link to one or more specific products (via a multiple links field, probably). So far, you donât need any blocks yet.
But then maybe you also want a blog section where you can write long-form articles, maybe something like a âbest ofâ type of article. But you want your editors to have more editorial control over the page content, being able to intersperse text, images, links to other pages⌠but also the occasional product. THATâs when blocks would be useful. You can compose the blog page out of different blocks inside a âstructured textâ field, which allows your editors to write in a powerful WYSIWYG system that allows allows the use of blocks and linked records. That way they can easily intersperse regular text alongside product links, hero blocks, carousel blocks, etc. Those particular blocks could correspond to frontend components (via our <StructuredText/>
helper component for React and its âcustom renderersâ â they let you define how to a certain blockâs schema and fields should be rendered on the frontend).
So in the end, a project would end up with a healthy mix of fields, records, blocks, and links/relationships. They each have a certain purpose and theyâre meant to complement each other for different use cases. Most projects use all of them in different ways.
If youâre just exploring DatoCMS, I would recommend playing with our starter projects (Project starters - Free demo projects - Marketplace) to see how a typical project might be hooked up.
If you have a specific kind of project or use case in mind, please also feel free to email us at support@datocms.com (or just post the details here) and we can help you brainstorm through a schema design, if that would help.
Does that answer your concerns? If thereâs anything I can clarify, please let me know 