Implement saving block settings forms

This needs #3484666: Show configuration forms for Block components to land first.

There is work in #3467954: META: Evolve XB UI's data model to allow non-SDC components' inputs, DynamicPropSource support, etc. that will make this easier. Should we postpone on that too?

I'm not opposed to that at all, but @longwave, @jessebaker and others felt that #3467954: META: Evolve XB UI's data model to allow non-SDC components' inputs, DynamicPropSource support, etc. was too broad in scope to be actionable. If you managed to act on it anyway, all the better! 😄

#3484666: Show configuration forms for Block components landed!

Also, https://git.drupalcode.org/project/experience_builder/-/merge_requests/3...

Ran out of time today, but compared the component inputs form HOC against the block one and I think we should be able to make them one and the same. Because the form state and these input behaviours are locked up in the compiled FE build, any deviation that is per source component is going to make things difficult for contrib (and a layout builder/paragraphs BC layer).
Ideally we can leverage the SimpleComponent/SDCComponent differentiation in #3493941 and then defer any other nuance between Source plugins to pure PHP. That leaves the door open for Layout plugins (LB), paragraph plugin and anything else from contrib

Per @larowlan's latest MR comment.

In https://git.drupalcode.org/project/experience_builder/-/merge_requests/448 I've tried to remove those assumption - but it will likely need to come back in some form by way of transforms in #3467954: META: Evolve XB UI's data model to allow non-SDC components' inputs, DynamicPropSource support, etc. but ideally it can be controlled from PHP

For #3487484: Save page data form values in application state with support for undo/redo we were able to remove the knowledge of that nesting and let Drupal sort it out - i.e. we store the page values keyed by the name attribute for their respective input (e.g. 'title[0][value]' and then that is transformed back into the nested format Drupal side.

Follow up to address re-unification #3500152: Remove InputBehaviorsBlockSettingsForm and consolidate with input components form

This looks ready to me in its current form. There's a followup for the reunification.

This issue exists to complete that work and make block settings changes in the UI propagate to the back end including data storage and preview.

(Emphasis mine.)

The preview part is working.

The storage part is not. It's only auto-saving (to ephemeral storage), not really saving (to an XB field or the PageTemplate). Which means it's not really stored, nor passing validation.

Besides that, I am concerned about:

1. the deviation from the previously established terms "explicit inputs" and "implicit inputs": https://git.drupalcode.org/project/experience_builder/-/merge_requests/5... — block settings are explicit inputs for that the "block" component source. As captured by this bit in the issue summary: Block settings are similar to, but not the same as, SDC props.
2. the (undocumented) meaning of supportsProperties and supportsDynamicProperties: https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...

Perhaps it's worth meeting on Monday morning about this, @longwave, to figure out the naming and docs? Happy to write those together!

It's only auto-saving (to ephemeral storage), not really saving (to an XB field or the PageTemplate). Which means it's not really stored, nor passing validation.

How are you determining that without #3497530: Implement the "Publish All" button being done? Are you testing the publish step some other way?

IDK who/when/where this happened but there still is a “Publish” button next to thr “Review changes” dropdown 😅🙈

Oh, right, I forgot that button was still there. So originally, that button implemented direct-to-entity-save (without going through autosave), so that we could work on issues having to do with saving entities in parallel with figuring out how we wanted to handle autosaving.

Once we got autosaving working, I think we opened an issue to change this Publish button to not send the entity data in the request body, but instead to just send the autosave key (or the info needed to figure out the autosave key), and the server-side controller to save from the corresponding autosaved data instead of from the request body. However, I forget if we completed that issue.

So, if that is in fact how the Publish button now works, then I do think it makes sense, as either part of this issue or as a followup that can proceed right after this issue is merged, to make sure that block settings get validated and transferred correctly from the autosave data to an entity revision. Because presumably the work to do that would be exactly the same as what will get triggered by the "Publish All" button once that's in.

However, if the Publish button is still working the old way where it's publishing from the request body rather than the autosave data, then I don't think it makes sense to make that old way work with block settings. Because once the "Publish All" button is in, we'll remove the "Publish" button.

Up until now, the XB team has been following a pseudo-scrum/pseudo-kanban process, but we're now shifting into more conventional scrum. We started a new 2-week sprint last Thursday (Jan 16). I'm tagging our current sprint's issues for visibility.

I've renamed the methods/attribute properties and documented them as follows:

* @param bool $hasExplicitInput
   *   TRUE if the component source generally expects input from the user. This
   *   could be in the form of props for a single directory component or
   *   settings for a block component. Pass FALSE if the component expects no
   *   input from the user. This can be modified on a per-component basis by
   *   implementing the ::componentHasExplicitInput method in the plugin class.
   * @param bool $hasEvaluatedInput
   *   TRUE if the component stores its input in the form of prop-sources. This
   *   input is stored as a combination of a source-type and expression.
   *   Depending on the source-type it may include additional input including a
   *   value or adapter configuration. A source plugin that passes TRUE here is
   *   also assumed to have explicit input. This can be modified on a
   *   per-component basis by implementing the ::componentHasEvaluatedInput
   *   method in the plugin class.

