RFC: Consider component augmentation

[levithomason]

Dropdown

Copied from #401 regarding the icon prop. This conversation now applies to all Dropdown types.

Preliminary Findings

The Dropdown supports many variations, including rendering as a Button or a Menu Item. Here is what I've gathered that helped clarify some things for me:

• There is only ever one icon
• Dropdowns can appear as other components like a Button or a Menu Item
• The icon is either a Dropdown icon, Button icon, or Menu Item icon but only one at a time

---

Brainstorming Solutions

Given the above, we may be able to use a single icon prop after all. It would just be applied to as either a Dropdown, Button, or Menu Item icon.

Our offline work going on with Forms may introduce a pattern that is helpful to Dropdowns as well. We may allow either component augmentation or specialized subcomponents in Form.Fields. This will facilitate our shorthand props API for Forms. Here are some of the ideas we are playing with:

<Form.Field control='input' type='password' label='Enter password:' />

<Form.Field control={Checkbox} label='I agree to the terms and conditions' />
// or
<Form.Checkbox label='I agree to the terms and conditions' />

<div class="field">
  <label>Enter password:</label>
  <input type='password' />
</div>

<div class="field">
  <Checkbox label='I agree to the terms and conditions' />
</div>

There is also a need library wide to explicitly set the element type for a component. Example, you may want to render a <Segment /> as an HTML <section />. We are considering a library wide standardized prop such as:

<Segment />
<Segment elementType='section' />

<div class="ui segment"></div>
<section class="ui segment"></section>

Applying it to the Dropdown

All of these ideas are ways of augmenting components. I have not thought this idea through at all, but it seems like we might support something along the lines of:

<Dropdown icon='filter' options={...} />
<Dropdown.Button labeled icon='settings' options={...} />
<Dropdown.Item icon='dropdown' options={...} />

// or

<Dropdown icon='filter' options={...} />
<Button elementType={Dropdown} labeled icon='settings' options={...} />
<Menu.Item elementType={Dropdown} icon='dropdown' options={...} />

The top group Dropdown.Item is already taken, so we'd have to solve the name conflict.

The latter group I think makes more sense. Consider the Button, all the props are regular button props (labeled, icon, etc) then the extra props (options) are passed to the Dropdown. This would result in a SUI dropdown being rendered with all the props/classes of both the Button and Dropdown.

As I write this, I'm thinking it might help users better understand the augmentation if we use the prop name as:

<Button as={Dropdown} labeled icon='settings' options={...} />
<Menu.Item as={Dropdown} icon='dropdown' options={...} />

// or

<Dropdown as={Button} labeled icon='settings' options={...} />
<Dropdown as={Menu.Item} icon='dropdown' options={...} />

MenuItem

Copied from https://github.com/TechnologyAdvice/stardust/pull/382#discussion_r75179898

Many other components and use cases have us considering the use of a library wide as prop:

<Segment as='section' />
//=> <section class="ui segment"></section>

<MenuItem as='a' />
//=> <a class="item></a>

<Dropdown as={Button} options={[...]} />
//=> <div class="ui button dropdown" />

Especially handy for react-router use with the MenuItem as it would allow passing props for both components:

import { Link } from 'react-router'

<MenuItem link as={Link} to='/home' activeClass='active' />
//=> <a class="item active"></a>

The MenuItem would consume its own props (link) and spread the rest. The as prop here means the MenuItem would render like:

render() {
  const ElementType = getElementType(props) // new util, like getUnhandledProps()

  return <ElementType {...rest} /* other menu item props */ />
}

The getElementType() method would hold the logic for returning the value of the as prop, else if props.link return a, else div. We could add more logic to how components are allowed to determine their element type as well. This is good because all components would be consistent.

[layershifter]

Linking #382

[levithomason]

Thanks, I updated the title include all components. I also copied over the relevant MenuItem comments to the description.

[jeffcarbs]

We started implementing a lightweight react wrapper around SUI before coming across stardust. This is one of the missing things that's keeping us from switching over to stardust entirely.

We've solved this issue exactly like your MenuItem example (we named our argument el, but as reads well also):

• For the component type, accept either:
  • the name as a string <MenuItem el='a' />
  • a component type <MenuItem el={Link} />
  • default depending on the component. Usually just div but e.g. for <Button> the default is button
• Pass any unhandled props to the el

In your form example, this would mean:

// Good 
<Form.Field as={Checkbox} label='I agree to the terms and conditions' />
// Bad
<Form.Checkbox label='I agree to the terms and conditions' />

A reason to advocate for this is it allows the library consumer to pass arbitrary components, not just the ones included in stardust. For example, if I implemented my own custom checkbox component I'd be able to use it in the first case. The react-router Link is another example of this.

[levithomason]

@jcarbo appreciate the comments. I fully agree with your points. We also already spread unhandled props on the root node, so this will come for free once the root node is dynamic. I also like el as a prop name and will consider using it.

Did you guys have any prop conflicts? I'm thinking of cases where two components take the same prop name, the first will consume it while the second may have needed it as well. Or, duplicate classNames: <Dropdown as={Button} /> will have classes ui button ui dropdown. Did you run into any of this and if so, how were those handled?

I'd like to hear from @davezuko on this as well. I want to start on implementation for this today if at all possible.

[levithomason]

@jcarbo also:

This is one of the missing things that's keeping us from switching over to stardust entirely.

If this is one, what else?! :) This project is the culmination of the greatest SUI React ideas out there. We don't want to create another SUI React project, this project is joining the disparate efforts into the SUI React project. I believe we'll have better features and better support if we're in it together. If you've got any other features or patterns that are better than what you see here, please do share.

[jeffcarbs]

Did you guys have any prop conflicts? I'm thinking of cases where two components take the same prop name, the first will consume it while the second may have needed it as well.

We haven't run into this yet, but my initial thought would be having a prop (e.g. elProps) to explicitly pass props down. For example:

render() {
  const ElementType = getElementType(props) // new util, like getUnhandledProps()

  return <ElementType {...elProps, ...rest} /* other menu item props */ />
}

// Usage
<Dropdown el={Button} elProps={{ icon: 'search' }} icon='dropdown' />

The default behavior would still remain re: rest so you'd only need to use that extra prop to avoid collisions.

Or, duplicate classNames: will have classes ui button ui dropdown. Did you run into any of this and if so, how were those handled?

I don't think this would pose an issue, although if it did I could see extending the class name helper to unique the values.

This is one of the missing things that's keeping us from switching over to stardust entirely.

Off the top of my head it's mainly just customization of some elements to fit our specific needs, although I'm sure we'd probably be able to just wrap these components if need be. I'll try to think about this a bit more and get back to you with some concrete examples.

[levithomason]

Cool, we're on the same page again. You can expect this to roll out soon. Keep us posted on your findings.