Skip to content
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

Create a better default helper/behavior for including subcomponents #138

ixley opened this issue Sep 2, 2016 · 1 comment


None yet
2 participants
Copy link

commented Sep 2, 2016

The default partial include and render helper (for Handlebars) makes for some undesirable and somewhat confusing defaults. With an acknowledgement that there are natural shortcomings of different templating languages, here are a few desirable attributes of component helpers.

Default Usage = Simplest Syntax

Ideally, the helper will assume the most common defaults so additional parameters are only needed for additional specificity or customization.

With Handlebars, the default template include doesn't bring along a components contextual 'default' values, which makes for an unintuitive experience. Let's flag this as a shortcoming of the templating language, but also posit that in most cases, subcomponents should include default values.

Default Usage Assumptions

Despite the acknowledged shortcomings, I'll reference Fractal's existing implementation of Handlebars for examples.

Components inherit values by default

Assume that components and (nested) subcomponents should render with a basic set of defined default values.

  • ex: {{render '@component-name' reference-name merge=true}} currently most closely resembles the ideal default behavior, but is overly verbose.

Merge component values by default

Default values can be overridden with more direct contextual values (i.e. subcomponents will inherit any passed values with the specificity of the component they are referenced in, but still default to the inherited values for anything not overridden by a parent).

  • ex: if component footer includes button-nav which in turn, includes instances of button, by default, each instance of the button component in footer should include default values from button.config, overridden by any values passed from button-nav.config, and then any final customizations passed by footer.config.

Only strip values from nested components when specified

It should still be possible to clear default values without passing in new ones – it is useful at times – but should be treated as the exception rather than the default behavior.

This behavior may make sense for Handlebars templating, in general, but seems counterintuitive for building a component library!

Inherit handles from base component.

Nested subcomponents can be given new handles for more appropriate contextual targeting, but in the absence of a new 'reference name', they should inherit the base component's name.

If a component includes multiple instances (at any nesting level), it makes sense to give unique handles for referencing in a new context. By default, however, components should just inherit their original handles. If values are only taken from components that nest them, it should make for a rare collision.

  • ex: Again with Handlebars as a reference, with {{render '@component-name' [reference-name] merge=true}}, reference-name should equal component-name without needing to be specified. Again, the default is to inherit (the name), with the ability to customize.

This comment has been minimized.

Copy link

commented Jul 12, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jul 12, 2018

@stale stale bot closed this Jul 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.