#3452512: Add component instance edit form to contextual panel introduced a first iteration of a form in the right sidebar to edit the props of a component instance (not to be confused with ComponentEditForm, introduced by #3444417: "Developer-created components": mark which SDCs should be exposed in XB).
It introduces a lot of infrastructure to be able to render PHP-defined widgets ("field widget plugins") using React by lifting a subset of the functionality out of https://www.drupal.org/project/jsx, thus allowing React to render Form API render arrays generated by field widget plugins! 🤯💥
But what it does not do, is generating that Form API render array using something sane/understandable: it does so by extracting a subset of the form that \Drupal\experience_builder\Plugin\Field\FieldWidget\TwoTerribleTextAreasWidget generates. But that is itself — as the name already indicates — a very temporary throw-away kind of code.
Since #3452397: Allow specifying default props values when opting an SDC in for XB, \Drupal\experience_builder\PropSource\StaticPropSource::getWidget() (and sibling methods) can be used to generate a new static prop source and a widget to accept a value, even if no host entity exists yet.
/xb-field-form route to not be powered by TwoTerribleTextAreasWidget, but by StaticPropSource::getWidget()\Drupal\experience_builder\Form\DummyComponentFieldForm\Drupal\experience_builder\Controller\ExperienceBuilderController::horribleFormHack()Out-of-scope:
DynamicPropSource, this logic should currently just fall back to using a StaticPropSource, as if it were a newly placed component.
IOW: The sole purpose of this issue is to simplify the right sidebar.
Less noisy UI — it should start resembling the actual UX, and be somewhat reasonable.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | expected.png | 16.94 KB | wim leers |
| #9 | after.png | 114.06 KB | wim leers |
| #9 | before.png | 193.97 KB | wim leers |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
wim leers#3452512: Add component instance edit form to contextual panel must land first.
Comment #3
wim leers#3452512: Add component instance edit form to contextual panel landed! This can now be worked on. 👍
Comment #4
wim leersComment #5
larowlanI'm still very strongly in favor of writing actual react components for each widget with a way for people to swap them in.
We did this in decoupled LB. It's a lot less magic.
Comment #6
wim leersThere's no question that there's a lot of complexity. AFAIK writing React-based widgets is intended to become possible too, eventually.
For more context, see my detailed response at #3452512-38: Add component instance edit form to contextual panel.
Comment #7
wim leersThis blocks #3462310: Component props form: map textarea, bool, and select elements to React components.
Comment #9
wim leers⇒ the impact of #3462310: Component props form: map textarea, bool, and select elements to React components will be much clearer!
Note: it looks like this unveiled a minor but high-impact oversight in
semi_coupled.engine: default values for forms are not rendered when using that engine (see screenshots above), but are rendered when using the default engine (reproduce by adding an early return toexperience_builder_form_component_props_form_alter()):Comment #10
lauriii🤯
Comment #11
wim leers+69,-210🥳Comment #12
wim leersYay, the MR is green — only the
phpcsCI job is failing, but that's due to #3462697: CI: phpcs job failing due to upstream changes in Drupal core: comments must start with capital letter.Comment #13
wim leersComment #15
bnjmnmComment #16
tedbowLooks good
Comment #18
bnjmnmSo much better
Comment #19
wim leersUpdated #3462310-10: Component props form: map textarea, bool, and select elements to React components and I see @bnjmnm already started working on #3462441: Contextual form values need to be integrated with Redux: start with single-property field types 🚀