Create <Button /> component about orbit HOT 12 CLOSED

Icon should be a string?

from orbit.

@fallion For me it's string because it's just the name of the icon, like "attachment", "plus-circle" or "remove". When I explored some React components, I've seen few styles and I just liked the "string" as the easiest one.

But everyone is solving this with their own style, we should do what we think is best for us:

• Shopify have just list of icons you can use. This can be good if you don't want someone to use a button that is not in your icon set.
• Instacart allows string or element.
• CA Technolgies have React$Element
• Pluralsigh have Icon component
• Seek adds icons inside the component same as where they put a label

But take these my params proposals more like reference what should we be able to set for every instance of a component.

from orbit.

Just trying to start a conversation around this. We're using React$Element right now so it's up to @jaroslav-kubicek and the team whether to use strings or an <Icon />

from orbit.

I personally just don't like this one:

<Button icon={<Icon name="remove" />}>
    Remove booking
</Button>

The string inside is repetitive for each instance and renaming anything in the <Icon /> component would be hell.

But these specifications are basically starter of a conversation as well. Nothing is set in stone and everything is very open to discussion.

from orbit.

The element is better, I think. Because if you want to use a string you must have all possible icon already imported, even if you don't use there. Of course you can handle it with some async loading but this is not so easy.

from orbit.

What about something like this?

<Button>
  <RemoveIcon />
   Remove booking
</Button>

from orbit.

I think @FilipMessa 's suggestion allows us for a more flexible arrangement of the Button content(icon + label) and let's us extend the content, but maybe that is not even desired as per design system?

Also, it's nice and minimalistic to have pre-defined icons that can be triggered only with a string... I'm still undecided on the fence : )

from orbit.

I mean we could do simple checks with flow by exporting a list of all possible icons and setting that as a prop definition for icon names.

from orbit.

@git-toni There will be very probably version with the button on the right side too, but I was thinking about solving this specifically, as the button on the right usually could be just some type of arrow (pointing down or right, etc.). But I didn't explore all possibilities yet so it's for the future.

About @FilipMessa' suggestion: won't it be hard for this to change the inner padding of a button if there is some icon inside? Also, it can lead us to situations when someone uses for example small icon in large button which shouldn't be even possible or use two icons in one button or whatever crazy combination we can imagine.

from orbit.

@darkwindcz You can specifically style the Icon to be a specific size. This is one of the advantages of having the component as a Prop, you don't have to worry if all Icons will be correctly styled because you can style the Icon directly.

They cannot use 2 icons because it will automatically invalidate Flow, which they should be using.

from orbit.

I believe starting with @fallion's suggestion of a flow check for icon names is a good start, see if we bump into a wall soon.

Regarding the Icon style difference I think @darkwindcz meant that you can do:
<Button size="large" icon={<CloseIcon size='small' />} />, which shouldn't be allowed by design.

from orbit.

@fallion Just one thing about a padding - it's not a static value. Its size depends on the size of the button and if the button has icon or no.

Not sure if there is something more I should add, the final decision which style to use is now on you guys. 👍

from orbit.