Level of control of non trivial components.

[raplemie]

I'm looking at creating the Header component out of the Header iTwinUI-css (which is still in progress at the moment).

I'm wondering at which extent we expect such a component to control what it can be used with ?

Header

For example, current demo of header have this:

• Left part contain:
  • application (iui-application)
    • an app icon (SVG, iui-icon),
    • a title (text, optional),
  • a divider (iui-divider),
  • a project button (iui-header-button, optionally iui-detailed, iui-active)
  • a chevron divider (SVG, iui-chevron).
  • a iModel button (same as project)
• Center part contain:
  • Anything, we dont control any classes within, so it's up to the user.
• Right part contain:
  • Notification (borderless SVG button)
  • Help (borderless SVG button)
  • User icon (custom, with controled size and transitions)
  • More (borderless SVG button)

Left part

Application is quite simple, just not sure if we allow anything for icon and always tag iui-icon to whatever we are given, or we restrict to SVG ?

We should probably have a component for HeaderButton for Project and iModel button, as some application might want to build other flavor of these (Plant button, Asset button, and so on), however, should we recieve an array of those buttons and force a chevron in between, or just leave everything after the divider to the user and let them put chevrons as they see fit (leaving likely to have applications that will use chevrons, straight lines, no dividers...) ?

Right part

To which extent do we want to enforce the standards ? We can either again, leave that to the users to put whatever they want in there, and "document" that a user icon with iui-user-icon will update the transition and size, or we fix the content, Help, User icon and More likely have MenuItems attached, depending on the application, but we likely want these to be always the same order/icons for every application so we have some standard...

[mayank99]

Agree with having a separate HeaderButton, which can be passed into an array for easy chevron dividers.

I would rethink the "left" vs "right" approach. Having individual props for help, user icon, etc might also not be a bad idea but maybe we could combine those into smaller groups rather than just one big "right" part.

As for the "center" part, I think that should be handled by children.

Maybe something like:

type HeaderProps = {
  appIcon: React.ReactNode;
  appName?: React.ReactNode;
  buttons?: React.ReactNode[]; // pass `HeaderButton`
  actions?: React.ReactNode; // pass notifications icon, help icon, etc
  userIcon?: React.ReactNode; // pass `UserIcon`
  moreOptions?: React.ReactNode[]; // pass `MenuItem`s
  children?: React.ReactNode;
  ...
}

Using ReactNode allows the user to pass anything, which makes it flexible.

[raplemie]

Also, left and right is just how the structure is divided, I did not intend to put it in the api itself.

[mayank99]

We use ReactNode everywhere for a couple reasons (I think passing strings was one reason. Maybe @veekeys can comment). When we need to cloneElement, we just cast it to JSX.Element as needed.

Maybe not everything needs to be ReactNode but that's a different discussion 😄

[raplemie]

casting is not really a safe solution with ReactNode, given the quantity of things it can actually be, but I guess we can work with it and validate what it actually is if we need the clone:

• A ReactNode is an array of ReactNode too :), so no need for ReactNode[] :)

[mayank99]

Explicit array type is better to prevent user from not passing an array. But discussing types and stuff can be done in your PR.

This original discussion is about how much control we provide through props. I think what you said all makes sense except the really small stuff. I don't think the user should be in charge of putting dividers or providing a 3 dots menu icon.

Also they shouldn't need to know about our CSS classes.

[veekeys]

Most of the stuff makes sense to me too. I would agree having a specific props for certain "standardized" places (user icon, menu). The only part which need to think about is those additional icons on the right.. If we want to ensure their order, we might want to put them as separate props too.. But then I guess still need to leave some kind of a way to pass there what ever else users might need.
Do we have more examples of header implementation what could go else in there and also on the left side (where usually project and other selections are)?