Don’t kill me Seb that this is not in a
w
Don’t kill me Seb that this is not in a thread
n
Now a thread... 🙂 no killing
w
😂
n
Yes, so I assume the Backend code still has the code. So its 'just' missing the link to the front-end. At the end of the day it would generate such Icon Set extension manifest and hand it to the front-end. Main point there is that the front-end does not have the Icon Set Extension Type just jet.
w
This is how it works currently
So in theory a new management C# api should return the merged collection
k
I have done it in uSync... https://github.com/KevinJump/uSync/tree/v14/dev/uSync.Backoffice.Management.Client/assets/src/icons but its a little clunky (hence its not in the blog posts).
n
Yes, something like that.. Or just include it as part of the Server Extensions.. as we already ask the server for all the umbraco-package.json files. One bad thing about just dropping files on the server is that it just has data based on the file name. The future Icon Set Extension Type, would accept a JSON which points to the files of that set. This would make room for making the Icons Accessbile one day. By appending more data, like search keywords and Accessible Name. 🙂
w
But maybe a conscious choice from @Bjarke Berg and gang not to do that way as it’s extending the UI and should be done with your new approach of extending the UI stuff with JS instead 🤷
k
i've found it then has to be wrapped which seemed wrong ?
Copy code
html
<usync-icon-registry>
  <uui-icon name="usync-logo"></uui-icon>
</usync-icon-registry>
n
Well, yes and no... In current backoffice. but in New Backoffice... in the future of New Backoffice, once the Icon Set Extension Type is here... currently its just in my head. Then that is not needed.. just a Extension Manifest pointing t a JSON File pointing to the SVGs.
w
Yep sounds ideal and the idea of having more than one keyword to search/filter on would be fab !!
House, home, building all for same thing
n
yes, I assume you all thought you knew the name of the icon... but had to go through all synonyms to find it..
w
Haha amount of times I end up giving up filtering and just scroll until I see what I want 😂
n
( I do think technically it would then also be possible to overwrite the Umbraco Icons... but then again please dont.. )
w
Same could be said for the c# side of things. You can swap things out and then wonder why it’s all broke because you removed everything from a collection
So hopefully people won’t replace the icons you ship
And just add to the existing collection
Anyway… is this something trivial as a community pr to work on to learn the concepts of back office extension types ?! Or probably not?!
n
Nha, maybe.. 🙂 but trivial to append some new icons from the Lucide set.. Improving the set of icons that are available by default.. as a PR to the New Backoffice
w
Yeh I can do that for sure
Any recommended way to ship an icon with a package or best just to reference the icons that are defined
n
I think its good for packages to come with new icons.
Also another thing to get started on would be to transfer the search keywords from this package into the Icon Set Json. I got verbal permission from Jason Elkin & Joe Glombek. https://github.com/glombek/umbicosaurus
w
Just as most packages tend to ship with some custom icons
Where does this json live in the repo?
n
src/shared/icon-registry/icon-dictionary.json
that gets read by a Node script that you can run via
generate:icons
which is located at
./devops/icons/index.js
w
This UI project or the new backoffice?!
n
Currently in the front-end its usage is hardcoded at
src/packages/core/modal/common/icon-picker/icon-picker-modal.element.ts
that will be changed into using the Extension Type we already talked about a few times.
New Backoffice
w
Some in that json has _file and __file
n
thats just a way to make the entry invalid.. aka outcommented..
w
Ah gotchya
Didn’t like those one and removed them?!
n
That makes it fallback to the icon from the Current Backoffice. Yeah, it was hard to find one that could replace it. Like it would eventually visually represent something else.
w
So for these synonyms from Joe’s package. New property that is a string array?
synonyms: [“house”, “home”, “building”] etc?
n
yeah, that seems good 🙂 I think ones tht property is present, then we might only use those for the search terms used.. so the name would not be used for filtering in that case. As that enables the name to become more specific to the Icon than what it represents... Like name: "Umbraco Deploy Transfer", but that would not like either Umbraco or Deploy to be a search term. So maybe the property name 'keywords' would be better?
(Also there is today icons named something that it does not represent.. so in that way we can keep the name but get rid of it as a search term and still be backwards compatbile)
w
Yep keywords. It’s a bit of a churn of a PR but happy to help out with the full stuff so you clever guys & gals can focus on other stuff for the rewrite.
p
@User May I suggest “all” instead of "guys"? We use gender inclusive language in this Discord. 😀
w
I put and gals probot 😂
Silly robot 🤖
n
Sound good, thanks. Otherwise thats more down the road of details. So I may think for a few days and come up with even more central important things to test & improve if you like 🙂
w
Yep happy to help out as community for the more trivial stuff to help out the backlog. But for now I’ll start out with this and then can move onto the next thing you give us 🙂