We use 'Content' for anything that is actual content that gets displayed on the frontend. We use 'Settings' for values that alter the way the content is displayed. This might be background colours, text alignment, spacing etc.
As different settings models may be used in different blocklists for the same block (or use the same one for multiple block types) my thoughts are that the conntent should be anything that is always required for that block.
Settings are anything that relates to what it is held in (width, fill etc.)
I like this idea, until I realised the block is completely decoupled from the settings so it has to be added to every single blocklist this block is used on.
This makes it more of a item that relates the block to the blocklist rather than settings for the block itself, so I use it for block widths and other generic data that may affect the containing div rather than the internal workings.
I don't find it so easy to separate a block list editor from it's content and various settings and configuration.
The block list editors I setup are usually user interface components like:
Breadcrumbs
HTML Block
Rich Text
Video
Horizontal Card
Vertical Cards
Banner
Slider
Carousel
The settings are often times unique to the component. I didn't like doubling up on all of these element types, example:
SliderBlock
SliderBlockSettings
I am considering a settings type for everything general - margins, padding, background [color or image], id attribute, html tag [div, section, article], and the such.
But in general, my settings are too specific and thus are put in the element type.
+1 to this, I am finding a LOT of settings that are component unique.
That being said, there are the containner settings or generic settings that can be used (% width of container) which can be applied to a lot of blocks and may differ based on the blocklist the block is in.
When to use Block List Settings
Does any one have any guidelines for when to use the blocklist settings vs blocklist content?
I'm having trouble wrapping my head around when I would use settings.
Hi Kevin,
We use 'Content' for anything that is actual content that gets displayed on the frontend. We use 'Settings' for values that alter the way the content is displayed. This might be background colours, text alignment, spacing etc.
Hope that helps.
Cheers,
Marc
As different settings models may be used in different blocklists for the same block (or use the same one for multiple block types) my thoughts are that the conntent should be anything that is always required for that block.
Settings are anything that relates to what it is held in (width, fill etc.)
I'm with Marc, content for data and settings for display.
I like this idea, until I realised the block is completely decoupled from the settings so it has to be added to every single blocklist this block is used on.
This makes it more of a item that relates the block to the blocklist rather than settings for the block itself, so I use it for block widths and other generic data that may affect the containing div rather than the internal workings.
I don't find it so easy to separate a block list editor from it's content and various settings and configuration.
The block list editors I setup are usually user interface components like:
The settings are often times unique to the component. I didn't like doubling up on all of these element types, example:
I am considering a settings type for everything general - margins, padding, background [color or image], id attribute, html tag [div, section, article], and the such.
But in general, my settings are too specific and thus are put in the element type.
+1 to this, I am finding a LOT of settings that are component unique.
That being said, there are the containner settings or generic settings that can be used (% width of container) which can be applied to a lot of blocks and may differ based on the blocklist the block is in.
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.