To be honest for me, right now, this is way too advanced/complex for a small gain. I'd rather pass the "view" object here as a "temporary API". I can't imagine this "mediaAppearance" API sticking forever either.

I would like to understand better what other kind of "rendering config" we need per field before having a more formal/complex API.

But now, that I think about itrender is also called on DataForm which doesn't have the concept of "view". So my question here, what would be the simplest common denominator thing we could pass here that allow us to achieve the use-case without complexity. For instance I want to avoid resize observers as much as possible personally, can we instead having

config={ config }

with the following type

interface config {
   size?: "small" | "medium" | "large"
}

and each view could decide to pass the right "size" as needed.

• For instance the "media" field in table would always pass "small"
• The "media" field in grid would always pass "medium"
• DataForm would probably pass "small" too

I realize this is close to what you're proposing but there are two changes:

• Simpler because there's no need for resize observers
• More generic because it's not just about "media", later we might want other kind of "rendering config" for fields.

Simpler because there's no need for resize observers

The simpler config won't fix the need for resize observer, because that's already being used to build the grid layout. I just moved it to a different element because it isn't giving accurate numbers in its current location (the layout wrapper).

I did simplify the grid logic as much as I could so it's less dependent on breakpoints, but unfortunately we do still need to know the container size in order to display the right options in the preview size picker.

interface config {
size?: "small" | "medium" | "large"
}

small, medium, large won't really work here because the responsive image logic requires actual numeric values for its sizes attribute. The layout is responsible for setting the image size, so we should get that size from it. Otherwise we're putting the burden on the consumer to figure out what those sizes mean in px and produce a suitable number themselves, which might break if we ever change the layout.

We can call the object something more generic than mediaAppearance; it could be config or something else. But we do need those numeric widths for the responsive images to work.

I've updated to a generic config with a size property that takes a string with the size in px.