It would be great to be able to use blocks outside modular content, as a way to reuse fields between multiple models.
To clarify:
Let say I have three models: news, articles and general_information. All these models share the fields title, subtitle, and the structured text field content. I want to be able to group all of these in to one block and then simply add that singular block to all models, to be able to for instance add blocks to the structured text field, and by then change all models directly.
This could be done now by using modular content, and limiting the records to one. However, from the editors perspective this is not optimal as you need to create the first record of you own, it also shows an unattractive message about this + the content is nested in the block frame and you cant use the full screen view of structured text.
A simple way to create shared single blocks between models would be of great use in many cases.
I second this request. In our evaluation of Dato vs ContentStack, this would be another big blocker to us switching to Dato. We make heavy use of the concept of blocks, and while a lot of it does occur in a modular content type field, we also heavily use these to add common fields across many templates ( models in Dato ). Things like Administrative options that need to be present and identical in all models and we have found that having to maintain them independently is not very scalable.
Is this in a sprint or at least part of a planning phase?
hey @jdesherlia thanks for your feedback, make sure to vote the feature requests to give them more prominance. We don’t have this in development yet, but we’ll surely consider it. We add the tag planned to all the features that we are working on.
Right now we have just released the new version of our Plugin SDK so we are considering new stuff soon.
Not sure if its the same thing we’re asking, I wanted to force display a block when a new instance of a model was created. I wrote a plugin to see if I could do a temporary work around. Working on some errors, in another thread, let me know if it does what you need. I’m hoping this because a native option, and raised anothe support request for a new field type.
@mat_jack1 thanks for the clarification on how this community is structured. I have added my vote to this feature request. Fingers crossed!
@emile.swain this looks pretty cool, and might fill the gap for now. You mentioned an issue with translations not working… Can you expand on what that limitation is? Otherwise, thanks for putting this together, I think it will be a very valuable plugin.
I don’t know anything about translations, though i’ve seen some code in other example plugins that i think related to the localisation part. I just ignored it.
i’ll try and find the link.
Is this something that might be picked up? We find ourselves wanting to reuse single blocks quite a lot but being hesitant since we have to use modular content which always creates an array. The behaviour I would expect is that if I restrict a modular field to max 1 block, it would be represented as an object instead (or another option to add a singular block into a model).
Yes @felicia.moller, if you restrict to one block we still return an array, but on the UI we automatically add the block, if only one block is available, have you seen this? For the editors is the same, we need to improve on the API side.
We are surely going to consider this in the future.
Is this still under consideration? We find our self spending a lot of time having to update many models separately that all share the same field structure. It would be so useful to be able to share a set of fields between different models.
So at the moment we’re working on a project with several different models based on content types, like News, Commissions, Portfolios, Events, aso. All these share the same structure, fields and final layout, with some exceptions, and we use Structured Text for the client to build block based layouts for each record, and a set of mandatory fields like Title, Image, Slug, Desc.
During the process of building the site we often find that we need to add or remove a block or two in the Structured Text fields, or we need to add a help text to the Slug field, or set a limit to the image sizes of the Image field. At the moment we now need to do that on every model, which is a bit time-consuming and it’s easy to forget something.
Coming from a WP background we’re a bit used to the ACF fields, where you can create a group of fields, which you then can choose to use on X amount of models. Most other things are 100 times better in Dato of course, but that function saves a lot of time and makes it way easier to manage your fields in a consistent way.
+1 to this feature (I think this feature is not getting more votes because the title is a bit misleading)
We’re making a heavy usage of blocks in our project, and most of them are used in a 1:1 fashion. We’d love to have the option to create 1:1 relationships between a field and a block, in a similar way as you can have a single or multiple links to models, so that:
Makes development easy. For example, if my model has a header field that will only have one block, it’s counter-intuitive to do header[0] to access the actual content, as well as naming it headers when there’s only one.
Avoid the unnecessary block layout in the UI. If there’s a 1:1 relationship with a block, I’d love the UI to pretend that there’s no block involved and show the fields as if they were first level fields of the model.
This is the only real issue I’ve encountered so far when working with Dato in the past few days.
My use case, is a reusable “style” field which holds something like “background_color” and “text_color” which almost every single type of block I make will want to have. Something like the discussed feature would help clear up a ton of copy pasting and manual setup of creating these fields on every block type, getting the preset color hexes from somewhere and pasting those, etc.
Update! We are actively working on this: here’s our internal pitch for this feature, I’d really like some feedback if you have time!
[…]
We introduce a new field type: Single Block. The behavior is extremely similar to a Modular Content, with the only difference that it doesn’t contain an array of blocks, but only one. The field should support the “Required” validation, as well as the ability to specify which block models can be inserted.
The default presentation of the field will be exactly the same as a Modular Content (when can only contain one block), but…
“Embedded” presentation mode (temporary name)
If a Single Block field:
can contain only one type of Block Model, and in addition…
has the “Required” validation active…
then we can offer an “embedded” presentation mode for the field. This means that in the content editing side, the block… is not visible. The label of the Single Block field is not there. There is no “frame/border” around the fields of the block. The fields of the block appear to belong to the record itself.
In other words, we achieve what we need: multiple models can share a subset of fields with exactly the same structure.
What happens if two embedded Single Block fields pointing to the same block model are inserted in the same model? Obviously, the experience for the editors will be terrible — two fields with the same label in the same record? — but we allow it, because maybe the editor experience can be fixed by using fieldsets to group the fields in some way.
A few gotchas, at least for the first release of this:
A block only has non-localized fields. If I use a Single Block in “Embedded mode” to share fields between models, then either all the fields of the will be localized, or none — it depends on the localization preference in the Single Blog field itself.
Things like the following will NOT be possible:
Being able to search in shared fields (*)
Being able to set a field of the Single Block as title/image field for a model (*)
Adding a column for a field of the Single Block in tabular index visualization (*)
Expecting that _seoMetaTags will be generated based on an SEO field in the single block (*)
Expecting to have a uniqueness validation in a field shared via Single Block
Get rid of the single block field nesting in GraphQL responses
Those marked with (*) would be possible in the future, if we want to invest in this. But it makes sense to first release a small canary, and see the overall feedback for this kind of solution.
Sweet! Thanks for the update. Can’t wait to rework all my models to use this instead of a clunky single block allowed in a modular content with the Force Block Field plugin.
It seems to me that the “currently not possible” things aren’t too bad. In my mind the most useful use-case for this block type is reusable “meta”-ish fields and stuff like an optional “button” block. As mentioned by you, Fieldsets can solve the editor experience in case of clunkyness.
Very excited about the idea of using Single Block instead of modular content that accepts exactly one record. It would create a lot more cohesion to have just the object returned rather than an array of one object. Love it!
We find ourselves wanting to reuse single blocks quite a lot but being hesitant since we have to use modular content which always creates an array. The behaviour I would expect is that if I restrict a modular field to max 1 block, it would be represented as an object instead (or another option to add a singular block into a model).
