Allow setting the default icon set

[davidjamesb]

Hey @mathewtaylor.

I previously contributed the Font Awesome icon package which we are using across our application.

We're in a scenario now where we have a mix of icons - with our custom components using Font Awesome and the default out of the box Blueprint components using Lucide.

It's not a huge deal, but it does mean we have inconsistencies in our design. It would be great if we had an option to override the default icons used across Blueprint and wanted to get your thoughts before I take a stab at it myself.

I can see two possible approaches:

1. Provide a global configuration object that can set the icon set application wide and modify the components to switch out the icon based on the chosen icon set. We would need to ensure each available icon set has a like-for-like icon.

This global configuration idea has also been raised in #488.

2. Expose RenderFragments (e.g IconContent) for all current components that have icons out of the box. Stick with Lucide for the default but give the user an escape hatch to be able to override each one.

Neither approaches seem trivial but I know we already expose IconContent in some components so maybe that approach is preferred.

Any other ways you would recommend that we could extend Blueprint so we can align icons across our design?

Thanks.

[mathewtaylor]

Hi @davidjamesb — sorry for the slow reply, v4 ate the last few weeks. Short version: yes, I want this, and I would be glad for you to take it. Thank you for asking before building.

I went and measured the surface before answering, because the numbers decide between your two options:

• 63 distinct icons, across 180 usages in components
• 8 components already expose a RenderFragment? Icon or IconContent
• 7 take a string? Icon name

On your option 2 — a fragment per icon

I would not go this way as the primary mechanism. 180 usages means roughly 60 new RenderFragment parameters even after collapsing to one per component, the API-surface snapshot grows by the same amount, and — the real problem — it does not answer your actual question. It gives you a way to override this icon at this call site. It does not give you "make my whole application consistent", which is what you are after. You would end up wrapping every Blueprint component just to pass the fragments through.

On your option 1 — a global switch

This is the right shape, but I would not key it on icon sets. That needs a like-for-like mapping of all 63 icons across Lucide, Font Awesome, Heroicons and Feather, maintained forever. Coverage is not 1:1 — Feather ships 286 icons against Lucide's 1,750 — and the day a component starts using a 64th icon, three of those four mappings silently fall back without anyone noticing.

What I would build instead

A provider keyed on a closed set of semantic roles the library owns.

public enum BbIconRole { ChevronDown, Check, Close, Search, Calendar, /* …63 of them */ }

public interface IBbIconRenderer
{
    RenderFragment Render(BbIconRole role, int size, string? cssClass);
}

Components render <BbIcon Role="BbIconRole.ChevronDown" /> rather than <LucideIcon Name="chevron-down" />. The default renderer maps roles to Lucide, exactly as today. You register a different one and the whole library follows:

builder.Services.AddBlazorBlueprintComponents();
builder.Services.AddBlazorBlueprintFontAwesomeIcons();   // or your own IBbIconRenderer

Why roles rather than set names:

• The contract is finite and ours. Anyone mapping Font Awesome covers 63 roles, not "every icon in every set".
• A 64th role cannot be added silently. It is an enum member, so every renderer has to supply it or fail to compile.
• The library takes no dependency on the icon packages. A provider can ship from a separate package — including one you own.
• One registration covers the application, which is the thing you actually asked for.

The existing RenderFragment? Icon parameters stay as the per-instance escape hatch. They already exist on 8 components, so that half of your option 2 is effectively shipped.

If you want to take it

I would split it so the reviewable decision comes first:

1. PR one — the BbIconRole enum, IBbIconRenderer, the BbIcon component, and the Lucide default renderer. No component changes. This is where the design gets argued, and the role list is the part worth getting right.
2. PR two — convert the 180 usages over.
3. PR three, optional — a Font Awesome renderer package.

Branch off develop. Shout if you want the role list pulled out of the source as a starting point — it is a one-liner to generate and I am happy to do it.

Related: this is a concrete instance of #488 (global defaults), and it lands in the same registration shape, so the two should stay consistent.