Way to calculate / get icon hash by their name.

[Thomascogez]

Hello, we recently migrate our applications to use your new package. But since the today update that introduce a hash in the name of each icons we got some problem. Since, we are using StreamlineIcons since a while, we have in our database some entries that contain icons name with the old format.

My question is: Can we get / How to calculate the hash of an icon like that we could be easily convert to the new icon format. Thanks in advance

[cbrwizard]

Hey, this was introduced because some icons have the same names across categories and families https://github.com/webalys-hq/streamlinehq-npm/issues/6. Basically the way it is right now is that a part of icons' ids are entered after their names. The ids have been randomly generated years ago and right now are taken from our db.

Would exposing an endpoint which accepts an icon old name and returns a new one (with appended id) help? Or perhaps we can publish a csv file with all images and their updated paths listed? If you have any other suggestions we'll be glad to hear them too.

[Thomascogez]

Thanks for your quick answer 🙂 , a CSV would be awesome !

[cbrwizard]

Which format would be the most useful to you? Would just listing all icons import paths (eg check-circle-1-jUA7gT) be enough or do you need any other info like an icon name (eg CheckCircle1) or maybe also icon family + icon category (if it exists) + icon subcategory (if it exists)?

[Thomascogez]

I was thinking about something like this	iconFamilly (eg: bold, regular)	iconName(eg CheckCircle1)	iconNameWithHash(eg check-circle-1-jUA7gT)

Thanks in advance

[Thomascogez]

Hey @cbrwizard any update ?

[cbrwizard]

Hey, we're considering moving to a previous structure instead: family/category/subcategory/iconName. This will mean that the users of the old wrapper packages won't have to change imports much. This will also resolve the naming conflict issue and there won't be a need of an icon hash.

We're working on another important feature right now, but I'm planning to switch back to this right afterwards.

[Thomascogez]

@cbrwizard , ok i'm waiting for the next update 👌

[Thomascogez]

@cbrwizard any update 🤷‍♂️ ?

[cbrwizard]

Not yet unfortunately. Our small team is working hard on delivering an important big feature. We'll switch back to npm right after it's done with the goal to fix all related issues.

[pinuts-LucasKristandt]

Thats such a crucial structure change.. We just rebuilt our entire cms integration for our editors because of the last structure change. Anyway the old structure was much easier to use for this usecase.

[nicholasschulz]

@cbrwizard I have to express, that we are in a very unpleasant situation due to the first announced changes combined with your last announcement. As Lucas described, we had to rebuild our entire cms integration. Furthermore our editorial team has to manually change all used icons on our website due to these changes, which both costs us a lot of money. Based on the new announcement, I am afraid that we have to re-do this whole process soon again. As the first announced changes will be active next week, we also have no chance to wait for your new plans. This is a very dissatisfied situation, which why it would be very helpful, if you could give a statement on that as soon as possible. Thanks.

[cbrwizard]

I'm honestly sad to hear that you had this issue because of our mistake in architecture. I wish that didn't happen.

The upcoming change won't be a breaking one. We will maintain the old structure so you will not be forced to move to a new one. As an alternative you can always import the svg files from the app and use them as plain images without the npm package.

[nicholasschulz]

Thanks for your words. So the big change beginning on 1st of June will no longer be happening and we can remain, what we have so far? Am I understanding it right?

[cbrwizard]

Let me be more clear:

• On 1st June we're planning to get rid of old react/angular/vue packages (so called wrapper packages) which exist in other repos such as https://github.com/webalys-hq/streamline-wrapper-react. We might postpone their removal for a couple of months though since the release of this package didn't go smoothly.
• In the following week(s) we will release a new major (3.0) version of this package (streamlinehq), where we will fix all outstanding issues and where we're planning to move back to wrapper-style import paths ${family}/${category}/${subcategory}/${icon}. We will keep maintaining the current 2.X version of the package in the foreseeable future. Package users will be encouraged to upgrade to 3.0, but they can do that on their own pace.

If there is anything else I can help you with (besides fixing the thing obviously haha) please reply.

[nicholasschulz]

thanks for the clarification. This means for us, we would stick to our integration for now and wait for v3.0 - based on the assumption you really postpone the removal and not change it on 1st of June - correct?

Cheers!

[cbrwizard]

Yes, let's postpone the removal of the wrapper packages by one month - until 1st July.

[cbrwizard]

We have recently recreated all assets and released a new NPM 3.0.1 version https://github.com/webalys-hq/streamlinehq-npm/releases/tag/3.0.1, please install it, fetch newest images and check if it helps you. Now images use the predictable family/category/subcategory paths