After updating my dependencies, I get this error everywhere I use an <Icon> component.

the trait bound `MaybeSignal<leptos_icons::Icon>: From<leptos_icons::CgIcon>` is not satisfied

I checked that all the versions and feature flags are correct (ssr and hydrate were removed right?) I have no idea how to fix this. I'm using icons in too many places so it would be tedious to go and remove it.

Any help is appreciated. TIA.

Known Issues

• Twotone icons can't be styled properly
  • A solution for this is to track the fill property for every xml tag inside the svg. If the overall svg contains two distinct fill colors, the darker one would be overwritten to currentColor. The lighter color (or the only color if only one fill color is set) is the one which corresponds to the secondary tone, and could be set with a css variable or kept track of in the library code. This would permit users to manage the color of twotone icons properly.
• Explorer site not working on small screens
  • This issue is a simple task, it only requires making a dynamic header with tailwind.
• Code bloat due to generics in component
  • This is theoretically a simple fix, but would require heavier syntax for users. A macro could be made to alleviate this
    problem.

Unanswered Questions:

• What should be done about categories (sizes, types, ...)?

I feel like we have reached the point where the crate is mostly done, and we are only left with a few unanswered questions/design decisions. Here they are:

• Are we correctly handling html attributes? An alternative to passing common attributes such as class, style, width, etc. (what we are currently doing) would be to use the attr feature of leptos.
• Since this crate has become pretty stable in the recent months, should we try to match our version to leptos' version? (e.g., publishing version 0.7 once leptos v0.7 comes out)

As you have acknowledged, having so many icons causes rust-analyzer to lag. To fix this, you can gate each icon into its own feature flag. If you reach over the maximum features, you can group icons instead and do it that way.

I'm new to rust but it seems icon type is not exposed. My requirement is to store a list of icons in an array and use a loop to show all of them. But I couldn't get it working because the icondata_core::IconData type is not exposed from the lib. Is it possible to store a list of either leptos_icons::Icons or icondata_core::IconData? If so what would be the type of the array?

When attempting to reactively update an icon using a signal like:
<Icon icon=icon_signal class="h-6 w-6 text-gray-400"/>,
I encountered the warning: Signal or memo accessed outside a reactive tracking context (defined at /rustc/ad963232d9b987d66a6f8e6ec4141f672b8b9900/library/core/src/convert/mod.rs:716:9) on the line let icon: IconData = icon.get().into(); in lib.rs.

Wouldn't it be more appropriate to handle the signal inside the Icon component so that it'll react on change (for example, if modifying the icon from another component). This is what I had in mind:

    let icon_signal = move || icondata::IconData::from(icon.get());
    // handle rest of svg attr's
    ...

[email protected] that's compatible with [email protected] isn't published since the last change is Readme.md about a week ago.

Please, try cargo add [email protected] to confirm.

I sort of figured out the issue I was having with the icon macro earlier. Suppose I am importing from this library like so:

use leptos_icons::{icon, ChIcon, Icon};

I try to use an icon like this:

<Icon icon=icon!(ChIcon::ChMenuHamburger)/>

When I run cargo leptos build, I get this compiler error:

error: proc macro panicked
  --> src/ui/components/common/nav.rs:12:24
   |
12 |             <Icon icon=icon!(ChIcon::ChMenuHamburger)/>
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: message: Expected only one identifier, but received multiple tokens.

If I import like this:

use leptos_icons::{icon, ChIcon::ChMenuHamburger, Icon};

and use the icon like this:

<Icon icon=icon!(ChMenuHamburger)/>

I get a different compiler error along with an odd warning:

error[E0433]: failed to resolve: use of undeclared type `ChIcon`
  --> src/ui/components/common/nav.rs:12:24
   |
12 |             <Icon icon=icon!(ChMenuHamburger)/>
   |                        ^^^^^^^^^^^^^^^^^^^^^^ use of undeclared type `ChIcon`
   |
   = note: this error originates in the macro `icon` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this enum
   |
1  + use leptos_icons::ChIcon;
   |

warning: unused import: `ChIcon::ChMenuHamburger`
 --> src/ui/components/common/nav.rs:2:26
  |
