New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Toolbar Component #386

Closed
bitpshr opened this Issue Nov 20, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@bitpshr
Member

bitpshr commented Nov 20, 2017

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

This comment has been minimized.

Member

bitpshr commented Nov 27, 2017

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 bitpshr self-assigned this Nov 27, 2017

@bitpshr

This comment has been minimized.

Member

bitpshr commented Nov 27, 2017

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.

@bitpshr bitpshr referenced this issue Dec 8, 2017

Merged

Toolbar #397

3 of 3 tasks complete

@bitpshr bitpshr closed this in #397 Dec 13, 2017

@dylans dylans added this to the beta.5 milestone Dec 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment