Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: [Feature] DataViews.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

Size Change: -821 B (-0.03%)

Total Size: 2.57 MB

_{compressed-size-action}

Thanks for scratching the itch @jameskoster, I always think it's good to try out these ideas in code and see how it feels. It's compelling! Conceptually I also like the idea of the container handling the scrolling. In practice, though, I believe it introduces another issues which is that the footers don't stick to the bottom of the container when there isn't enough content to push it out to the bottom. Here's some screenshots from the Pages view and of the Media modal:

This PR (footer isn't sticky)	Trunk (footer is sticky)

While these issues are blockers, I wouldn't say it necessarily rules out your idea here. And now that we've standardised on 24px padding in trunk, I do think it's a good idea to continue exploring our options.

What do you think about these "sticky" issues... worth pursuing further or does it feel like a deal breaker?

The one other tiny issue I ran into is that while focus styles on buttons are working pretty well, the badge on an active filter gets cut off:

Oh shoot, I didn't test a list that doesn't fill the container so didn't spot the footer problem, thanks for pointing that out. Maybe a simple min-height: 100% somewhere would solve that 🤔

Padding aside, the more I wrestled with the position: sticky issues the more I began to wonder whether it might be better to use 'free composition' to create specific layout configs for scenarios like DataViews in a Modal, Page, or Card. In an ideal world (and what I think we'll aim for on the DS side) is introducing container subcomponents like Page.Footer, Page.Body which will handle layout, scrolling and stickyness. So then it would just be a case of placing the DataViews pagination controls etc. in the appropriate subcomponent. Then we could remove most of the sticky styles from DataViews.

This 'make DataViews less opinionated about layout and style' topic is a huge rabbit hole 😅

Indeed, I think we'll encounter lots more cases where free composition feels like the right approach given how many different things using DataViews will want to inject buttons or little bits of UI in various places. That said, it's also good for there to be a version of things (e.g. DataViewsPicker) that kind of "just works" without the consumer needing to know about where to put things 🤔

In an ideal world (and what I think we'll aim for on the DS side) is introducing container subcomponents like Page.Footer, Page.Body

Yeah, I was just thinking that about Modal, too, that it's very common to want a sticky footer with actions, etc, and it'd be nice for consumers not to have to worry about how to do that reliably.

This 'make DataViews less opinionated about layout and style' topic is a huge rabbit hole 😅

But yes, it's a big topic indeed! Thanks for continuing the discussion / ideation. Hopefully we can get there in little steps 👍