Media Library integration

How would a SDC author declare that a component can accept a media image? (Backend)

It should not declare such a thing. Component author must declare a slot, that's all. A slot can accept any renderable. Sending a media image to the slot is the responsibility of the component user, on the CMS side.

How can we load the Media Library within the Experience Builder (which is a React SPA)? (Frontend)

It was started as a React SPA, but will it stay like that? Maybe, one day, we will consider this choice has more drawbacks than advantages.

How would a SDC author declare that a component can accept a media image? (Backend)

I agree with @pdureau, sort of.

A "media image" really means:

• a Media entity
• … of a bundle that is configured to use \Drupal\media\Plugin\media\Source\Image
• Which corresponds to … an image.

Step 1: SDC author defines the expected shape, and ideally using a predefined JSON schema definition

So, the SDC author should not define what the UX is for getting an image in there. They should declare that they want an image. But there's (at least) 2 kinds of images:

1. an URL to an image — which could be sufficient if it gets used as a background image
2. an URL to an image + associated metadata (alt + width + height), necessary to be used. in an <img> tag

We haven't gotten very far with making all of these concepts well-defined at the SDC JSON schema level, but we do have some, and we do have it for the aforementioned 2:

1. {$ref: 'json-schema-definitions://experience_builder.module/image-uri'}
2. {$ref: 'json-schema-definitions://experience_builder.module/image'}

(introduced in https://git.drupalcode.org/project/experience_builder/-/commit/f784af41, which is heavily inspired by @pdureau's https://git.drupalcode.org/project/ui_patterns/-/blob/28cf60dd776fb349d9...)

Step 2: when opting in an SDC component to XB, the default value for each prop determines the field type

📌 "Developer-created components": mark which SDCs should be exposed in XB Active landed. One of the next steps is ✨ Allow specifying default props values when opting an SDC in for XB Needs work . An implied part of setting up a default value there is that a field type is selected at that time: whichever field type the default value for the StaticPropSource uses that the Site Builder configures, also determines what the field type is that Content Creators get to use (they do not get to choose: that'd make the UX unbearably complex).

In other words: if the selected default value is some "media image", then the Content Creator will be presented with the ability to use a media image.

How can we load the Media Library within the Experience Builder (which is a React SPA)? (Frontend)

This question is insufficiently specific IMHO 😇

We've discussed before that as a first step, we intend to load the existing field widgets in the right-hand sidebar (presumably with their Form API-based definitions automatically rendered using https://www.drupal.org/project/jsx → , to bring real-time updates — see 🌱 [META] Real-time preview: supporting back-end infrastructure Needs review ).

But … the way that the question is phrased seems to refer to in-place editing. Which is not something we should be doing from the start. See #3453690-10: [META] Real-time preview: supporting back-end infrastructure → .

But … the way that the question is phrased seems to refer to in-place editing. Which is not something we should be doing from the start.

Sorry for causing confusion in regards to the requirements. I did not intend to expand the scope to inline editing. #2 was intended to be specifically about how the field widget (displayed in the right drawer) should be opening the Media Library, and defining how the Media Library modal dialog should be rendered within the Experience Builder. IIRC, we did some initial research that it could be opened in an iframe, and was something that Mercury Editor and/or https://www.drupal.org/project/layout_builder_iframe_modal → were doing.

Ahhhh! So it's more focused on the "this ain't no simple single-document viewport, it's a viewport with many (i)frames" challenge. Now I get it 👍

We haven't gotten very far with making all of these concepts well-defined at the SDC JSON schema level, but we do have some, and we do have it for the aforementioned 2:

{$ref: 'json-schema-definitions://experience_builder.module/image-uri'}
{$ref: 'json-schema-definitions://experience_builder.module/image'}

Indeed, I was a bit "quick" pushing the opaque slot as the only solution. I still thing is by far the best, but a well-defined and structured object prop ("object" according to JSON, so an associative array, a Twig "mapping", not a PHP object) can also do the job, and the JSON schema reference system can help the author.

However, let's not look at the contents of the URI string ("experience_builder", "image") to guess if it is an image or not. Those URI, like every URI, → are opaque too. An other reference URI (ex: {$ref: 'json-schema-definitions://whatever.module/amstragram'}) pulling the same JSON schema structure must be processed the same way.

2.How can we load the Media Library within the Experience Builder (which is a React SPA)? (Frontend)

I've managed to decouple(ish) Entity Browser in the RJSF module, it still depends on some drupalSettings values so it's not fully decoupled. Never explored doing it for Media Library because Entity Browser did a good enough job for my needs and could be used for any entity type. Linking in case it's helpful. https://git.drupalcode.org/project/rjsf/-/tree/1.0.x/modules/rjsf_entity...

However, let's not look at the contents of the URI string ("experience_builder", "image") to guess if it is an image or not.

🤔 Why? This would result in broken components wherever images are used. Can you elaborate? 🙏

Linking in case it's helpful.

Thanks!

🤔 Why? This would result in broken components wherever images are used. Can you elaborate? 🙏

If {$ref: 'json-schema-definitions://experience_builder.module/image'} resolve to:

{
  "type": "object",
  "properties": {
     "url": {"type": "string"; "format": "iri-reference"},
     "alt": {"type": "string"},
     "width": {"type": "integer"},
     "height": {"type": "integer"}
  }
}

The schema resolver will juste replace the reference to the resolved JSON schema snippet.

Then, the logic (is it an image?) will apply on the resolved JSON schema.

So, if a component author directly write (without using $ref):

{
  "type": "object",
  "properties": {
     "url": {"type": "string"; "format": "iri-reference"},
     "alt": {"type": "string"},
     "width": {"type": "integer"},
     "height": {"type": "integer"}
  }
}

It will also works.

Or if a component author just writes:

{
  "type": "object",
  "properties": {
     "url": {"type": "string"; "format": "iri-reference"},
     "alt": {"type": "string"}
  }
}

It will also works.

Or if a component author uses another reference resolving the same schema snippet.

{$ref: 'json-schema-definitions://whatever.module/amstragram'})

It will also work.

It is solid architecture, using JSON schema reference as expected, without introducing "weird" behaviour by deducing information from the characters in that URL.

At some point do we need to talk about formatters? Yes we might store a media reference - but we might format it using e.g. a different view mode or a responsive image format

Integrate the Drupal Media directly with the Experience Builder, allowing users to upload, browse, and select images from the Media Library.

When talking about Experience Builder, it seems we are not talking a lot about the blocks, layout, formatters... plugins. Are they still considered as first class object? Or are they becoming an afterthought? Do we plan to reimplement in Experience builder features already existing in Drupal (like Media Library Browser) instead of leveraging them?

Experience Builder is currently looking like 2 different "products" bundled in one:

• the initially promised easy-to-use, powerful & universal display builder, which will replace Layout Builders and others
• SDC & design system / tokens integration / management / building. Ambitious, but still a bit blurry.

I am worrying this "coupling":

• will ask extra unexpected work, so we will not meet our ambitious projects targets (calendar, scope...)
• will cut experience builder from large parts of the Drupal ecosystem by:
  • not exposing the SDC integration to the other tools
  • not leveraging the plugins provided by Druapl core & contrib
• will create technical debt (when we will want to replace or revamp one of the 2 parts) and change management risk (if one of the 2 parts of Experience Builder is not welcomed by the community, it will take down the other part with it)

Instead, let's restore the Drupal plugins we all know and love in the centre of the discussions and the architecture, as an interface between the display builder and the design system manager.

What do you think about that?