2016-07-31 139 views
4

我有点被打字机装饰器所迷惑,以及它们是如何解释的。假设他们通过将元数据与它关联来“装饰”一个类。我似乎无法理解元数据如何与类的实例关联的概念。以角度2为例。Typescript装饰器与类的继承

@Component(
     { 
      selector:... 
     } 
    ) 


    export class foo { ... } 

目前我所了解的角度将实例类foo和莫名其妙的实例与装饰的争论联系起来,以便它可以提供服务,指令和模板。所有这些似乎也可以通过类继承来实现。如果我有一个Component类,并让我的组件扩展该类,那么为什么不能角度提供这些参数,当它以与对道具作出反应的方式引导时,并在此使用场景中完全摆脱装饰器。

class Component { ... } //say this has members such as selector, services, directives, etc.. 

class Foo extends Component { ... } 

那么你会与之反应,这是技术上的引擎盖下了什么与此

new Foo(ElementName, Directives, Services, etc..) 

实例化,在系统启动/运行。您派生组件并实现其方法。如果你需要在实例化时传递信息,那么你传入道具对象。

请赐教。

回答

2

据我所知,主要原因是为了方便静态评估。通过继承,您需要执行TS(或编译后的JS)代码来获取信息。

静态评估此元数据允许工具将其用于自动完成和模板中的所有类型的lint检查以及建筑设计人员和其他工具,以便于构建Angular应用程序。

此外,脱机模板编译器使用此元数据。