Try: a generic Edit config for media

[oandregal]

This is an incomplete prototype, it doesn't deal with adding new data, or update selection, etc. It's here to surface challenges with direction.

What?

This PR experiments with having a generic Edit config for the media control.

Why?

By having a configurable generic Edit config:

• this complexity is absorbed by the framework
• fields are serializable (no need for a specific media component)

How?

Creates a new media Edit control that takes some config. That config is all the properties of DataViewsPicker:

{
  id: 'media',
  type: 'media',
  Edit: {
    data: [ /* ... */ ],
    fields: [ /* ... */ ],
    view: { /* ... */ },
    /* etc. */
  }
}

Screen.Recording.2025-11-26.at.14.52.23.mov

Challenges / what's next?

• The Edit config is not reactive, which means we need to gather the data elsewhere that's reactive.

Testing Instructions

Run the local storybook (npm install && npm run storybook:dev) and go to "DataViews > Field types > media" story.

[oandregal]

The Edit config is not reactive, which means we need to gather the data elsewhere that's reactive.

Braindumping some thoughts I have:

This is a challenge due to how we set up fields as a standalone objects.

• Perhaps we could define these fields as part of the usePostFields hook, or as part of the PostEdit screen component?
• Is there any other way to declare the data for this component? Can we have a useEditData hook that provides them? etc.

[ntsekouras]

fields are serializable (no need for a specific media component)

How can this be the case when we will need to pass functions like onChangeView and many more for handling the upload functionality? Am I missing something?

Additionally by looking the EditConfigMedia type it feels like we are trying to create a generic API based on the current internal implementation (DataViewsPicker). Though, maybe this might be okay?

[oandregal]

@ntsekouras Yeah, the current state of this PR isn't. That's the core question I'd like to answer: how do we make this reusable and serializable? The API already enables us to provide a custom Edit, but is there a better way?

Potential ideas to follow-up:

• Can we reduce the surface of the API we have right now (be more opinionated, and don't allow all configurations)?
• How does it look like to allow consumers to register/substitute Edit components? Related. For example:

// Pass custom Edit controls:
{
  id: 'media',
  type: 'media,
  Edit: 'wpMedia'
}

// or define custom field types:
{
  id: 'media',
  type: 'wpMedia,
}

Then, separately, there's an API to register either the wpMedia control or the wpMedia field type.

[andrewserong]

Thanks for digging into this idea! I think a challenge here is that ideally the DataViewsPicker (or whatever the picker is) is decoupled from the field. As an example, there's a new media library modal experiment in Gutenberg here (the code lives in media-utils right now):

So it should be possible for folks to use either the new media library, or hook into the existing media library, and for this to be separate from the fields themselves. Another detail is that the picker itself will grow in complexity over time, handle uploads, have its own fields, etc, etc (media-specific fields are being explored in: #73071)

I guess my question for this API is: how do we offer the flexibility that the picker can live elsewhere (and have a common API), but the media field gets to define a common button that invokes that picker. I think it's more the button, displaying a tiny preview of the selected media / clearing media, etc, that's what belongs in the DataViews/DataForm package, whereas the media picker itself should probably live elsewhere.

[ntsekouras]

In general if we want a generic media edit control we need to write a media upload component ourselves, which is quite complex with all the things such a component needs. I think most of the complexity is not around the picker, but the uploading and handling of images and I don't think we need to prioritize this, since our immediate needs are for WP media fields.

I guess my question for this API is: how do we offer the flexibility that the picker can live elsewhere (and have a common API), but the media field gets to define a common button that invokes that picker. I think it's more the button, displaying a tiny preview of the selected media / clearing media, etc, that's what belongs in the DataViews/DataForm package, whereas the media picker itself should probably live elsewhere.

That was what I had understood we wanted TBH and even if we decouple the button for media preview, we'd still need to pass a media upload component.

That's why I think my PR for the mediaEdit (for WP) would be a first step towards our goals (at least for WP media fields).

[andrewserong]

I don't think we need to prioritize this, since our immediate needs are for WP media fields.

Very good point 👍

That's why I think my #73537 for the mediaEdit (for WP) would be a first step towards our goals (at least for WP media fields).

I think I'm with you there — this PR is a good exploration, but it raises a lot of questions about API design and where extensibility points could or should live. I like your idea to focus on the initial step (get a more common component happening within fields, and share it amongst the instances of the media upload fields we have in Gutenberg).

[oandregal]

I'm going to close this one. I'm not convinced this is ready to tackle this way, other approaches we are already investigating would be better.