bugfix/2092 resolve resource uris on server

[mhsdesign]

Resolves: #2092
Resolves: #3616

• BUGFIX: Extract resource resolving magic out of ResourceIcon
• BUGFIX: Move resource logic to server

[mhsdesign]

I decided against using a react context to pass the neos ui service redirect uri route along (/neos/ui-services/redirect-resource-uri) and instead its now hardcoded.

With Neos 9 we will establish service routes as part of the dom like so (see #3804)

 <link
   id="neos-ui-uri:/neos/xliff.json"
   href="https://mysite.example/neos/xliff.json?locale=de-DE"
   data-locale="de-DE"
   data-locale-plural-rules="one,other"
 >
...
 <link
   id="neos-ui-uri:/neos/redirect-resource-uri"
   href="https://mysite.example/neos/ui-services/redirect-resource-uri"
 >

to make it more dynamic.

But there is a catch. In local dev mode at least, it seems to take some time until the icons are visible on the first visit: (and somehow my browser didnt cache it after a reload :()

Bildschirmaufnahme.2024-07-09.um.12.15.40.mov

[Sebobo]

I think we shouldn't introduce additional requests to resolve icons for the default UI.
Rather we should use something like https://github.com/KrakenTyio/esbuild-svg-symbol-plugin to generate svg symbols for the stuff we need and reference them. This way they can be preloaded by the document with one request.
Or keep the SVG itself in React.

Is there a benefit besides resolving some issues with a few icons and the dummy fallback in the image editor?
3rd party icons and images are already resolved in the configuration or not?

[mhsdesign]

Option 1 of #2092 (comment) is currently not resolved by the server, but could be. On the otherhand resolving the resource in the server already via a node type preprocessor is not a good idea and will crash in CLI context (which basically forbids doing anything node type related once we use this functionality via cli)

see also neos/neos-development-collection#4888

soo as alternative solution approach i could imagine using indeed inline svgs (like for the neos ui logo) and move the resource:// replacement logic into the node type schema endpoint instead of a node type preprocessor, as we are in the web context at that time and know the correct host

[mhsdesign]

So i experimented a bit and tried out the file loader for the Neos logo and the custom icons for the node creation dialog.

The problem with the file loader is that we dont know the correct public base path.

For example if the svg is copied next to the javascripts we should be able to link it via

http://127.0.0.1:8081/_Resources/Static/Packages/Neos.Neos.Ui/Build/logo-AUKGDP6U.svg

buuut by default it will link to ./logo-AUKGDP6U.svg which leads to the icon not being found. Configuring the publicPath is also not really possible as we dont know if the files are placed in Neos.Neos.Ui Neos.Neos.Ui.Compiled or located in the cloud (the problem we are initially trying to solve)

Additionally having each svg separate as file is not the best option and we should check into the svg-sprite approach. Though im not sure if we wont face the same publicPath dilemma there as well?
Additionally with svg-sprite xlink:href cannot point to a different domain, wont that already be a problem for cloud hosted resources without proxy?

On the other-hand we dont need to optimise loading of 4 icons when font-awesome inlines thousands and completely bloats up our bundle:

So we could decide to fully inline these few icons into the build (either as data-url or as plain text) and for any real optimisations look into how we can make font-awesome awesome? (see https://docs.fontawesome.com/v5/web/advanced/svg-sprites)

[mhsdesign]

Seb agreed with my reasoning and well just include our 3 additional svgs in the bundle
See #3836