2 | use leptos_icons::{icon, ChIcon::ChMenuHamburger, Icon};

Unused import? I'm using it right there!

I managed to get it to compile by importing like this:

use leptos_icons::{
  icon,
  ChIcon::{self, ChMenuHamburger},
  Icon,
};

and writing the component like this:

<Icon icon=icon!(ChMenuHamburger)/>

Oddly enough, I still get the unused import warning for ChMenuHamburger.

I doubt this is the way the library is supposed to work, and it will definitely trip up consumers. It certainly confused me.

I tried something like this for the icondata crate not long ago and was told that that crate was supposed to be framework agnostic. This seems like the more appropriate repo for that change.

I was having trouble getting the icon! macro to work. While that would solve the issues I'm having, I noticed that using Icon::From worked as well. If From is implemented on the icon types, it should allow consumers of the library to pass their directly to the icon component, making the icon! macro superfluous.

I'm willing to implement this change. @Carlosted Are the features generated programmatically for this crate like they are for the icondata crate?

https://icones.js.org is based on https://github.com/iconify/iconify / https://iconify.design

All popular icon sets, one framework.
Over 200,000 open source vector icons.

Universal icon framework. One syntax for FontAwesome, Material Design Icons, DashIcons, Feather Icons, EmojiOne, Noto Emoji and many other open source icon sets (over 150 icon sets and 200k icons). SVG framework, React, Vue and Svelte components!

Iconify is the most versatile icon framework.

• Unified icon framework that can be used with any icon library.
• Out of the box includes 150+ icon sets with more than 200,000 icons.
• Embed icons in HTML with SVG framework or components for front-end frameworks.
• Embed icons in designs with plug-ins for Figma, Sketch and Adobe XD.
• Add icon search to your applications with Iconify Icon Finder.

E.g. the Tamagui Takeout stack template uses these icons.
It would be nice to have them available in leptos.

I recently executed cargo update and noticed that leptos-icons no longer compiles due to modifications in the icondata dependency. Specifically, utilities like the icon! macro are malfunctioning since their imports have been deleted. There are also new cargo features and others have been removed. Is there ongoing work to address this?

From the next major release of simple-icons (v11, releasing on May 26, 2024), We will begin removing third-party extensions from our README list that are not up to date with at least the previous major release.
For example, when v11 is released, we will remove any extensions that don't support v10.0.0 or higher.

How do I keep my package up to date?

There are two methods that prove most popular among other maintainers. It is up to you which you implement.

Using @latest from a CDN

Projects that use the CDN version of the project (jsDelivr/unpkg) can keep up to date simply by changing the version number in their code to @latest. That way - you're always using the most up to date version of the icon package.

Running a weekly CRON

Many of our third party contributors make use of GitHub actions, and a weekly CRON job to query that the version number of the main package has changed, and then update and build their own package. A great example of this is the DrawIO package by mondeja. The main package is released consistently on a Sunday - so we recommend running your CRON job on a Monday or Tuesday.

When you've got your extension running one of the above methods, drop us a Pull Request to update your version number on the README.

If you're in need of any support in implementing one of the above - please feel free to start a discussion or ask us on Discord.

Awesome crate 🔥

I can't build leptos-icons on stable Rust and I don't see a stable feature to enable it.

Are you interested in adding a stable feature, which could be passed to the leptos so it builds on stable Rust?

I can submit a PR if you would like.

Please include more info in the readme about how to use the libs especially if there is a way to not include all the icons from icondata when compiling debug builds.

Maybe it will be easier to uniformly integrate multiple icon sets by using some icon set aggregator? I know that Iconify has a repository with all the icons as json files: https://github.com/iconify/icon-sets/tree/master/json.

leptos-icons, as the library is currently named, more or less clashes with https://crates.io/crates/leptos_icons. Publishing this crate under leptos-icons (I think that might be possible, as it uses a dash instead of an underscore, but I'm not 100% sure on that) might not be a good idea, as users will likely use the wrong library. Or we can't use the name in the first place.

I would suggest finding a different name for the library.

