When to use it

Use Icon when application code wants the same semantic icon language that the SDK uses internally. It is the fastest path for rendering things like search icons, trust badges, cart chrome, and small decorative affordances without coupling your code to a specific icon library.

Reach for useIcon() instead when you are building your own composed component and need the resolved icon component directly.

Slot strategy

The icon system has three layers:

• IconSlotMap defines the complete semantic contract.
• EnadProvider receives the active slot map through icons.
• Icon and useIcon() read from that provider and render the resolved component.

If you do not pass icons, EnadProvider uses phosphorIcons by default.

For most apps, pick one of the shipped curated adapters for the whole tree:

• phosphorIcons
• lucideIcons
• hugeIcons
• carbonIcons

If a brand wants full control, supply a complete custom IconSlotMap.

If you only need to replace a subset of slots, use createIconifyIcons({ names }). That lets the app keep the SDK's semantic slot contract while sourcing selected icons from Iconify.

State and theming guidance

Icons inherit their visual tone from normal classes like size-*, text-*, and layout utilities. Keep decorative icons aria-hidden, and give icon-only buttons their own accessible label on the interactive parent.

For Iconify-backed setup, keep the mapping explicit and use the standard prefix:name format shown by Icones. Any slot you leave out falls back to Phosphor unless you pass a different fallback map, so partial migrations are safe and incremental.

Use adapter overrides when a curated family is almost right and you only need to swap a couple of slots. Use a full custom IconSlotMap when the product has its own icon library and every slot should be owned locally.