Export createSvgIcon from @material-ui/icons

[darkowic]

• I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

Export createSvgIcon function from @material-ui/icons to be able to create custom icons while reusing the createSvgIcon function.

Examples 🌈

import { createSvgIcon } from '@material-ui/icons'

Motivation 🔦

It would be great to reuse the createSvgIcon function in other projects. It is possible to import the function by

import createSvgIcon from '@material-ui/icons/utils/createSvgIcon';

but it is an internal function so the API may change anytime soon without any warning.

[eps1lon]

This is an internal utility that serves our specific purpose. We need to be able to adjust this to our internal needs which makes it unsuitable for public release.

It's tiny enough that you can build your own utility or just use <SvgIcon>{path}</SvgIcon>

[oliviertassinari]

I have seen @dmtrKovalenko face the same problem: https://github.com/mui-org/material-ui-pickers/blob/next/lib/src/_shared/icons/ArrowDropDownIcon.tsx#L2.

So far, we have

• core: 1 duplicated version
• lab: 1 duplicated version
• icons: 1 duplicated version
• pickers: import a private version from core

[eps1lon]

I have seen @dmtrKovalenko face the same problem

This is not the same problem though. You're talking about internal usage which is quite different from public release.

[oliviertassinari]

You're talking about internal usage which is quite different from public release.

@eps1lon Well, I believe we have no precedent of importing private modules between @material-ui/x packages, but I don't see anything wrong with it, as we can control these imports (not the case when in third-parties code) :).

What do you think of refactoring "lab" and "icons" to follow the approach of "pickers"? I would reduce the bundle size (deduplication for private usage).

[darkowic]

This is not the same problem though. You're talking about internal usage which is quite different from public release.

It's kind of util that could be reused between different internal packages but also outside - like in my project where I need to create several custom icons.
Creating new util is not a big deal ofc but still, it is some duplication that could be avoided.

[oliviertassinari]

@darkowic For the public aspect, I think that we could delay the effort to a point where we have more user requests. Also, I think that we should look into how it fits with the SVGR ecosystem before moving forward.