**Feature:** TopBar components

[peterszerzo]

Summary

Adding Topbar, TopbarButton and TopbarSelect to components.

To be tested

Me

• No error or warning in the console on localhost:6060

Tester 1

• Things look good on the demo.

Tester 2

• Things look good on the demo.

[peterszerzo]

Add Toolbar Component to operational (extract from Pantheon UI)

[ImogenF]

Looks great!
Just a few comments, but all personal opinion so feel free to disagree 😉

• The TopbarSelect component styling seems a bit off to me. I feel like there should be more distinction between the label and the selected value.
  
  Maybe the label could be moved a bit further left, or the font made a bit darker?

• The "x" icon looks really large compared to the others
  

[TejasQ]

I'm not so sure about the level of granularity of this component's parts: why do we need specific TopBarButtons and TopBarSelects? I feel like we had a similar approach with CardHeaders and we eventually did away with them. Could it be that we're going down a similar path here that we might want to change later?

[TejasQ]

Suggested change

	background-color: #fff;
	background-color: ${props => props.theme.color.white};

[TejasQ]

We could make this a single rule?

Suggested change

	& > * {
	& > :not(:last-child) {

[TejasQ]

Would the following work?

Suggested change

	font-weight: 600;
	font-weight: {$props => props.theme.font.weight.medium};

[peterszerzo]

@TejasQ the reason we have subcomponents is that said subcomponents can compose in a much more flexible way, either on the left side of the top bar or the right, in any order, repeated any number of times. Contrast that with a card header that is always at the top, and where it is obvious to put header contents in a title and actions prop. If we went down the same road for top bar, it would turn out pretty confusing.

[TejasQ]

Makes sense. I'm also a little unsure of the variants of Select and Button. It seems a little smelly to me that our own Buttons and Selects don't compose comfortably into this component and we need whole new components that essentially serve the same function. I'm not sure what the right solution might be, but this feels little off because it is currently a duplicated responsibility.

What if we do a major button overhaul and we miss these because the TopBar isn't as widely used as generic Buttons? This is the reason for my concern.

Finally, I'm also a little bit concerned about the naming. Naming things is an age old problem, but I'm wondering if TopBar can get confused with HeaderBar since HeaderBar is actually at the top (and so what does that make TopBar?) It gets a little more confusing when a Page's title is thrown into the mix. I'd suggest naming this PageToolbar or Toolbar in order to more clearly describe its intended usage.

[peterszerzo]

Button's and TopbarButton's are very different both visually and in the way they interact with siblings (same goes with Select and TopbarSelect), to the point when we'll set up API's that cater to both places, it'll turn into a maintainability nightmare (think of all the ternaries in styles, the discriminating union interfaces etc.). Having separate components keeps both usage and readability sane, and allows components to evolve independently.

As far as naming goes, clarity and conciseness will always fight a battle, and at this point I'd rather stick to the way we call them during the design process. I'll clear up the possible naming confusions in the documentation.

[TejasQ]

Button's and TopbarButton's are very different both visually and

Ah, I see. I misunderstood: I thought the blue thing that looked like a Button from the screenshot attached to this PR was a TopbarButton in this case. My bad.

That makes sense.

Awesome. It looks good to me so far. One final thought I have is this:

We have different padding (revealed via hover) on the elements of the other Topbar, HeaderMenu where the selects/buttons (Avatar in this case) have the padding inside them, instead of the actual bar itself padding its children.

Design-wise, I don't have the context, but these two cases aren't consistent and I'm wondering if that's the direction we're intentionally wanting to go here.

[peterszerzo]

@TejasQ the blue thing is a barebones regular Button component, whereas TopbarButton is used to render the undo-redo buttons.

The idea is that there are buttons and selects that blend in seamlessly into top bar, taking up the full height and having nice opinionated borders, and, when needed, other components can be added.

[TejasQ]

Looks good.

[fabien0102]

@TejasQ Is this ready to merge?

[TejasQ]

It looks good to me. If you approve, I say we can merge it. 🙂