Immediately include a block in model content view

I must not be understanding this correctly as i’m looking for something i kind of just assumed would be an option.

When i define the fields for a model, i want to be able to add a field, called details, and have it display the fields defined in the detailsBlock i set up.

The details block is used across lots of models, because the fields are the same.

The problem is, in the content editor, if i add a modular content field, there is no option to force an instance of the block. Which i should be able to do.

Instead it requires the editor to click add block, which they shouldn’t have to do.

Infact, i should be able to add multiple fields to a model, either pointing to the same BlockType or different blocktypes, and appear by default in the editor for the model.

I just can’t find a field option that does that?

is there one?

I have noted, that the fieldsets option, kind of does what i want from a visual perspective but doesn’t allow you to have fields nested with the same key as other fields in other fields sets. Which makes sense, given the fieldset is purely visual and doesn’t actually nest the fields in the json output. (which could/should also be an option)

I’m under the impression that the blocks functionality has been developed with more of the visual side in mind, rather than the schema of the actual resulting model.

Ok, i created a plugin as a field addon (under presentation) that basically lets you force force the blocks to be added when creating a new model. Will share it.

1 Like

Great @emile.swain the plugin way sounds perfect to me!

If you want to share your plugin would be awesome, thank you very much

I’m also in the slack channel, and Stefano Verna as seen this as well.

1 Like

Not sure, but I just tried on my project and I got this:

Is it working fine for you?

Yeah, i think i can see where its failing. i’m doing the following.

// Line 68 below.
ctx.setFieldValue(ctx.field.attributes.api_key, [...fieldValue, {
                    "itemTypeId": itemTypeId,
                    "itemId": "new-" + nanoid(),

so i think it might be ...fieldValue that its trying to spread and its possibly null, or undefined, or what is essentially failing.

So it might be DatoCMS returning something unexpected, or if you’re building locally then it might be webpack messing with the … operator. I’m not sure myself. I litterally just bashed this together over the weekend.

i’m pretty sure that DatoCMS returns “” or [] for the fieldValue. So not sure why the … would fail.

Where are you getting the fieldValue from?

Can you maybe add a check if the fieldValue is not null before doing the setFieldValue?

Yeah, i might be able to find some time later today.

Ok, i’ve wrapped in a try/catch but i can’t replicate the error so i hope it wraps your error up.

The […param] failes if it gets an object or a number. So i’m wondering what are valid fieldValues.

I’ve also noticed a bug, where if a model has multiple instances of a block, the presentation view gets inundated with repeat instances of that blocks switcher.

I’m hoping that the SDK v2, gets updated to pass the field parameters data into the ctx object, because currently you can’t tell what field your editing. Hence having to loop through all the field validators for the whole model, rather than just for the field you editing.

doh, i forgot to change the version number, new version should be pushed soonish.

Can you do a screenshot? Not sure what you mean!

In general, I’ll try to sum up my 2C (sorry for the long reply! :wink:)

If the Modular Content field has a validation (ie. “at least 2 blocks”, or “exactly 1 block”) AND there’s only one type of block you can add, it would make sense that DatoCMS natively creates some empty blocks for you, I agree with you. We’ll try to prioritize this request, hopefully it will be shipped soon! In the meantime, plugins are fine, that’s what they’re for :slight_smile:

Talking about plugins, a modular field value should always be an array OR null, and spreading a null value is not permitted:

Screenshot 2021-12-07 at 20.08.03

So you need to do something like [...(fieldValue || []), newBlock]

Since you can use the same manual field extension on multiple field types, it makes sense to add some additional information in the ctx of the renderManualFieldExtensionConfigScreen hook. It cannot be a full Field object though, as it might not even exist if you’re creating a brand new field.

I’ve just released v0.3.20 of the datocms-plugin-sdk package with the following new properties available in the ctx of renderManualFieldExtensionConfigScreen hooks:

Screenshot 2021-12-07 at 21.29.14

Screenshot 2021-12-07 at 21.29.31

It was a bug with my plugin code that displayed multiple switches with the same block name. I think i had two fields applied to my model, both fields using validators that had the same block added.

Because the Plugin Config component doesn’t tell you which field your editing on the ctx object, I iterated through the whole model description. As such it lists the same validator twice.

Now that you’ve updated the SDK to pass through the pendingField i’ll see about resolving that.

Talking about plugins, a modular field value should always be an array OR null , and spreading a null value is not permitted:
So you need to do something like [...(fieldValue || []), newBlock]

I’ll add that in.

Hmm, now facing various errors.

Added a modula field, applied a block to the validators, added the addon and i get the following errors.

I updated the package.json to the new versions, both the sdk and ui looked like they had changed.
Had a couple of complaints in the Plugin config component.
Cleared npm, lock files and restarted all instances of the plugin and browser cache.

Code changes in this branch GitHub - emileswain/datocms-plugin-forceblockfield at experiment

Error ID: 7be472d3-72e1-4f0b-b467-631be483cdd6

index.js:11 TypeError: Cannot read properties of undefined (reading 'origin')
    at AdminArea-J72GJJGT.js:1:83746
    at (<anonymous>)
    at Ko (AdminArea-J72GJJGT.js:1:83693)
    at AdminArea-J72GJJGT.js:1:84237
    at Object.useMemo (chunk-Q7JIQSC3.js:2:59326)
    at Object.l.useMemo (chunk-B7G5LW6E.js:1:7075)
    at Ag (chunk-5OHDIJPZ.js:1:5620)
    at Xo (AdminArea-J72GJJGT.js:1:84230)
    at Si (chunk-Q7JIQSC3.js:2:55172)
    at va (chunk-Q7JIQSC3.js:4:15080)

@emile.swain I’ve tried to enter your project to reproduce the issue, but the modular content was already deleted so I cannot see the error :confused: I’ve tried recreating it and applying the plugin, but no exception.

Can you recreate the situation in which the error occurs on the birely-app project (maybe on a new environment so you’re not blocked by the error)? At that point let me know and I’ll try to solve it, thanks!

seems to work fine now. I think there is occasionally an issue with browser cache or something residual when switching between market place and localhost plugins.
I’m wondering if there is a way to build against the none obsfuscated code so i could read the errors if they happen?

Ok, so I think its all working now. Just waiting on market to pick up changes and do a final test.

quick update @emile.swain:

Shipped! It also works recursively (ie. when a block requires nested blocks)

1 Like