[DataViews]: introduce DataViewsContainer component

[retrofox]

Closes WOOA7S-124

Note

This PR is one of two alternative approaches currently being explored for improving DataViews composition.
Please also see [DataViews]: Support dual rendering mode (controlled props or free composition) #102996 for the other direction we’re considering.

Introduce DataViewsProvider, a new wrapper component that allows free composition using the existing DataViewsContext.

Why are these changes being made?

Our goal was to enable a more flexible usage of DataViews, where developers can access data and shared config from context, without relying on the built-in layout rendering or manually passing props through the component tree.

We initially explored supporting both "controlled" (rendered) and "headless" (composed via children) behaviors directly within the DataViews component.
However, this approach introduced complex conditional prop logic and made type inference unstable, particularly when working with optional children and conditional data/view combinations.

Additionally, this duality made the TypeScript definitions fragile and more complex to maintain or extend. In multiple iterations, we encountered type assertion issues, context mismatches, etc.

To reduce maintenance risk and preserve backward compatibility (both in runtime behavior and type definitions), we opted to create DataViewsProvider as a lightweight facade. It provides only the context layer, allowing custom rendering logic while preserving the same context shape and types.

This setup also ensures we keep the DataViews component aligned with Gutenberg’s implementation, minimizing divergence and simplifying future upstream merges.

Testing Instructions

• Run yarn dataviews:storybook:start
• Verify that DataViewsProvider renders correctly using FreeComposition story.

• Confirm DataViews behavior remains unchanged in all existing stories.

⚠️ react-docgen-typescript has known issues parsing advanced generic types. We’ve added a scoped override to ignore props from DataViewsProvider in Storybook docgen to avoid build-time crashes.
See: styleguidist/react-docgen-typescript#356

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-142285

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-142285&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-142285&env=a8c-for-agencies

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[youknowriad]

Thanks for the PR, this is close to what I had in my, but why a new component instead of just passing the "children" prop to the DataViews component.

• when the children prop is passed to the DataViews It would only render the <DataViewsContext.Provider which it already renders
• when the children prop is not passed, it would work just like today.

In other words, the DataViews component is the provider when "children" are passed.

[retrofox]

Yes, I know this is the approach we discussed yesterday.

The issue with this “dual” behavior is that I ran into a TypeScript problem I couldn’t solve properly. If we go this route, we might introduce a breaking change at the TS level.

Assuming that’s true, would it still be okay to move forward with an approach that could trigger TS errors when users update the package?

Or should we consider releasing a new major version where TS compatibility is not guaranteed?

[retrofox]

Thanks for the PR, this is close to what I had in my, but why a new component instead of just passing the "children" prop to the DataViews component.

@youknowriad this is the PR #102996 that implements what we agreed yesterday, with some notes about the TS issue.

[retrofox]

closing in favor of #102996