Add support for object output

[NetanelBasal]

Add support for object output

[NetanelBasal]

In real life, most of the applications use a library where you register the icons and use them in the component. The registry expects an object where the key is the icon name, and the value is the SVG content. Let's take my library as an example:

import { SvgIconsModule, fromSvgProps } from '@ngneat/icons';

import * as icons from '../assets/svg/my-icons.model';

@NgModule({
  imports: [
    SvgIconsModule.forRoot({
      icons: fromSvgProps(icons)
    })
  ],
  bootstrap: [AppComponent]
})
export class AppModule {}

And now we can use the icons:

<svg-icon key="settings"></svg-icon>
<svg-icon key="home"></svg-icon>

In these cases, there is no benefit of using constants because we need an object. To support your library, I made the fromSvgProps util:

export function fromSvgProps(propsMap: { [key: string]: { name: string; data: string } }) {
  const map = {};

  for (const { name, data } of Object.values(icons)) {
    map[name] = data;
  }

  return map;
}

We can change the API to something like:

import { location, settings } from '...';

SvgIconsModule.forRoot({
  icons: [location, settings]
})

But imagine a big application with hundreds of icons. You'll need to maintain it, and your file will be huge.

[kreuzerk]

I will start to work on this soon - hope that I can find time and deliver it asap.

[NetanelBasal]

Great! Thanks. In the meantime, when I'll publish it next week, I will instruct to use the fromSvgProps helper function.

[kreuzerk]

I have implemented a first version that is now able to convert icon to object, constants and files. I just want to quickly check if my current implementation meets your requirement and ensure that I understood you correctly.

So if we would convert a folder with the following icons:

• expressionLess.svg
• full.svg
• laughing.svg

we would end up with the following file. ``ìcon.ts```

export const awesomeIcons = {
  expressionLess:'<svg xmlns="ht....',
  full: '<svg xmlns= ....',
  laughing: '<svg xmlns="http://www....'
};

When converting to an object I thought to give the consumer the following options:

	type	default	output the version number
fileName	stirng	my-icons	file name of the generated file
delimiter	CAMEL, KEBAP, SNAKE	SNAKE	delimiter which is used to generate the types and name properties
svgoConfig	string or config object	check help command - to large to display	a path to your svgoConfiguration JSON file or an inline configuration object
srcFiles	string	"/*.svg"	input files matching the given filename pattern
outputDirectory	string	"./dist"	name of the output directory
objectName	string	"icons"	name of the exported constant

Does this meet your requirements?

[NetanelBasal]

Yes, that's great. I'd also add an option to export it as default.

export default { ... }

Maybe check if objectName is default.

[NetanelBasal]

I also think the default delimiter should be camelCase. This is the standard.

[NetanelBasal]

I added in the README a recommended flow with your library.

[kreuzerk]

Hi @NetanelBasal

Thx a lot. Glad to hear that you like the library and that you want to include it in an article. Yes, we could add this feature. But I am not sure if providing the icons as an object has benefits.

I think that delivering the icons as an object makes them not tree shakable. Currently, we deliver the icons either as singleconsts so that they are tree shakable or even as single files, so that they are tree shakable and can additionally be split to lazy loaded feature modules.

But maybe there's a good reason to do so. Theoretically we could provide all three approaches, object, const and single file. What do you see as benefit of having them as object props instead of individual consts?

[NetanelBasal]

If you find it unsuitable for your library, let me know, and I'll create a dedicated library for this :)

[kreuzerk]

No, after your explanation I think it makes sense - with this, we could support all scenarios - object, const and multiple files.

[NetanelBasal]

Thanks for the quick collaboration! I'll update my library.

[kreuzerk]

Awesome, let me know if everything worked

[NetanelBasal]

Works great.

[kreuzerk]

Epic! Glad to hear - let me know once your blog post is out. If you want we can also link to it from our README.

[kreuzerk]

Awesome thx.