Why does the new Block Editor have both a Content Model and a Settings Model for each block type? This does feel like a useful feature, but I’m not sure I totally understand the reasoning behind it.
The downside I see of having this is that the Block View uses a BlockListItem ViewModel instead of a strongly typed content model. This means the view needs to be unique for the block rather than being able to be reused as the view for any instance of that element type (nested content, DTGE, etc).
I'm using the Block Settings to define common settings around each block, such as padding/margin or custom classes, like how Row/Column Settings worked on the Grid Editor.
But since I only want to define this logic once per setting type rather than on each block, I needed to update my Block renderer to render a Settings View for each block based on its Settings object type. Then in the Settings View, in addition to rendering the wrapper div with settings, it also calls the Content View by passing in a strongly typed Content Model, which means I can also use this view for nested content and DTGE. This is different than how the out of the box implementation works so I feel like I may be missing something.
I can also see some advantages of having a "settings" section for the backoffice editor experience if you were to build an inline editor, since you will need a way to edit non-inline things. However, that would just be more of a UX experience and I don't see the reason for making this a separate element type since I will need both objects to render the block.
Or, I can maybe see it useful once variants come into play, so you maybe can have an alternate variant for the content but not the settings, but this would be a future feature, so I’m not sure what the plan is.
How has everyone been using Block Editor Settings, and does anyone know what the original idea was behind them?
Why use Block List Settings
Why does the new Block Editor have both a Content Model and a Settings Model for each block type? This does feel like a useful feature, but I’m not sure I totally understand the reasoning behind it.
The downside I see of having this is that the Block View uses a BlockListItem ViewModel instead of a strongly typed content model. This means the view needs to be unique for the block rather than being able to be reused as the view for any instance of that element type (nested content, DTGE, etc).
I'm using the Block Settings to define common settings around each block, such as padding/margin or custom classes, like how Row/Column Settings worked on the Grid Editor.
But since I only want to define this logic once per setting type rather than on each block, I needed to update my Block renderer to render a Settings View for each block based on its Settings object type. Then in the Settings View, in addition to rendering the wrapper div with settings, it also calls the Content View by passing in a strongly typed Content Model, which means I can also use this view for nested content and DTGE. This is different than how the out of the box implementation works so I feel like I may be missing something.
I can also see some advantages of having a "settings" section for the backoffice editor experience if you were to build an inline editor, since you will need a way to edit non-inline things. However, that would just be more of a UX experience and I don't see the reason for making this a separate element type since I will need both objects to render the block.
Or, I can maybe see it useful once variants come into play, so you maybe can have an alternate variant for the content but not the settings, but this would be a future feature, so I’m not sure what the plan is.
How has everyone been using Block Editor Settings, and does anyone know what the original idea was behind them?
is working on a reply...