[Icons] allow configuring multiple local directories and optionally prefixing them

[kbond]

Q	A
Bug fix?	yes
New feature?	yes
Issues	n/a
License	MIT

Configure multiple paths:

ux_icons:
    icon_dir:
        - %kernel.project_dir%/assets/icons
        - %kernel.project_dir%/vendor/your-vendor/your-bundle/assets/icons

Additionally, you can suffix the path with @<alias> to add a prefix for icons in this directory:

ux_icons:
    icon_dir:
        # ...
        - %kernel.project_dir%/vendor/fortawesome/font-awesome/svgs@fa

Now you can render icons in this directory by prefixing the name with fa::

{{ ux_icon('fa:solid:adjust', {class: 'w-4 h-4'}) }} <!-- renders "vendor/fortawesome/font-awesome/svgs/solid/adjust.svg" -->

[smnandre]

I need something similar for the rendering options... in the end we maybe will need to merge the syntax into something a bit more complex, lire the transports, or the doctrine connections.

I guess thoses are "read-only" ? (as we won't be able to write in "vendors" with the import command)

[kbond]

I need something similar for the rendering options... in the end we maybe will need to merge the syntax into something a bit more complex, lire the transports, or the doctrine connections.

Something like?

ux_icons:
  icon_dir:
    - path: some/path
      prefix: fa
      readonly: true
      more: ...

I guess thoses are "read-only" ?

All but the first one, yeah. We could make configurable as shown above.

[yceruto]

ux_icons:
    paths:
        vendor/fortawesome/font-awesome/svgs: fa

? ... then normalize to path, prefix?

[yceruto]

Also, it seems the concept is pretty close to Twig namespaces. It could be good if we reuse same concept that we already know, so "prefix" could be named "namespace" and the usage could ux_icon('@fa/solid/adjust.svg'), it's a path to a resource in the end, right? Less new magic/convention, more easy to understand.

[smnandre]

ux_icons:
    paths:
        vendor/fortawesome/font-awesome/svgs: fa

I'd use the "prefix" as key, like a namespace. As it's the only thing we need to garantee the unicity.

So maybe

    dfgdfsdfd:    # word i don't have; set ? packs ? groups ? ns ? 
        bi:
            path: assets/bootstrap
       ld: 
           alias: lucide
      bi-reg:
            dir: vendor/fortawesome/font-awesome/svgs:

Do you agree to make it the "primary key" ?

[kbond]

Yeah, prefixing with a key seems best - this will allow choosing the path to import into when using the import command. And @yceruto, namespacing is an interesting idea. Maybe something like:

ux_icons:
  paths:
    default: some/path

    fa:
        path: vendor/some/path
        readonly: true
        namespace: fa

About the : separator. Twig switched from : to / eventually, I wonder if we should do the same here initially (have no concept of :). Like @yceruto says, keep to twig's conventions.

[smnandre]

I'd say...

• prefix/key: no "directory" allowed (no ":", no "/")
• path: free as a french mobile phone carrier

Regarding "name/identifier":

• HTML syntax uses the ":" notation, i'd feel maybe more logic to keep it... but if you want to use "/" i'm not gonna fight for this :))
• Twig component (in component function) names: i'll check, but i think we have 0 constraints there, so no hot take there either.

[smnandre]

How can we move on this ? What do you need @kbond ? Or can maybe start in parralel the attributes configuration per directory and we see later how to merge ?

[kbond]

prefix/key: no "directory" allowed (no ":", no "/")

I think we need to allow a directory even when a prefix is used. For instance, assets/icons/heroicons: hero could have hero:24:outline:user/hero:24:solid:user