label_format enhancements

[TonisPiip]

Is your proposal related to a problem?

label_format logic seems to be a little iffy, haven't look too far into it. But it's annoying me.

https://github.com/wagtail/wagtail/pull/7509

    if (this.blockDef.meta.labelFormat) {
      /* use labelFormat - regexp replace any field references like '{first_name}'
      with the text label of that sub-block */
      return this.blockDef.meta.labelFormat.replace(/\{(\w+)\}/g, (tag, blockName) => {  /// << Here we just return the processed value without any checks that it's not with just a " " or some useless value.  
        const block = this.childBlocks[blockName];
        if (block.getTextLabel) {
          /* to be strictly correct, we should be adjusting opts.maxLength to account for the overheads
          in the format string, and dividing the remainder across all the placeholders in the string,
          rather than just passing opts on to the child. But that would get complicated, and this is
          better than nothing... */
          return block.getTextLabel(opts);
        }
        return '';
      });
    }
// otherwise uses old logic

Seems that if the label_format is empty it falls back to the name of the block. But not if there's However if you have several fields in the label, there's no way to separate/join them with "," or " " or "|" without it also bing just the separator values when there are none of those values.

currently we have several label_formats which are just "{field_1} | {field_2}", "{field_1} {field_2}", or but those are optional.

Describe the solution you'd like

Do a js equivalent to " foo ".strip().strip("|,") and bool check before using the label_format label value.

This seems like a fairly easy solution to malformed label_format values.

Describe alternatives you've considered

Allowing for label_format output to be defined in a BE code function, rather than FE regex JS replacement. To allow for more complex label generation.

Also: Why have we hidden the block name when collapsed completely, it feels better if the name is still somewhere...

Additional context

Main use case is when you have a complex block, with lots of fields, some of which are empty / optional.