piemonkey
commented
5 months ago If the app is embedded in a different domain, the browser might refuse to load the referenced symbolset, so something like svgxuse needs to be used as a workaround.
In fact, while the svgxuse workaround does work if you're hosting the ember app that is embedded in another domain (for example in an iframe), as svgxuse is still able to request the symbolset. If the app is designed to be bundled within another project, then the symbolset is no longer available and this approach fails. This is the case for the embeddable-say-editor project which can now be installed through npm and in order to work requires overriding AuIcon with a custom version. This workaround only works for ember-appuniversum <=2.15.
abeforgit
Windvis
alternative to the symbolset setup [Released as experimental]
Read more
At the moment Appuniversum bundles a [list of icons](https://github.com/appuniversum/ember-appuniversum/tree/654711add804e8e2de2a5b23b22976690a9c4b90/public/icons) into a svg-symbols file which is also stored in the public folder and which is then referenced in `AuIcon` component. This works, but has some downsides: - no support for custom icons, which means icons need to be added here, even if they are very specific for a single project - All the icons are bundled, even if only a few are used by a project - If the app is embedded in a different domain, the browser might refuse to load the referenced symbolset, so something like [svgxuse](https://github.com/Keyamoon/svgxuse) needs to be used as a workaround. A potential solution for these issues is to use icon components, instead of the string based setup we have now. Each .svg file could be converted to a .gts file at build time, and imported like any other component. The benefits: - Since they're components, Embroidered apps will strip out the unused ones so only the used icons will be part of the build - No reference to a symbolset file, so no issues with cross-domain requests For this to work, each component that now accepts a string for the `@icon` argument, would also need to support a component (POC in #481 ). We would also need to refactor our internal usage of the `AuIcon` component, and pass the components instead of the string. TODO: - [x] Add support for passing components into the `@icon` arguments (#481) - [x] Add a script that generates icon components from the .svg files (#487) - [x] Use the icon components internally (#486) - [x] Release this work as an experimental feature, so apps can start experimenting with it (Released in [v3.4.0](https://github.com/appuniversum/ember-appuniversum/blob/master/CHANGELOG.md#v340-2024-03-25)) **Open questions:** - Do we want to deprecate the string based system? If we don't any usage of the symbolset will trigger the download resulting in all the icons being downloaded again) - Do we want to expose these components in Ember's global component namespace, or do we only expose the export paths and require that consumers import where needed? (In non-gjs/gts files this might be cumbersome, but I think we're at a point where using .gjs is in a good place)Webuniversum icon inconsistencies
Webuniversum has a lot of icons. Not all of them were added here, and we might also be using some of the legacy ones.
We should compare all the icons we bundle here with the Webuniversum list and document if it is a custom component, or a legacy one.
TODO:
Custom icons
If an icon is not part of the Webuniversum list, we should check were it is being used. If it isn't used, or if a Webuniversum equivalent with a different name exists, we should deprecate it (or otherwise override it).
Legacy icons
We should deprecate the legacy icons and suggest the new equivalent.
Sync all the icons
We should also add all the icons that Webuniversum currently has so they can easily be used without new PRs. Assuming we only support the new icons in the component setup this shouldn't have an impact.