The Paragraphs module has become the de-facto approach to modelling a parent/child field structure within nodes. It's a tried and tested way of organising data and separating presentation from content.
This rigidity can be great, but the strictness is reflected in the authoring experience. Think of it as structure first. You need to know what paragraph type you want before you can produce any content.
Sometimes that's a barrier to content authoring. A lot of content is inherently more freeform. As an editor, you want to start with a blank page, write some rough content, and organise it into components later. You want an editing experience closer to Google Docs or Microsoft Office.
Drupal 10 and CKEditor 5 open up some more avenues in this space.
CKEditor 5 has an internal data model that's distinct from both the stored data and the resulting HTML. It's a document editor rather than an HTML editor. With that in mind, we can define our own document structure and plugins for things that we might previously implemented as paragraphs.
This talk will demonstrate this approach. We'll go though putting together a component that is editable within CKEditor, is stored in a semantic way and is themable with twig.
We'll also illustrate when this is not the right approach, and when multiple entities organised hierarchically make more sense.
