Perspective: Fluent UI React developers are currently leveraging icons in their app today.
Today, we have a @uifabric/icons
package. It contains 1200+ font-based icons based on the MDL2 design (reference pointer to MDL2) language. Developers in Microsoft and OSS (especially SharePoint developers) use these icons to build experiences.
Fabric core is a css library, which also exposes a stylesheet which vanilla HTML developers can use to reference the MDL2 icons using classnames. (E.g. ms-Icon ms-Icon--Add
)
Additionally we have scaffolded @fluentui/react-icons
package as a solution for React developers. The icons are represented as React components and use SVG icons.
Teams uses a different set of icons, which has been packaged under the @fluentui/react-icons-northstar
package.
Lastly we have a new set of mobile-based icons living in the microsoft/fluentui-system-icons
repo. There are approximately {TODO: fill in } icons living there, different from the other sets, and exposed only as SVG and PDF resources.
TODO
TODO
Web
Angular developers - what do they do?
React-native…
Developers want a single story that works well for their platform. Focusing on web first, this would look like this:
outline
or even just color1
vs color2
)React developers should use the @fluentui/react-icons
package for the latest icons. This package includes all of the icons from MDL2, with updates from the mobile set. That means that if Chevron
icon has changed, developers get the update intuitively by using the package.
Developers using the current @uifabric/icons
font-based package won't get updates. We stop publishing this.
The react-icons-northstar
package goes away and we consolidate it into react-icons
. One package so that we don't confuse partners.
So for React devs:
For non-React developers, we can provide raw SVGs to leverage:
We can also produce a stylesheet akin to Fabric Core which defines classnames which create background images pointing to the SVGs on the standard cdn.
TBD
TBD
If some icons cannot be distributed in the primary package, we should separate them out into a separate license sensitive package that customers opt into, following whichever legal restrictions are necessary. We should provide a clear disclaimer on the readme on the package, rather than a oneliner in the LICENSE that points to a poorly worded Word document.