If a user of leptos-icons enables the "tracing" feature of Leptos in his own crate, the build will fail, as the #[component] macro used for all the icon-components cannot find the tracing crate inside leptos-icons. Adding the tracing dependency to leptos-icons, probably behind a similarly named feature should fix that error.

It seems that there is not generalized icon enum anymore. That makes it hard to "name" or ''reference'' a single but arbitrary icon.
For the lib itself and it's Icon component, taking anything convertable into icondata_core::IconData is fine, but if other libraries want to reference an arbitrary icon, this design forces them to use icondata_core::IconData as well, which currently provides no functionality, does not derive common traits and can not provide information about what icon that data actually represents. It is kind of unsuitable to be send around in code or over network or into storage. An enum would be more appropriate.
I would suggest, if it does not induce a large penalty to final (wasm) binary size, to re-add the old Icon enum. This could then derive

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord, Hash, Clone, Copy)]

and should probably also derive serde::Serialize and serde::Deserialize (hidden behind a serde feature flag) so that users can easily send around and store any chosen icon without introducing own wrapper types.
The Icon component can still take anything being Into<IconData>.

hi, when i enter to the link i can't see nothing, just a blank page

I'm trying to use classes with a signal or closure like this:

    let icon_class = move || {
        if disabled() {
            "h-5 w-5 stroke-slate-400"
        } else {
            "h-5 w-5 stroke-green-800 dark:stroke-green-600 group-hover:stroke-slate-600"
        }
    };

    view! {
        <button class=btn_class on:click=move |_| set_clicked(true) prop:disabled=disabled>
            <Show
                when=clicked
                fallback=move || {
                    view! {
                        <p class="text-sm pr-1 group-hover:text-slate-600">{label.clone()}</p>
                        <Icon icon=TbClipboardText class=Signal::derive(icon_class)/>
                    }
                }
            >

                <p class="text-sm pr-1">{label_copied.clone()}</p>
                <Icon icon=TbCheck class="h-5 w-5 group-hover:stroke-slate-600"/>
            </Show>
        </button>
    }

I tried removing the Signal::derive and I tried converting the return type of the closure from &str to String but nothing works.

Let's assume a component library provides a leptos component Foo, which may display an icon.
The library may give the user the option to choose the specific icon to show.

But: How does Foo incorporate/display an "arbitrary" icon. And how should the user specify the icon to use?

One could imagine something like this, where Foo just takes some arbitrary View and includes that in its output:

<Foo icon=move || view! {cx <BsFolder />}/>

But the user might not even create an Icon here... Could also be a benefit (easy prarmeterization of the icon), but most likely not what a library author inteded. The library auther would also have no control over the icon in this case.
The author can only accept an arbitrary nested view, as the user currently has no other means to specify an icon.

In this case, a selection of an icon by enum variant would be much more ergonomic and would allow any library authors to simply take an enum variant as a prop. (I followed this approach as well when doin some limited icon stuff in the Yew framework.)

<Foo icon=Icon::BsFolder/>

The problem lies in the fact that, right now, all icons are represented by individual leptos-components (functions) and no enum exists.

I think that an enum, defined as non_exhaustive , and with all it's variant feature-gated, is required for this library.

Two things are required:

• The enum itself: Probably a single one in the library root, containing a variant for each feature name of the library (feature name can be reused)
• A generalized Icon component which can take that enum as a prop and display the proper icon.

I'm unsure on how to implement the second and welcome any suggestions! :)

A simple solution would be to generate a huge match statement inside the Icon component, where each arm is feature-gated and displays one icon by reusing the icon-components which are already getting generated, forwarding all possible arguments.
The efficiency of such a match statement should be high. With the enum variants all having zero data, it should be a simple jump table at runtime.

In my own leptos projects I have been using enums for prop inputs in some cases. This minimizes the possible incorrect inputs, just like with normal Rust code.

I wonder if the same makes sense here, for example:

   mount_to_body(|cx| view! { cx,
        <div>
            <CheckCircleFill class="test" size=Size::Em(10) title="a11y title" color=Color::Red />
        </div>
    })

What do you think?