-
Notifications
You must be signed in to change notification settings - Fork 12.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot add custom icons in Angular due to typing #14199
Comments
It's possible that we could do something along the lines of adding an interface for a CustomIconDefinition or CustomIconLookup and then allowing the custom version to be used wherever the normal version can be used, however that seems like it might be adding unnecessary complexity since as far as I can tell that would have the same outcome as just changing IconPrefix and IconName to accept any string. Maybe IconPrefix could include an extra option "custom", which people could use, but you would still have to allow IconName to use any string. |
It has been brought to my attention that I use type assertions as a workaround (as below), although ideally one wouldn't have to do this.
|
I'm also having this issue when trying to add custom icons as per https://github.com/FortAwesome/Font-Awesome/wiki/Customize-Font-Awesome#with-webpack. Interestingly, that section has a @tagliala I see you marked this as 'waiting for feedback', but I don't see any questions or requests for feedback here. What feedback are you looking for? |
@Tschrock we are waiting for feedback from the community itself
I should have written instructions does not work for TypeScript Anyway, please giva a try to #14199 (comment) |
I once resolved the problem by adding "as any" when registering the icon. But now on Angular 11 witch suggests to enforce strict template type check it breaks again when using the Angular component. <fa-icon [icon]="['fac', 'my-icon']"></fa-icon>
IconPrefix should not enforce values if it the library is willing to allow custom icons. You could use this definition to provide hints but don't lock the user out : export type IconPrefix = "fas" | "fab" | "far" | "fal" | "fad" | string; |
I've recently come across this issue too. My current solution was to override the definitions in a shims file, shown below. It would however, be good to have a native solution to this problem.
declare module '@fortawesome/fontawesome-common-types' {
export interface IconLookup {
prefix: 'fas' | 'fab' | 'far' | 'fal' | 'fad' | 'fac';
iconName: string;
}
export interface IconDefinition extends IconLookup {
icon: [
number, // width
number, // height
string[], // ligatures
string, // unicode
string | string[] // svgPathData
];
}
}
import { IconDefinition } from "@fortawesome/fontawesome-common-types";
export const myIcon: IconDefinition = {
prefix: 'fac',
iconName: 'my-icon',
icon: [
444,
512,
[],
'e001',
'M432, ...'
]
}; |
Had the same issue, my workaround was for Angular 10
export const customIcons:IconDefinition[] = [
{
prefix: "fac" as IconPrefix,
iconName:"myName" as IconName,
icon:[
346, // viewBox width
268, // viewBox height
[], // ligatures
"e125", ...
}
] And in templates :
to avoid
|
Facing the same issue with ivy language service. I am using 0.8.2v of the library and Angular 11. |
try some thing like this,
It works for me! |
I'm trying to add custom icons to the library with code like this:
If I can work around the compilation errors it does actually work but it throws a bunch of type errors like this:
If I
import { IconDefinition } from "@fortawesome/fontawesome-svg-core"
and then create my icon object using that type then I still get similar errors:
Looking at the common types in https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome-common-types/index.d.ts
I see that IconPrefix and IconName are defined as a fixed set of string values, which means that you can only override existing icons and cannot add new ones.
If I change the prefix and name in my code to strings in the allowed values list the errors all go away.
Could we potentially come up with an alternative typing that allows the use of custom icon prefixes and names?
The text was updated successfully, but these errors were encountered: