Optional programmatic default blockName field

[damnsamn]

It would be great to be able to define a programmatic default blockName pattern, usage similar to admin.components.RowLabel.

My thinking is that a block's blockName would default to the generated output of a given function while the input is empty - automatically updating each time the block's data updates. blockName could still be overridden in the UI, which would break the link between it and the generator function. When cleared the input is cleared, it would default back to the provided function output.

Example:

const MyBlock: Block = {
  slug: "myBlock",
  defaultBlockName: ({data}) => data.name,
  fields: [
    {
      type: "text",
      name: "name",
      required: true,
    }
  ]
} 

[damnsamn]

Example use case:

Here is a Navigation Menu builder which utilises Blocks to differentiate between navigable menu items, and non-navigable menu item parents (2nd-level navigable only)

In this case, the user will have to self-label each block in the list by copying-and-pasting from the label field.

In an ideal scenario, we could define these blocks as being automatically labelled by its label field by default, which the user could optionally override. This would avoid the "Untitled" default which forces them to duplicate effort in naming each menu item

[cbrualdi]

No one interested in this?

I think this feature is crucial for the usability and clarity of the CMS. Blocks are often used to create complex structures, and the information identifying a block is often already contained within the internal fields. We also have several use cases where it is useful to generate a blockName from multiple internal fields, but people either don't use it or are bored with re-entering the same information.

In my opinion, this change would add a lot of value for the end user.

What do you think?

[lotarbo]

It's super useful, for example in sanity you can do that. https://www.sanity.io/docs/previews-list-views

[damnsamn]

This still gets regularly raised as a bug, both internally and from clients. Having to explain "Payload doesn't support this" fairly often at this point

[GermanJablo]

This is supported, it just wasn't well documented. Please see the changes in the documentation from: #13782

[robclancy]

That isn't even a good solution to this. I don't see why we can't just set the damn blockName. I can't go a week without finding some weird decision in payload.