All this data will come from elsewhere. I want to ship things iteratively to maintain a steady velocity and don't overwhelm reviewers. This follow-up will be tracked at #76544

The icon is not part of the view-config endpoint because I don't know that we'll need it: 1) there's a experiment (Gutenberg > Experiments > Site Editor extensibility) to update how the site editor looks that doesn't use icons, 2) if we wanted them for any entity, we'll need to figure it out how to use/register them from the server.

I'll get this listed at #76544 so it's tracked.

Haven't tested, but I'm curious if an empty object here would cause failures.

Yes because the user preferences (coming from the me/preferences endpoint) or the default view (coming from the new endpoint) can be in flight when this code runs (undefined) and baseView is used in a bunch of places after.

Should we add the context=>array('view') to all of these?

When we support all targets (pages, templates, patterns, inspector), we'll want to filter the response — not every property is useful/should be returned for every target. However, I don't think context is granular enough for that, and I'd think _fields=... would be a better approach.

Should we add mediaField->featured_image here?

I saw you've added below, but that makes me wonder if the default here should not expect the below fields then (author,status).

Yeah, exactly: this is the default for all post types. Until we absorb also the field declarations and remove this client-side logic, it's not entirely clear to me how/where to leverage the existing post type supports. So I thought it's a bridge we can cross later.

Before we had the override for author align in view. Here it seems we only do it for trash

The default view is list, which doesn't provide any layout prop. The layout for table is already set up via $default_layouts. Do you find anything missing? Or the author column field being misaligned?

the author column field being misaligned?

Yes.

I was able to repro by:

• Having a view (with user preference: table layout) in trunk
• Switch to this branch

The issue here is that activeViewOverrides for useView is only taking into account the viewList but it should also take into account defaultLayouts. However, it's not trivial to do that programatically accounting for any view type because the view type is not stablished until later (useView) — so we have a recursive dependency. Before, we just added the table layout always, even if type was other than table.

The proper fix would be to actually add support for defaultLayouts in useView but I've tried that before and it didn't get enough support. I'll get back to this.

In other words: the activeViewOverrides input param of useView needs the view type to compute layout-specific overrides, but it's useView which outputs the view type.

Considered a few approaches:

• What if useView absorbed useViewConfig entirely? It works for consumers (single hook call), but I worry that useView becomes a catch-all hook and composability/performance suffers (some places may only need what useViewConfig provides — without the need to request for user preferences, etc.).
• What if we got the type before useView usage (via preferences store) and use it to compute the active overrides? It's bad devexp for consumers.
• What if we provided all defaultLayouts config to active overrides, ignoring the active view type? The risk is that some layouts have the same prop (e.g., density), and so the last layout destructured in activeOverrides we'll be overriding previous ones. For example, the active layout is table; both table and list have different density, but list is destructured later (density will end up having the list layout value instead of the table layout one):

// pseudocode
const activeOverrides = {
  ...defaultLayouts.table,
  ...defaultLayouts.list,
  // etc
  ...viewListOverrides
}

All things considered, I think useView handling defaultLayouts is the cleanest. Pushed at b50a829

I'm not very fond of this name view_list because it feels ambiguous. Not sure for a better name though.. Could just views work?

views sounds too close to view to make a difference — it's an overloaded term already. Perhaps there's a name in how we call the sidebar/tab list of views? 🤔 I want to avoid to be too much UI centric (tab_list, sidebar_views, etc.) because that ages badly. I don't have a better suggestion than view_list, but happy to iterate (in follow-ups) if there's any.