New OverflowContainer wrapper around useOverflow

[r100-stack]

Changes

Pulled out of #2120 as PR 3 in the PR stack (PR stack order).

This just adds the OverflowContainer component from the combined PR but continues to use the existing useOverflow algorithm. Additionally, all components now use OverflowContainer instead of useOverflow.

• OverflowContainer: Takes the items prop (would like be remove in later PRs in the PR stack), passes it to useOverflow(), and put the returned visibleItems along with the items.length in a context.
• useOverflowContainerContext(): Can be used in components under OverflowContainer to access the context values in OverflowContainer. (#2152 (comment))
• OverflowContainer.OverflowNode: Wrap overflow content in this component to conditionally render it when overflowing.

I also had to make a small css change to make the iui-breadcrumbs-list stretch to the width of iui-breadcrumbs. This was needed to constrain the width and thus trigger an overflow when the width of the container is smaller than the required width.

Testing

• All tests continue to pass

Docs

• Added pertinent JSDocs.
  • Since OverflowContainer's API will change, the JSDocs are currently concise. They will be expanded upon in later PRs in this PR stack.
• Added changeset

After PR TODOs:

• Re-think the polymorphic as-prop (#2152 (comment), #2135 (comment))

[mayank99]

This render prop branching isn't nice, and kinda defeats the purpose of extracting a component (it's basically a hook with extra steps). What is the main reason for calling children as a function?

I'm wondering if it would be better to expose a subcomponent instead.

<OverflowContainer>
  <>{/* regular nodes */}</>

  {/* this is rendered only when overflowing */}
  <OverflowNode>…</OverflowNode>
</OverflowContainer>

[r100-stack]

What is the main reason for calling children as a function?

I thought of offering the children as a function approach for more customized cases (e.g. Breadcrumbs, MiddleTextTruncation, etc.) that have overflow in the center. With a function, we can get the visibleCount and return custom content based on that.

I'm wondering if it would be better to expose a subcomponent instead.

I will try looking into this approach as an alternative of the children as a function approach.

[r100-stack]

I played around with having an OverflowContainer.OverflowNode that only renders its children when it overflows and having an OverflowContainerContext that gives the visibleCount that the OverflowNode can read (https://github.com/iTwin/iTwinUI/pull/2152/files/2758496d61824cb1133b4baeb4155511d2f30033..abd6485a7f996d211cb507ed9585761077a2eb02). This eliminated the need for the children as a function.

I will fix some a minor regression and improve the code a bit more soon as I first wanted to play around and confirm the API.

[mayank99]

Yeah, the new context API makes sense. I think we should also have a hook called something like useOverflowContext. It would just be a wrapper over useSafeContext(OverflowContainerContext), with the main goal of allowing to easily destructure the return value without needing to import useSafeContext or OverflowContainerContext.

My main concern with the context API is the need to extract child components. While it's generally a good idea to have lots of smaller components rather than one large component, it makes the diff too large in some cases (e.g. TablePaginator).

[r100-stack]

I think we should also have a hook called something like useOverflowContext.

Added the hook. I called it useOverflowContainerContext since the context is linked with OverflowContainer instead of useOverflow. (a05e8d4 + 99e3536 for one leftover usage in OverflowContainer.tsx)

My main concern with the context API is the need to extract child components. While it's generally a good idea to have lots of smaller components rather than one large component, it makes the diff too large in some cases (e.g. TablePaginator).

That's true. But as of now, I kept the context approach since it solves some of the other problems that we had with the OverflowContainer API from this PR.

[Ben-Pusey-Bentley]

I don't have any issues with this PR that don't already have comments, so I am approving this.