-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Support custom icons without propType warnings, change name propType to string? #955
Comments
The names in the list of Icon names are SUI icon names. Since we officially support only SUI CSS we then only validate SUI Icon names. I think this makes sense.
Indeed, a great one IMO. One of the reasons that we have specific props for various things, like Also, with a fixed list of possible values we're able to generate a better "component explorer" in the future. You can see the prototype here #427. What to do then?It is important to note here that the end result of all props is a string of <Icon color='blue' name='user' />
<Icon className='blue user' />
// => <i class="blue user icon"></i> I would suggest using In the longer term, I could see somehow supporting different icon sets. Inspired by https://github.com/gorangajic/react-icons. This would fit in line with theming support and some config I've been considering. Some day perhaps... |
you are shockingly fast with good answers. |
For anyone else doing this, @levithomason's answer also works with the shorthand version of icons with a bit more markup: <Icon className="my-custom-icon-name" />
<Button icon={{ className: 'my-custom-icon-name' }} /> |
With the whitelisting of the
name
property of<Icon>
, we can no longer use custom icons without ugly warnings.Previously, we could happily build a custom icon font using such awesome services as Fontello. Performance is important for a lot of reasons and lugging around the entire Font Awesome collection is not practical in a lot of cases (eg. complete rendering on first request with embedded octet stream icon font). Hence I point and click and build a custom icon pack and use that. It is tedious to try to align the names with the existing Semantic whitelist.
@levithomason says in #931 that we cannot add to the list of icons. Wondering what the rationale is for that? Can we change the
<Icon name>
propType
tostring
to allow for custom icons again? Is there an awesome reason why we have to be so strict with the type?The text was updated successfully, but these errors were encountered: