【问题标题】:Sharing custom Angular formatting functions outside of template在模板之外共享自定义 Angular 格式化函数
【发布时间】:2018-07-23 13:59:27
【问题描述】:

如果在模板之外需要自定义 Angular 格式化/管道函数,那么 Angular 共享该函数的方式是什么?通过静态导出/导入还是通过InjectionToken

选项 1:静态导出/导入

export myFormatter(value: string): string {
  return ...
}

在服务中使用:

import { myFormatter } from 'my-formatter';

export class SomeService {
  ...
  const formattedValue = myFormatter(value);
  ... 
}

选项 2:InjectionToken

export const MY_FORMATTER = new InjectionToken('My Formatter', {
  providedIn: 'root',
  factory: () => (value: string) => { return ... }),
});

在服务中使用:

import { MY_FORMATTER } from 'my-formatter';

export class SomeService {
  ...
  const myFormatter = this.injector.get(MY_FORMATTER);
  const formattedValue = myFormatter(value);
  ... 
}

我最初的直觉告诉我使用 InjectionToken 来利用 Angular 的依赖注入系统。另一方面,Angular exposes their formatting functions as of Angular 6 without the use of InjectionTokens。这就提出了一个问题,为什么 Angular 不将 DI 用于自己的格式化函数,我们应该如何共享这些函数?

【问题讨论】:

    标签: angular angular-pipe


    【解决方案1】:

    不要依赖 Angular,因为它会使用复杂的函数在不同的特性之间共享您的代码。

    相反,考虑依赖 Typescript,通过制作一个可导出的函数:

    export function myFormatter(value: string): string {
      return ...
    }
    

    在你的功能中:

    import { myFormatter } from 'path/to/file';
    
    export class MyComponent {
      myFormatter = myFormatter;
    }
    

    你也可以从中创建一个超类:

    export class FormatterUtils {
      myFormatter(value: string): string {
        return ...
      }
    }
    

    在你的功能中

    import { FormatterUtils } from 'path/to/file';
    
    export class MyComponent extends FormatterUtils {
      constructor() { super(); }
    }
    

    【讨论】:

    • 您能否详细说明一下为什么您认为在这种情况下可以纯粹使用 TypeScript 进行回复?我同意 DI 整体上更复杂,但有 reasons why we use DI。为什么在这种情况下可以放弃 DI?针对您的第二个建议,我个人不同意在这种情况下使用超类,因为MyComponent 不是FormatterUtils(它不是is-a 关系)。如果我在MyComponent 中需要两个格式化程序,那么这种方法将行不通,因为您只能从一件事继承。
    • 两个字:执行时间。捆绑文件后,即可在现场访问导出的功能。您有 1 条指令可以获取它们。使用 DI,您有 10、20、1000 条指令来获得单个功能。这似乎很明显。至于第二个选项,您没有指定需要两个格式化程序。
    • 我同意@SamHerrmann 的观点,即组件绝对不应该从 FormatterUtils 继承——这不是继承的正确用法。但除此之外,我同意对于像这样简单的可重复使用的“纯函数”,直接导入打字稿是一个明智的选择。 DI 的开销是值得为复杂服务支付的代价,以使您的测试保持简单和受限 - 所以它取决于您的格式化函数的复杂程度以及您是否愿意独立或就地测试它们(如果您不注入它们,您必须对它们进行适当的测试)。
    猜你喜欢
    • 1970-01-01
    • 2015-03-30
    • 1970-01-01
    • 2023-03-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-07-22
    • 2017-10-20
    相关资源
    最近更新 更多