Define how block settings should be presented in the UI

Cons: Will this always work inside React?

I don't see why not? I'd like to see @bnjmnm comment on this aspect.

Cons: What if we want to map field values to block settings? (see 📌 Define `props` in the context of Block components Active )

ℹ️ I'm assuming that by , you mean DynamicPropSources aka product requirement 7.1 Token.

Why would that make sense? Isn't that what Block plugins already have the context functionality for? This sounds like it'd be a confusing duplication of that functionality. IMHO we should limit

2. Use the block config schema to build a settings form

Pros: Autogenerated forms will be easier to handle in the client
Cons: What if ::blockForm() allows dynamic values or uses other advanced features of forms?

This cannot work AFAICT.

See my detailed write-up at #3462241-8: [PP-1] Decorate the SDC plugin manager and allow components defined in code →

One possible idea is to converge these two options: for fully validatable blocks, allow the block plugin to opt out of providing a form, and automatically generate it from the config schema instead.

Interesting idea! 🤔 But … config schema is not rich enough in its metadata to convey everything. Lots of validation constraints use logic to define valid values, conditional values, and so on.

Hence it sadly follows that it's impossible to auto-generate equivalent forms from a fully validatable block plugin's config schema! 🫤