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! 🫤

Is there a third option somewhere in the middle here where some components are flagged (e.g. via hook_block_alter for blocks) as being 'simple' in so far as keys in ::blockForm map 1:1 to their settings. Even if they're not fully validatable.
For these we can call ::blockForm and make use of the existing FormState react functionality to keep the store in sync.
For items that we review and determine that there's more going on in ::blockSubmit ::blockValidate we make a round-trip back to the server to resolve props from form values.
I think there's going to be enough use cases for something like this that we can make it generic on the Component config entity, i.e. the UI should be simple and not need to know the difference between blocks and SDC and anything else added later, it should just know that some components need a round trip to Drupal to transform form values into settings/props - whilst others don't. There are cases where we will need this for field widgets (e.g. ::massageFormValues) and places we will need it for SDC (think Media widget where we resolve an image URL via a hard-coded attributes approach atm).
Thoughts?

Do we have an existing issue to call ::blockValidate and ::blockSubmit from \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::clientModelToInput ?

If so I think we could repurpose this to do that.

wim leers → credited bnjmmn → .

@bnjmnm and I independently proposed the same at #3500795-8: [PP-2] Implement client-side validation of block settings → , so let’s do it 💪

IMO this is borderline beta blocker, because without this, eligible block plugins (those that are fully validatable) are likely to not work correctly.
Thoughts?

I think there's a chance we could store invalid data, so that feels like beta-blocker

Removing the "stable blocker" tag, because we have 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active as a stable blocker, and that's the only part of this that seems like a must have before a 1.0.0 release. Implementing #2 from this issue's summary or a hybrid solution allowing some blocks to be #1 and others #2 seems like it could happen after a 1.0.0 release. Please re-tag if you disagree.

We long ago decided to use the forms provided by block plugins, not generate ones, and so IMHO we should close this. But let's make sure we leave no loose ends:

• #7 is now being handled in 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active .
• #9 points to #3500795-8: [PP-2] Implement client-side validation of block settings → , which proposes to do what @larowlan's MR at 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active is already doing!

All good IMHO 👍

Yes I think this can be closed

Thanks :)