I'm still familiarizing myself with DF, but I think:

1. the same problem occurs even with a label
2. the same problem occurs at least in card layout

When empty should we use for summaryContent an edit: ${attribute label} instead of empty field? I think that's better, but if we went for an empty field approach, it should be different based on the number of fields.

Finally with this change in the story ?path=/story/dataviews-dataform--layout-panel&args=labelPosition:none the discussion appears empty. Is this in indicator that we need a getValue there in general?

edit: ${attribute label}

I had a similar thought 👍

Edit: I realised this is a bit related to #73036. "${attribute label} unset" could also be an option for when the label is hidden. When the label is visible we might not need to repeat it.

As I mentioned here: #73036 (comment), I think that:

[...] it should be up to each field to decide how it wants to handle its empty state and DataForm shouldn't provide a default one.

For example, for some fields it might be more appropriate to have a -, for others a placeholder text etc. This can be controlled via the field's render function.

So perhaps the solution here is to update the Storybook example and add a render function to fields that can have an empty value?

Shouldn't there still be a fallback in case a field doesn't supply an empty state?

Do you mean a curated fallback, other than the one we have now, which is displaying an empty space ''?

Looking at the current proposal, it doesn't seem like the field's render function is taken into account. Instead, if the value is empty, then __( '(Empty field)' ) is rendered. The render function is only used when else if ( summaryFields.length > 1 ).

I understand the UX benefits of having a curated fallback, but as a developer I would expect to have control over the empty state of a field via render, without having to change its value (i.e. what is returned via getValue). For example, the value of a field could be '', but I might want to display it as -.

I think that we must keep the consistency of displaying the field's value as is, unless a render function is provided. If the value is '', display it as ''. If the value is abc, display it as abc. Having a special render function that runs only when the field has a specific value (empty is this case) and the field doesn't provide a render function, doesn't seem very consistent and intuitive in my opinion.

Do you mean a curated fallback, other than the one we have now, which is displaying an empty space ''?

Yeah. I suppose the problem I'm conscious about is when labelPosition is none and the value is '' you basically get an empty row in the UI which looks broken.

I agree the consumer should have some level of control over the empty state render.

Hi @ntsekouras, @jameskoster I update to use "${attribute label} unset" when label position is none and "${attribute label}" when label is shown (we repeat the label).

Hi @jimjasson, you raised a very good point, we should allow consumers to have their own empty states using the render function. I totally change the implementation to be based on css :empty pseudo selector, only if the element is in fact empty and the render function did not provided any output we use the fallback, so consumers of the API now have full control if they want a different fallback.