I’d like to propose moving the model-tree icons in the HTML Architect from the backend to the frontend. Right now the server ships SVG files and serves them over an /Icons route, and each tree node carries an iconUrl — but the backend really shouldn’t care what a folder icon looks like.
The idea:
The backend just returns a small TreeNodeIcon enum (Generic / Folder) instead of an iconUrl.
The frontend maps that enum to icons from react-icons/vsc, so the look stays consistent with the rest of the UI.
No more SVG files to deploy, no static-file route, no Vite proxy — fewer moving parts overall.
It’s also easy to add more icons for additional item types in the future — just a new enum value and a matching case on the frontend.
I already have a PR ready for this if there’s interest — happy to open it.
If doing this will be the users still able to see all existing icons in the Architect and use them for their own menu items? So nothing would change from the user perspective we would just optimise data routes?
From what I can see, the current HTML Architect works with only two icons served from the static asset folder — a folder icon for groups/providers and a generic fallback icon for everything else. Notably, the iconName/iconIndex fields were sent from the backend but never rendered by the frontend — the “New” context menu only ever showed text labels.
Just to make sure I understand: are you referring to the built-in per-type icons we have in the desktop Architect (the ones from SchemaItemDescription), or to some way for users to assign their own custom, per-project icons to menu items? The former was never displayed in the HTML Architect, and I haven’t seen a requirement for the latter — is there somewhere I could read more about it?
My solution aims to keep responsibilities where they belong (separation of concerns). But if we do want to serve icons that way, I’d be happy to adapt it accordingly.
@vikter Anyway, my edit leaves all the icons in HTML Architect as they are. Only in the Tree component I change the folder icon and the generic icon to icons from the icon pack we are using, so it will be visually consistent.
These two icons were served from BE. My opinion is that this is an legacy approach, because we are working with the FE library of optimized icons now.
I was talking about this. If these images/icons will remain available in the Architect for the end-users, then any “technical” change is not a problem…
These are not model-tree icons that represent different functional types. These are images and their representation that can be added to the model and used for menu items and action buttons.
My cleanup is still relevant here, since I’m dealing with actual system icons that aren’t subject to any customisation. That said, in light of this new information I’m happy to broaden the scope.
These user-defined icons for the HTML Architect will certainly be served from its backend, and for that we could likely reuse part of what I’d flagged for removal — it was dead code that doesn’t really belong in the repository, but I think we can repurpose a portion of it precisely for the icons you’re describing.
