Discussion: API to register icons

I think we should discuss how API for the icon registration in the library should look like. If we should have it at all.

Option 1: reuse fontawesome.library

This means that users will have to do somewhere (where?) in their code:

import fontawesome from '@fortawesome/fontawesome'
import { faUser } from '@fortawesome/fontawesome-free-solid'

fontawesome.add(faUser);

Than they can just specify icon name in the template:

<fa-icon icon="fas-user"></fa-icon>

• pro: No extra implementation in the angular-fontawesome library
• con: Component using icons does not declare its dependencies clearly
• con: Requires use of low level API
• con: Not clear where to put this code

Option 2: provide helper method on the FontAwesomeModule

We’ll provide a helper method, which will register icons passed in as parameters in the library. Here is a small example how it can look like:

import { faUser } from '@fortawesome/fontawesome-free-solid'

@NgModule({
  imports: [
    FontAwesomeModule.withIcons(faUser),
  ]
})
class AppModule {}

Than icon can be used in the templates by just providing its name like in option 1:

<fa-icon icon="fas-user"></fa-icon>

• pro: Obvious place for registering icons
• pro: Implementation is quite simple
• con: Component using icons does not declare its dependencies clearly (better than option 1, but still)

Option 3: no registration at all

Require developer to import icon and pass it into template. In this case developer will have to import every icon they want to use in the component explicitly. Here is an example:

import { faUser } from '@fortawesome/fontawesome-free-solid'

@Component({
  selector: 'my-app',
  template: '<fa-icon [icon]="faUser"></fa-icon>',
})
export class AppComponent {
  faUser = faUser;
}

• pro: Explicit dependency declaration for a component
• pro Easy to find all icon usages or unused icons with TypeScript tooling (find usages, noUnusedVariables in TsConfig)
• con: Requires extra field in component for every icon, quite verbose

Let me know what do you think?

[devoto13]

I’ve read the React component README and I think that it is very similar to what we should do for Angular. Couple of notes:

Explicit

This is same as option 3 in the original post.

Library

This is option 1 or option 2 from the original post. Just want to note here that having global state (library) is not very common in Angular world, so that’s why I offered option 2 at the first place. To host icons library inside NgModule and use this library when rendering icon instead of global one.

But option 2 can be just wrapper of the library.add method and add icons to the global library. The benefit is that the place where developers add icons to the library is clearly defined, so they don’t need to guess where to put this code.

As for the concern @Shinigami92 raised about being messy with many icons. One of the solutions is to have a separate file to collect all icons and then add them. Something like this maybe:

// icons.ts
export { faUser } from '@fortawesome/fontawesome-free-solid'
export { faClone } from '@fortawesome/fontawesome-free-solid'
export { faCopy } from '@fortawesome/fontawesome-free-solid'
export * from '@fortawesome/fontawesome-free-brands'

// module.ts
import * as icons from './icons'

@NgModule({
  imports: [
    FontAwesomeModule.withIcons(icons),
  ]
})
class AppModule {}

External

Embedding Angular is not supported now, but some people do it and it will probably be supported at some point. IMO this is less important use case specifically for Angular.

[robmadole]

Wanted to pop in here and mention that the “encapsulation” of Option 3 (and 2 as well) will provide better long-term scaling as projects and teams grow. One of the issues that has always bothered me about the fontawesome.library is that it creates a dependency between the component and the thing that sets up the library. This can create an opportunity for sneaky things to break (what if someone accidentally deletes some icons in a particularly tricky git merge?)

So while the library provides convenience we need to realize that the convenience will come at a price. I personally have worked on enough projects that the temporary pain of being explicit always out-weighs the chance of things getting messy and error-prone in the future.