Research JSON schema forms for SDC configuration

I have been doing this for a while in Drupal using https://github.com/e0ipso/schema-forms-php

However, I think that the current approach is geared towards using field widgets instead. In other words, instead of mapping the schema to the form elements, it tries to map the schema to the typed data in field types. Once you have the field type, you can load the widget for it.

#2 is right. XB is following the direction proposed in #3440578: [PP-2] JSON-based data storage proposal for component-based page building, and hence does not need JSON schema-based form generators.

See the demo at https://drupal.slack.com/archives/C072JMEPUS1/p1716925610355849, the code for which is at https://git.drupalcode.org/project/experience_builder/-/merge_requests/20 and should land soon.

We should also be able to do that for the "Attributes" prop (SDCs do not have fields, but props).

I wrote the https://www.drupal.org/project/rjsf module to do this and was successful using it to implement component based authoring for several sites but after talking with Wim at Drupalcon there are a number of limitations that made me think it wouldn't be the best path forward for XB.

When it comes to forms there's really 3 different parts, the data model(schema), the view(form display), and the current data. JSON Schema does a really good job at defining the data model but has no concepts to define how a prop should display in a form. All the various JSON Schema form generators add on their own layer of properties and keys to the schema to allow defining how props should be displayed which potentially makes the XB JSON Schema less portable to other JSON Schema tools. If we were to adopt a form generator for XB we'd need to consider:

• If the library is extensible enough to meet all our needs, including allowing contrib to provide an arbitrary number widgets, from my work with RJSF it's good but is complex to make extensible for contrib.
• If the library's license is compatible with Drupal. RJSF is licensed under Apache-2.0 which as far as I understand is not compatible with GPL making distributing it with core difficult
• How developers(and non developers) would discover the various plugin widgets available and how they map to schema structures
• When defining a component meant to be used across multiple sites how do you know which components are available or denote a dependency? What happens when a widget defined the schema isn't available?
• How difficult it would be to reimplement and maintain two versions of core and contrib field widgets. We'd need both a PHP version and a JS version.
• Which schema are we storing? The schema for the content being collected or the schema for the content being rendered. Often the content when authored has a different structure then the template needs to render. Think a button link component, the target URL for is often an entity reference where we need to collect and store the entity reference from the form but the component template expects a url string.
• How would validation work? Most of these form generators have a built in client side set of validation that runs against the schema but Drupal's validation is much more extensive and would likely have to happen server side then need to be sent back to the form in some way.

I'm a fan of generated forms from schema and think that XB should have some amount of functionality to allow authoring of a component straight from the schema without additional configuration but overall after seeing that it's possible I'm a much bigger fan of reusing our existing field system and mapping known/validated content field structures to json schema props. Even if it means we have relatively ugly fields and forms to begin with. This approach lets JSON Schema do what it's good at which is define the structure of the props needed to render the component while allowing Drupal to do one of the things it's best at which is collecting and providing structured content to templates.

I'm a fan of generated forms from schema and think that XB should have some amount of functionality to allow authoring of a component straight from the schema without additional configuration but overall after seeing that it's possible I'm a much bigger fan of reusing our existing field system and mapping known/validated content field structures to json schema props.

This is exactly what the MR I mentioned in #4 aimed to do (for issue #3452497: [MR Only] Edit any component prop, powered by a new FieldForComponentSuggester service, which will power the JS UI), and it has since then landed.

@e0ipso also voiced explicit +1 in the Drupal Slack thread linked from #4.

#5 is an excellent write-up though, and I'm working on an overhaul of #3444424: [META] Configuration management: define needed config entity types that should point to this comment. I'll update #3452497: [MR Only] Edit any component prop, powered by a new FieldForComponentSuggester service, which will power the JS UI to point to #5 too, and I want to incorporate it in upcoming docs too.

Using Patch (to be ported) to signal that "this is fixed but still needs some following up", and self-assigning to do that.

It took much longer than I'd have liked, but comprehensive docs for the direction XB opted for (use existing Field Widgets + integrate with Redux) to meet all product requirements should be finished in the next few days: #3446434: Document "Semi-Coupled Theme Engine" and "Redux-integrated field widgets" components.

Signaling that by changing issue status, will follow up here after that lands.

will follow up here after that lands.

That landed while I was on paternity leave.

I've met with @ctrladel at DrupalCon Atlanta in March 2025, almost a year after his write-up at #5. Things are obviously much further along today than they were back then. We needed to render field widgets for the content entity form anyway, and that's now very well on its way to 100% — see #3487284: [META] Add explicit end-to-end test coverage for using all core field widgets including multiple cardinalities in the "Page Data" (content entity) form.

Furthermore, we're using (Static|Dynamic)PropSources to be able to evaluate both structured data on actual entities (for mapping structured data into component trees using ContentTemplates) as well as the "static unstructured data per component instance" in the same way. And StaticPropSources need those same field widgets. To get to 100%, follow along at #3515563: [META] Expand support to *all* SDC prop shapes, and *all* core field widgets and related issues.