[PP-1] Implement client-side validation of block settings

This to me is definite polish, a nice-to-have, not a must-have for 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active .

Why?

Because:

• 99% of BlockPluginInterface implementations' forms do not have any validation at all — client nor server-side. The range of possible settings values allowed through the UI is constrained only by the HTML input element they picked (<select>, <input type="checkbox">, etc.)
• It's only since a few months (since 📌 Make Block config entities fully validatable Fixed ) that a few block plugins are fully validatable …
• … and it's only those few block plugins that have a precise config schema that would even allow for this! 😰
• I'm convinced that >50% of placed blocks contain invalid/nonsensical block settings, that only sort of work due to PHP's automatic typecasting — having worked on https://www.drupal.org/project/acquia_migrate → , and having seen the incredibly weird/convoluted/puzzling "settings" many placed blocks were accepting without complaining.
• Actually, even outside a migration context, the only reason block plugins' settings forms work at all is precisely because both the PHP typecasting magic in the form definition is matched with the Form API submission typecasting magic, and is matched with the block plugin's ::build() method's interpreting of the saved values

📌 Implement saving block settings forms Active is in, but I imagine we'll at least want to do 📌 [PP-2] Remove InputBehaviorsBlockSettingsForm and consolidate with input components form Active first?

📌 [PP-2] Remove InputBehaviorsBlockSettingsForm and consolidate with input components form Active is in, too.

📌 Decouple generated source plugins from SDC plugins Active blocks this in my book

Per #3513589-6: [PP-1] Decouple generated source plugins from SDC plugins → , that is PP-1.

Just had a long chat with @bnjmnm about this … interesting problem space.

He had a very interesting proposal/observation/idea! 😄

What if … we don't do what this issue is proposing:

Attempt to add a translation layer from block configuration schema to json schema and send this schema for block plugins.

(which would be a huge pile of complexity!)

What if instead, we'd apply an approach similar to what we do for the (aka content entity) form? i.e.:

• use the regular FormBuilder-powered form submission logic
• hence use the same (PHP/server-side) validation logic (for those block plugins that do have it)

That would avoid the need for new APIs, new transformation layers, and would likely result in some shared infrastructure between the and block component forms.

Especially because the form already uses most (if not a superset!) of the #types listed at #3520484-70: [META] Production-ready ComponentSource plugins → that we currently have little confidence (because no explicit tests and no block plugins exercising them) in all of those working correctly.

So … @larowlan, what do you think about exploring what it'd take to refactor \Drupal\experience_builder\Form\ComponentInputsForm to use the same logic as the tab for \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent?

wim leers → credited bnjmnm → .

Yes I agree, I wrote something similar in 📌 Define how block settings should be presented in the UI Active yesterday - basically that we need to be calling ::blockValidate and ::blockSubmit from ::clientModelToInput in the block source plugin.

We can use this issue or that one to do that work

Oh, great! 🥳

That other issue seems to be the closer fit, so let’s do it there. I’ll point back here 👍