Context

With block bindings, we connect a block attribute with a dynamic source. However, the value of the dynamic source is not always available, so we should show a fallback value. For example, if I connect a paragraph with a custom field, that custom field might not exist, or I don't have permissions to see the value. Or when I am in a template and there isn't a specific post ID.

In those cases, we need to fallback to another value to not break the user experience. Simplified, the workflow could be understood this way:

1. Try to get the value from the source.
2. If the value is undefined, show the fallback.
3. If the fallback is undefined, show the original value of the block attribute.

Right now, there are two use cases in core:

• Custom fields: They show the key as the fallback.

• Pattern overrides: They show the original value of the block attribute.

I assume pattern overrides work as expected, but the fallback for custom fields feels a bit techy, so it'd be great to hear opinions if this is right or it should change.

The important part here is that the fallback might defer depending on the source. Right now, we added a getPlaceholder API to let sources decide what to show. This is how it is done for post meta, where we just return the key: link.

However, it was done that way because it was simple and we knew the API was private. Now that we are considering opening the APIs, it's time to discuss the best approach here.

Potential approaches

These are the different approaches I was considering:

Option 1: Keep using getPlaceholder (or getFallback) callback

We could keep the callback we are using right now. It provides flexibility because sources could do whatever they want but at the same time it makes the logic a bit more complex.

Option 2: Change the getPlaceholder property to be a string instead of a callback

This would mean that the fallback would be always the same for each source. Imagine I define it as "Connected to Post Meta". It would show that message independently of which field the block attribute is connected to.

One potential benefit of this is that it could be defined from the server registration directly, and reused in the client.

Option 3: Use the bindings object in the block attributes to receive the fallback value

Right now, bindings are defined inside the metadata attribute. I suggest adding a new property in the bindings attribute that receives the fallback. Something like this:

  "metadata": {
    "bindings": {
      "content": {
        "source": "core/post-meta",
        "args": { "key": "my_custom_field" },
        "fallback": "My custom field"
      }
    }
  }

In this case, the UI would be in charge of adding that property. For example, when a user connects a block attribute with a custom field in the upcoming UI, it could automatically insert the fallback the same way it's adding the rest of the object.

Option 4: Don't use a placeholder at all

This would mean skipping the placeholder step and always fallback to the original value of the block attribute when the value returned by the source is undefined. This is how pattern overrides work right now.

If I understood it correctly, this is what @richtabor was suggesting in this comment. Please correct me if that's not the case.

I'd love to know any thoughts on this before making a decision 🙂