The FontAwesomeTestingModule is now configurable via a `forRoot` method.
The configuration object passed to it configures how the mock icon library
should behave when adding icons to it: ignore them, warn about them or throw
an error.
Fix#440https://github.com/FortAwesome/angular-fontawesome/issues/440
With this change `angular-fontawesome` exposes more permissive variants of some types (`IconPrefix`, `IconName`, `IconLookup`, `IconDefinition` and `IconPack`) from the `fontawesome-svg-core`. These new types allow arbitrary string values as icon name and icon prefix while maintaining auto-completion for the core Font Awesome icons.
Firstly, this makes it possible to define and use custom icons without any casts, thus implementing part of the #172 and addressing part of the #423 (Kit packages with custom icons). The documentation for custom icons is coming later in a separate PR.
Secondly, this makes `angular-fontawesome` resilient to multiple instance of `fontawesome-common-types` packages, thus helps with issues like #125.
The drawback of this change is that if a user makes a typo in a core icon name or an icon prefix it will no longer produce a compile-time error, but will throw a runtime error instead. However, this trade-off seems to be overall the best option. Considerations:
1. To keep type safety while supporting custom icons, we'll need to somehow extend the mentioned icon types. It was investigated in the https://github.com/FortAwesome/angular-fontawesome/issues/172#issuecomment-620812343. The conclusion is that it requires very convoluted code to be added to the project and therefore is undesired.
2. For the explicit reference approach, the type safety/completion is not really needed as icon definitions are imported as runtime symbols and importing a symbol which does not exist will always result in complication error.
3. For the icon library approach, the type safety isn't perfect either. While it will catch cases where one specifies a completely incorrect icon name, it does not catch all problems. Icons are added to the library at runtime and if an icon name is correct, but the icon was not added to the library it will still result in a runtime error.
Normally people should not add icons or packs outside of the
`AppModule`/`AppComponent` constructor, so this should only throw in
case of an error and help to detect a mistake (e.g. user imported
`FontAwesomeTestingModule`, but attempts to configure the regular
`FaIconLibrary` and is surprised that icons are not rendered properly).
Even if the above assumption turns out to be wrong it will be easier to
remove this error, then add it after the release (as it will be a
breaking change).
Because path was in the array, icon was erroneously assumed to be a
duotone icon and error was reported when component was trying to render
a second path (i.e. missing second element of the array).
Igor Lins e Silva
Yaroslav Admin
bleistift2
Damien Retzinger