Closed mvaibhav77 closed 8 months ago
Thanks. I thought the search screen was one of the causes of the confusion. Therefore, I changed the name of the icon set to be listed along with the name of the icon set.
Perhaps there is another solution that does not break compatibility.
@kamijin-fanta we can also add different sections in the search result itself, like if we search 'user', the search result should show icons grouped by their module name like font awesome, hero icons, etc.
Thanks. I thought the search screen was one of the causes of the confusion. Therefore, I changed the name of the icon set to be listed along with the name of the icon set.
Perhaps there is another solution that does not break compatibility.
![]()
This works too.
Describe
Issue
An issue has arisen due to identical icon names within different modules – Font Awesome and Hero Icons. These modules possess varying versions, each containing icons of the same name. Additionally, users may import an icon from an incompatible version. For instance, the "HiBookmark" icon exists in both Hero Icon V1 and V2, leading to conflicts.
Solution
To address this issue, I propose three potential solutions:
1. Rename Icons in Later Versions:
Consider renaming icons in the newer version module to include version identifiers. For instance, for Font Awesome V6, icons like "Fa500Px" could be renamed as "Fa500pxV6". This distinct naming convention would help differentiate between icons of different versions.
2. Removal of Same Name Icons:
Remove identical icons from the older version module, effectively eliminating conflicts. For example, the "Fa500Px" icon could be removed from react-icons/fa, making it accessible only through react-icons/fa6.
3. Enhanced Documentation with Import Indications:
Supplement the above approaches by enhancing the documentation. When viewing icons, provide clear indications of their respective modules. Additionally, modify the copying behavior to prompt users about the module affiliation when copying an icon name. This approach offers a comprehensive solution, even if the previous methods are not implemented.
These solutions collectively aim to mitigate the issue and ensure a seamless user experience.
I would like to work on this myself. Can this issue be assigned to me @kamijin-fanta?
Minimal sample repository URL
No response
Additional context
Illustrative Example of the Issue
Below is a sample code snippet demonstrating the issue:
In this code, both "HiBookmark" icons are imported, but with different namespaces ("HiBookmark" and "HiBookmarkV6") to prevent ambiguity. One icon belongs to Hero Icons V1, while the other originates from Hero Icons V2. The core issue arises during icon selection within the documentation. Presently, when searching for an icon, the documentation displays its name and visual representation. However, it lacks information about the source module. Enhancing the documentation to include module source information can facilitate icon identification and seamless import.
Please note that the namespaces used here are for illustrative purposes to differentiate between icons with identical names. It is a good way we can more differentiate between icons when writing our code. We can implement it by changing the name of icons of newer version with something like "IconNameV2".