feature: safelist

[productdevbook]

example

safelists: ['uil:github']

please with api used, These must have already been added to the system.

[atinux]

Not sure to understand the purpose of it

[madebyfabian]

Maybe he means, that by having the chance to define a fixed set of icons (or a fixed set of icon-providers) in the config, the attempt to use any others will fail. This could be useful for when you want to maintain consistency.

I am currently implementing this by creating a seperate UIIcon.vue component which implements the <Icon> from this package.

<template>
  <Icon :name="props.name" :size="`${props.size}rem`" />
</template>

<script setup lang="ts">
  type RemixIconOnly = `ri:${string}` // either limit by set
  type RemixIconAllowed = 'ri:icon-1' | 'ri:icon-2' | 'ri:icon-3' // or by specific names

  const props = withDefaults(
    defineProps<{
      size: 1.5 | 3
      name: RemixIconAllowed
    }>(),
    {
      size: 1.5,
    }
  )
</script>

When now using any other icon names, you get typescript hints so you know that you either did a typo or attempted to use an that is not allowed. Type '"fxemoji:carouselhorse"' is not assignable to type 'RemixIconAllowed'. Did you mean '"ri:icon-1"'?

<template>
  <UIIcon name="fxemoji:carouselhorse" :size="1.5" />
</template>

[productdevbook]

What I mean is that the event icon names come from a database and are dynamically written to the component name.

It would be great if a safelist is created and icons are saved in memory during this build.

[atinux]

I love your idea of the UIcon @madebyfabian

You could also directly have a RemixIcon directly right?

To answer you @productdevbook, I see what you mean, but in that case, would you want to list all the icons allowed? Only lists? Using strings or regex? What would be the usage?

[madebyfabian]

Yes in this case the name RemixIcon could work. But the goal is basically to have a defined set of icons I could laters swap out. Should I create a seperate feature request for this? I think the issue by @productdevbook does not directly have something to do with it.

[atinux]

I think documenting how easy it is to create a wrapper component around <Icon> is even better than adding complexity into the module.