I've been working on creating a block which allows editors to add any other block within it. I found the existing documentation on 'sub-blocks' not great, however the blocks which were using sub-blocks in the wild were a good example on how to implement subblocks (notably kitconcept/volto-blocks-grid and eea/volto-accordion-block). I ended up following the volto-accordion-block implementation, creating a BlocksForm and using a schema-based approach.
This brings me to my question. Is this the currently 'recommended' approach to building sub-blocks? Does the volto community have an opinion on how developers should be building sub-block blocks? While there are currently no sub-block blocks in core, I'd be interested to know what the current state-of-the-art for sub-blocks is and which direction it is heading!
The Volto-included BlocksForm gives you a one dimensional grid (which you can shape it to be a column or a row). You can rely on it when developing new sub-blocks based blocks, it's included in Volto and widely used in multiple EEA addons (volto-columns-block, volto-tabs-block, volto-group-block, volto-accordion-block, etc). These blocks go one step further and implement two-dimensional grids (a columns block with multiple columns, each with multiple blocks inside, etc).
@sneridagh started a PR to introduce a Row/Column block in Volto, using BlocksForm, see Row/Column block and friends by sneridagh · Pull Request #3180 · plone/volto · GitHub
So I think there's a strong suggestion that BlocksForm and schema-based blocks can/should be used for sub-blocks. "Schema based" is the way to go when modeling blocks editing UI, Volto core moves into that direction as well.
It's worth mentioning RedTurtle's framework for sub-blocks GitHub - collective/volto-subblocks, though I don't have any experience with it.
2 Likes
Thanks again for the detailed response! Good to know I'm on the right path.