/**
   * Returns TRUE if the component source expects input from the user.
   *
   * @return bool
   *
   * @see \Drupal\experience_builder\Attribute\ComponentSource
   */
  public function componentHasExplicitInput(): bool;

  /**
   * Returns TRUE if the component stores input in the form of prop-sources.
   *
   * @return bool
   *
   * @see \Drupal\experience_builder\Attribute\ComponentSource
   */
  public function componentHasEvaluatedInput(): bool;

And the protected methods on the tree data-type are now componentHasExplicitInput and componentHasEvaluatedInput

I've also added an e2e test and for clicking publish with a block in the body and expanded test coverage in the client conversion test to ensure this is supported both for nodes and patterns.

Looking into the last open item regarding validation now.

This is ready for another look.
I think we also should consider a general followup to revisit some more uses of 'props' in the codebase including ComponentPropsValues in typed data. I'm happy to keep going on renames here, but it feels like we're getting into out of scope territory and making it harder to review this issue.

#21: #3494859: Rename Component config ComponentSource plugin-specific configuration keys for clarity fixed some of those "props" in the codebase :)

This MR is now looking way better than on Friday. I wanted to review+RTBC+merge, but @longwave's remarks alongside my own observations make me conclude that this is not yet ready to be merged. Two critical comments that I'm curious what y'all think about:

1. https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...
2. https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...

+1 for renaming ComponentPropsValues in a follow-up issue. Or … perhaps it actually would make help this issue simpler?

AFAICT the #1 thing slowing us down here is XB's SDC-centric naming of low-level infrastructure. If that were refactored away first, it'd allow us to land this MR with more clarity and confidence?

Unless I see comments articulating strongly why not to do that, that's where I'll start my day tomorrow: refactor away the pervasive "props" and "prop sources" in the XB field type. I think that will clear things up a lot.

Added #3500994: Remove references to 'props' outside of SDC - use 'inputs' instead for the rename

I'd like to do the final pass on this; this is the most important/impactful MR of the month AFAICT!

• @larowlan took my feedback from Monday and made it happen by Tuesday: https://git.drupalcode.org/project/experience_builder/-/merge_requests/5... — that's why this was legitimately RTBC! 👏 Awesome work here, @larowlan & @longwave 🙏🙏🙏
• Changes in /ui: https://git.drupalcode.org/project/experience_builder/-/merge_requests/5... points out that #3493941: Maintain a per-component set of prop expressions/sources will rewrite most of those things; so changes in that area are basically fine to ignore — they're in service of achieving this issue's goal, they're not aiming to nail long-term code patterns.
• There is an end-to-end test 👍 … but this was still broken in actual usage, because XBTestSetup was pre-placing a Block component, which concealed the fact that the initial block plugin settings are missing. Details: https://git.drupalcode.org/project/experience_builder/-/merge_requests/5.... Fixed in https://git.drupalcode.org/project/experience_builder/-/merge_requests/5....
• There were some API surface/code clarity concerns, as well as something that seemed innocent but revealed some gaps: https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...
• The #1 thing that's missing here: docs — they're absent from both the issue summary and this MR does not touch /docs/* at all. I didn't want to hold it up on that though, so I did a rough first pass that leaves us in a better place than if we'd merged this MR as it was, but we'll need to gradually tackle updating /docs/data-model.md, probably starting with #3500994: Remove references to 'props' outside of SDC - use 'inputs' instead — after that is done, an overhaul becomes much simpler.

Please don't think I'm downplaying the quality of this MR. This MR is a huge leap forward! 🤩🥳 But in doing so, I wanted to make sure we kept our eyes aimed at a tighter API surface, a more precise definition of how XB works with components coming from various sources, etc. Because #3499919: [Meta] Plan for in-browser code components is being worked on right now, and will introduce a third component type very soon!

All subsequent refactoring for which this MR surfaces the necessity:

1. #3493941: Maintain a per-component set of prop expressions/sources
2. #3500997: Move SDC-specific validation in ValidComponentTreeConstraintValidator and ComponentTreeMeetsRequirementsConstraintValidator into the SDC source plugin — https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...
3. #3501281: Reconcile date format handling between client-side transforms and server-side's Evaluator
4. #3501290: Introduce unit test coverage for both ComponentSource plugins (Block + SDC)
5. #3500994: Remove references to 'props' outside of SDC - use 'inputs' instead — should also update all references to component prop in /docs/*, and possibly also mark ADR#2 as superseded and write a new one. This issue did the heavy lifting, but without that rename, all docs will remain confusing anyway.

Note that most of the issues at the bottom of #27 are essentially a subset of what we'll need for #3467954 — see #3467954-55: META: Evolve XB UI's data model to allow non-SDC components' inputs, DynamicPropSource support, etc. for an overview of what AFAICT are the immediate next steps. — nope, that issue is for the client-side data model, #27 is focused on the server-side data model not being coupled to SDC!

I'll work on bringing clarity to this.

@longwave and I discussed this, and we recalled that #3500152-3: Remove InputBehaviorsBlockSettingsForm and consolidate with input components form is the one he identified as a critical refactoring to pave the path for #3499919: [Meta] Plan for in-browser code components.

One more follow-up: #3501708: Prove that it *will* be possible to apply block settings update paths (assuming #3521221 in core) to stored XB component trees in config/content.

Bug for something we missed here #3501870: Block form state not cleared when component is changed

Fixed :)