-
-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bugfix/2092 resolve resource uris on server #3695
Conversation
16df4da
to
aea8e7c
Compare
I decided against using a react context to pass the neos ui service redirect uri route along ( 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 |
I think we shouldn't introduce additional requests to resolve icons for the default UI. Is there a benefit besides resolving some issues with a few icons and the dummy fallback in the image editor? |
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 |
So i experimented a bit and tried out the 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
buuut by default it will link to 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 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) |
Seb agreed with my reasoning and well just include our 3 additional svgs in the bundle |
Resolves: #2092
Resolves: #3616
ResourceIcon