Toolbar Component

[bitpshr]

Enhancement

A Toolbar component should be created that eases the development of standard navigation bars. It should conditionally show children inside of a SlidePane component based on a property and support an opinionated but themable default style. We should look to the Monster card application to see what features (if any) were used in that toolbar implementation. For this initial version, styling should be extrapolated based on other existing components.

Package Version: beta5

[bitpshr]

Toolbar is an interesting component. It's one of the first components we have that's approaching aesthetic-only territory: it offers minimal programmatic functionality, but it's useful for quickly creating common variations of application navigation bars.

As such, I keep gravitating back towards an API along these lines:

w(Toolbar, {
  title: 'My Blog',
  fixed: true,
  collapseWidth: 800,
  actions: [
    v('a', { href: '/#home' }, [ 'Home' ]),
    v('a', { href: '/#about' }, [ 'About' ]),
    v('a', { href: '/#contact' }, [ 'Contact' ])
  ]
});

My thinking: Users can provide a title element action elements. The action elements will optionally be rendered in a SlidePane when the component width is less than the collapseWidth. Both the title and actions can be any DNode, which means events can be attached directly to those elements instead of being propagated up through the Toolbar itself, which is tedious from a properties-perspective. Yes, this architecture is somewhat restrictive: the title element will go in a specific place in the toolbar, and the same is true for actions. But they can be any element and don't rely on being wrapped in some Toolbar-specific child wrapper, and more importantly, why should we care about being somewhat opinionated about a prefabricated UI component? This should satisfy most common use-cases and provide clean extension points for less common use-cases we may not align with.

[bitpshr]

I also thought about using a property like collapsed instead of collapseWidth, meaning that logic would need to be implemented by the parent, but that got me thinking: most parents of a Toolbar would always implement that meta widget width logic, so why shouldn't we provide that? We don't always have to invert control for things that would always need to be implemented by parents imo.