Overview
Once #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model is a reality, every piece of structured data must be presentable using an XB component. If that would not be the case, then some data would be impossible to map into an XB Content Type Template, and hence impossible to present to end users.
Part one: docs/shape-matching-into-field-types.md
The above requires that:
- every base, bundle or configurable field instance
- … so every field type (
FieldTypeplugins, henceFieldItemInterfaceimplementations) - must have all of its data be presentable
- … so every field property (
\Drupal\Core\Field\FieldItemInterface::propertyDefinitions()) - must have a corresponding JSON Schema prop shape that can be matched.
That would allow each piece of structured data (1 entity → N fields → N field items → N field props) to be mapped into an SDC (or code component — these are equivalent).
(See 3.1.2.a `structured data` → matching `field instance`s ⇒ `dynamic prop source` in the doc for details.)
Important note: this means that it's possible that the entirety of a field item (so: the full set of field props) may not be presentable all at once, but may need to be mapped into multiple SDC props, with each SDC prop "receiving" one field prop.
Part two:docs/redux-integrated-field-widgets.md
On top of that, we also (of course) need to be able to edit every field type using whichever widget the Site Builder chose to use, so every field widget must also be Redux-integrated, to allow for live updates.
(See 3.4 Transforms in the doc for details.)
Proposed resolution
Currently, this is completely impractical to get a sense of how far we are.
Create a test that:
- ✅ reports the current % completion for both field types (and their props) that are matchable/presentable, and field widgets that are Redux-integrated
- ✅ is explicitly aware of which ones are supported
To get to full confidence in this test, I also had to:
- add a
type: number-shaped prop to theall-propstest-only SDC — this has been working for a long time now, it introduces ZERO changes, it just simply was not yet tested yet — otherwise we'd have been an artificially low %: this made us go from 67% to 74% → https://git.drupalcode.org/project/experience_builder/-/merge_requests/7... - there were nonsensical matches being suggested:
target_idproperties and whatnot → https://git.drupalcode.org/project/experience_builder/-/merge_requests/7... - similarly for read-only base fields such as
nid,vid,uidetc. → https://git.drupalcode.org/project/experience_builder/-/merge_requests/7... - override
DateRangeItemto add additional metadata, because itsstart_datecomputed property is irrelevant, and we need XB'sFieldForComponentSuggesterto NOT match it, so refined its logic → https://git.drupalcode.org/project/experience_builder/-/merge_requests/7...
Current percentages: see #6.
Once XB reaches 100%, we can simplify that test and just expect it to remain at 100%.
Note: we could expand this test to also account for contrib modules, which we'd then need to add as dev dependencies for those to be testable.
User interface changes
None.
Issue fork experience_builder-3512433
Show commands
Start 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:
Comments
Comment #2
wim leersComment #4
wim leersFirst full green test run!
Comment #5
wim leersComment #6
wim leersTo get a list of the remaining work, force XB to pretend we're at 100%:
+
… and then you'll get explicit test failures:
and
+
EDIT: updated for https://git.drupalcode.org/project/experience_builder/-/merge_requests/7...
Comment #7
wim leersSo, with #6, we've got a way to list the remaining work, to achieve @lauriii's stated goal of supporting ALL core field types + widgets.
It also empowers @lauriii to decide which field types, field type props and field widgets we'll intentionally exclude from scope. (i.e. won't work on adding support for). It also allows him to see which props on which (supported) field are not actually supported yet, and make a decision about that — for example the
linkfield'soptionsprop.It'll get surfaced in a more accessible form in #3512802: CI: surface the list of field types, field type props and field widgets not yet supported by XB.
Comment #8
wim leersComment #9
wim leersFollow-ups, now all linked:
And some of the core bugs surfaced here actually have been known for years: I opened #3324140: Convert field_storage_config and field_config's form validation logic to validation constraints in November 2022 😅
Comment #11
wim leersComment #13
wim leers