ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called

This AFAIK ties into follow-ups opened for 📌 Add support for Blocks as Components Active that were never followed up on. A quick scan suggests:

• 📌 Define how block settings should be presented in the UI Active
• 📌 [PP-1] Implement client-side validation of block settings Active (see \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::fixBooleansUsingConfigSchema())
• etc.

This should be fixed before 1.0, but not necessarily before 🌱 Milestone 1.0.0-beta1: Start creating non-throwaway sites Active  — because A) ComponentSource plugins won't be a stable API yet, B) I don't see how this could impact the data storage.

If we're lucky, it's this simple:

diff --git a/src/Plugin/ExperienceBuilder/ComponentSource/BlockComponent.php b/src/Plugin/ExperienceBuilder/ComponentSource/BlockComponent.php
index f0a7b094c..8e7fa4ba4 100644
--- a/src/Plugin/ExperienceBuilder/ComponentSource/BlockComponent.php
+++ b/src/Plugin/ExperienceBuilder/ComponentSource/BlockComponent.php
@@ -325,14 +325,14 @@ final class BlockComponent extends ComponentSourceBase implements ContainerFacto
    * {@inheritdoc}
    */
   public function validateConfigurationForm(array &$form, FormStateInterface $form_state): void {
-    // @todo Implementation.
+    $this->getBlockPlugin()->validateConfigurationForm($form, $form_state);
   }
 
   /**
    * {@inheritdoc}
    */
   public function submitConfigurationForm(array &$form, FormStateInterface $form_state): void {
-    // @todo Implementation.
+    $this->getBlockPlugin()->submitConfigurationForm($form, $form_state);
   }
 
   /**

I'm running into this in 🐛 Autocomplete machine name handling does not match to machine name Active with the webform block.

Webform uses Drupal\Core\Entity\Element\EntityAutocomplete which has a validateEntityAutocomplete() which is where the mapping happens. That is defined as an #element_validate on the element. I tried the proposed fix in #4, that did not seem to help (change anything at all with what it did).

The validateConfigurationForm / submitConfigurationForm methods in ExperienceBuilder/ComponentSource/BlockComponent aren't called at all, so the additions in #4 unfortunately won't work. This isn't a huge shock as (like the Page Data form) there isn't a traditional submit that would invoke the validate/submit methods in the way we're accustomed to.

I attempted to submit the block form similar to how the entity form is programmatically validated/submitted in \Drupal\experience_builder\ClientDataToEntityConverter::setEntityFields and didn't have any luck - if elements in the form had #element_validate callbacks they weren't called. I suspect this is because of how complex it is to do this (a delicate balance of form state and form and input values) and not because it's an unworkable approach.

@bnjmnm Ah, right, this also needs ComponentInputsForm::validateForm() and ComponentInputsForm::submitForm() to call ComponentSourceInterface::(validate|submit)Form 😅

Currently, as per @bnjmnm comment #7, we do not call methods proposed by @wim-leers in #4. I've tried adding suggested code as per #7, but that isn't called either.
In fact, ComponentInputsForm::buildForm() has the following comments on L102-L106:

// Prevent form submission while specifying values for component inputs,
// because changes are saved via Redux instead of a traditional submit.
// @see ui/src/components/form/inputBehaviors.tsx

I do not think we should classify this as a bug, as we've never built form submission/validation handling mechanism. We build form to allow user to input prop values, but the only validation performed is on FE side. At least until an attempt to publish/save is made, at which point some form inputs turn out to be invalid, as they were never massaged by "submission" mechanisms.
I suspect that this will be much more involving than just adding code proposed in #4 and #7. Specifically, adapting FE application to do submissions and validation via Drupal methods.
Considering that current UI allows user to enter some text into autocomplete, select a value and click away - there might be some interesting challenges to figure out what constitutes "form submission" or "form requiring validation" if there are no additional UI/UX changes introduced along with this.

And even when such changes are in, I suspect we will need thorough manual and automated testing to find potential edge cases.

I have some thoughts, I'll push this along a bit

Pushed up a POC but we've got a couple of open threads/questions

* In \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::buildConfigurationForm we're only calling ::blockForm and we probably should be calling ::buildConfigurationForm - current code is not calling the code for blocks that override that method - e.g. \Drupal\layout_builder\Plugin\Block\InlineBlock::buildConfigurationForm
* We have issues with #tree - BlockForm in core uses sub-form state and sets #tree => TRUE on the form. If we do don't do that we end up with a mismatch in how the form works between here and normal block forms. But if we do that, we end up with extra values in the input names - e.g. see \Drupal\system\Plugin\Block\SystemBrandingBlock::blockSubmit which expects to see block_branding in the values. We don't currently have that because we're working with the schema for the config (as seen in \Drupal\system\Plugin\Block\SystemBrandingBlock::defaultConfiguration where there is no block_branding. We also have \Drupal\experience_builder\Form\ComponentInputsForm::applyElementParents to mess with #parents.

I suspect the way forward will be to get \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::buildConfigurationForm into alignment with BlockForm and use sub-form state and properly pass along settings and #tree => TRUE to the FE, then in ::clientModelToInput we can undo that in a repeatable fashion, so that we can call ::blockSubmit for blocks like SystemBrandingBlock

The failing e2e catches these issues 🙌 so that block was a good choice for test cases!

larowlan → changed the visibility of the branch 3523496-componentsourceinterfacesubmitconfigurationform-and-validateconfigurationform to hidden.

larowlan → changed the visibility of the branch 1.x to hidden.

@gábor hojtsy any chance you could test this branch with webform to confirm it resolves the issue?
The test module I've added has a block form with an entity autocomplete widget so 🤞 it does.

If we're lucky, it's this simple:

Famous last words 😂, this one turned out to be quite the battle