Third party icon support in 24.2 and beyond

In Vaadin 24.2, some new functionality was added for custom icon support. We were just in the middle of adding a custom iconset to our application using the old method (embedding the SVG sprite in a JS file and registering it there, like in vaadin-iconset.js). However the newly updated documentation doesn’t mention this approach and recommends using SvgIcon in Java which points directly to the SVG sprite in plain SVG format.

Moving to SvgIcon causes some complications because it’s not a subclass of the “old” Icon, which means our equivalent to the VaadinIcon enum can’t implement IconFactory either. That makes it quite painful to switch over to the new method.

Are there plans to bring those two different approaches in line with each other? For now, the old approach seems much nicer to use, but if there are plans to move away from that we might as well go through the effort of moving towards changing everything to SvgIcon.

All share the same if that helps.

So if you update your IconFactory to return this, there should ne no problem

IconFactory is an interface in that same package, and it returns Icon, not AbstractIcon<?>. VaadinIcon implements this factory. So yes it’s possible to work around this issue, but it’s still a bit messy. It means duplicating an interface that Vaadin provides just to fix the return type, and we still have to change all references from Icon to AbstractIcon<?> to be compatible with both.

So that’s why I’m posing the question in the last paragraph: are there plans to continue working on this, and if so, in what direction will that evolve?

Let’s be honest: I don’t think that the IconFactory was considered while implementing the new icons, because it could have causes breaking changes for people, so changing that signature wasn’t easy. Personally I would suggest to ditch that interface and use your own - I find the interface rather useless because it’s noway used inside Vaadin except the enums for Lumo and Vaadin Icons.

But nevertheless: the best way would probably to ask your question / comment / enhancement request in the flow repo I’ve linked above so that the team can take a look at it :slightly_smiling_face:

Indeed, the Flow API was built like that partially to avoid breaking changes and also because we felt that adding all these new features to the old classes would have become a bit confusing and we couldn’t figure out a good API for it.

The Icons docs does provide an example of how to create a convenience enum for custom icon collections: