Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Improve usage of icons

See original GitHub issue

I’m in the middle of replacing my custom Material UI typings/wrappers in my pet project (https://github.com/krzema12/fsynth), and noticed several problems with using icons:

For icons to work, one has to add this piece to the <head> section of their HTML: <link rel="stylesheet" href="https://fonts.googleapis.com/icon?family=Material+Icons">. Without it, icons are replaced with their names cropped to the button’s size. This approach is problematic because:

it’s not included in the docs, and it’s just another implicit dependency to add. It took me a while to find it, and I found it by looking at the test app (thanks for it!)
it makes another web call which in some circumstances may not be possible (running the app offline) or slow (slow Internet connection)

Names of icons accepted by mIcon and mIconButton are just strings. It’s not clear what naming convention is used (it’s e.g. play_arrow, not PlayArrow as presented on Material UI website). It’s also prone to typos.

I recommend making the usage of icons more type-safe and self-contained. Adding implementation(npm("@material-ui/icons", "4.9.1")) may still be needed, but at least we can get rid of including the font. There’s an alternative way of using icons, without fonts: as regular components. See e.g. https://github.com/krzema12/fsynth/blob/master/web/src/main/kotlin/it/krzeminski/fsynth/typings/materialui/icons/PlayArrowIcon.kt.

I’m keen to prepare some pull request in my spare time. If you have any thoughts on this, let’s discuss it 😃

Issue Analytics

State:
Created 3 years ago
Comments:6 (3 by maintainers)

Top GitHub Comments

1reaction

Cottandcommented, Jan 9, 2021

I went for mSvgIcon and had great results. I borrowed the path from here. The license is permissive enough.

1reaction

cfnzcommented, Aug 21, 2020

Thanks for that.

In terms of changing mIcon, I am thinking it will be best to closely follow the Material-UI way of doing things. Currently their Icon takes a string child as the name of the icon, so I think we should leave mIcon the way it is and introduce something new. That way everything keeps working, new icons can be added easily and it follows Material UI’s Icon component.

Muirwik does not have an SVG icon whereas Material-UI does. So I have added mSvgIcon which is similar in use to the Material UI SvgIcon (will release it soon). In Material-UI all the other icons take on the same props as SvgIcon (or uses SvgIcon to create their icon).

Material-UI has over 5,000 icon files (including versions for Outlined, Rounded, Sharp, etc), each as a separate component. I think this helps with code splitting. So we need to decide if we are going to auto generate 5000 kotlin files, or do it some other way. The Kotlin dead code elimination might mean we don’t need a file for each icon, but having one in each file might still help with code splitting/DCE and it is a bit more like Material-UI. Then we would have things like mAccessAlarmIcon, etc (etc, etc, etc, etc…).

So I think this is the bigger task, having the build create the appropriate files, however many they may be.