Can you explain the benefits of so much granularity of data?

[native shale]

Can someone kindly enlighten me about the benefits of a system with so much granularity, when it comes to the data? I'm not use to seeing JSON right down to a p tag, a ul tag, then an li tag with a bunch of children etc. I know it was suggested this is a pro (vs a con) versus other similar CMS, this on one of the videos I watched (if I remember correctly), but I'm trying to understand how to manage it, without it become unwieldy on the frontend; I'm not implying it is or isn't, just that it's new to me and new things take time to understand; time to see them as a benefit versus a lot more work; how such things should be best used, or in this case, how to best consume it on the frontend etc.

Admittedly, I may have to get use to a managing more complex data structures, but a simple Post structure kind of "overwhelmed" me lol

[haughty anchor]

You can see here how we use a serialize function to consume the rich text and output it. The reason we use rich text is because it allows us to do things like, embed documents and other custom elements directly into the rich text editor.

In the example, ignore the customRenderers for now and just look at the serialize function, it calls itself recursively to loop over all nodes in the json tree.

https://github.com/payloadcms/website/blob/main/src/components/RichText/index.tsx

[native shale]

@haughty anchor thanks for sharing! Okay, I see what you're doing here: https://github.com/payloadcms/website/blob/main/src/components/RichText/Serialize/index.tsx

[weary fractal]

The granularity is because not all mediums that might consume the content are websites.

Content modelling in headless for true omnichannel delivery needs a completely different approach and mental model.

For example, voice assistants, printers, meta verse, etc. have no use for html.

Native app UIs can use the RichText json to natively render the content rather than relying on buggy web views, etc.

[clear flower]

That and it allows you to actually process the data better if you need to, rather than have to try and read long strings of HTML (or alternatives)

[leaden sable]

I love the granularity

[native shale]

Ah okay, makes sense.

Thanks for sharing everyone 😀

[native shale]

@haughty anchor @weary fractal @clear flower @leaden sable is it possible to have granularity for the times one needs it or something more simple for those times when one doesn't need it? For example, say I just want to get back a few fields with their key being the name of the field (that I've assigned to it) and the value being the value of the field and nothing more. Is that possible with Payload?

[clear flower]

Sounds like youre describing graphql?

[weary fractal]

Yes... just make a field of a different type. text, number, etc.

[native shale]

Is the granularity more of a RichText specific thing?

[native shale]

Possibly, but even that seems like an extra layer of complexity in my mind.

[weary fractal]

It is. The richText field splits all the elements into JSON ... most good headless CMS do this in one way or another.

If you need what I would call "structured content" (i.e. plain data rather than rich text) then just use normal fields.

[native shale]

Ah okay, maybe that's where the disconnect was coming from. Structured content, yes, that's more of what I was looking for.

[weary fractal]

Each field you define on your collection of global will return as { fieldName: fieldValue } ... i.e. a normal 'text' field might be { title: 'My awesome title' }

The richText field type is just the value as a JSON object that describes the rich text data in a way that is easier to programmatically process then HTML is.