角-@输入和@输出与可注入服务

Question

我在问自己，@Input/@Output在父/子组件中的区别是什么？和使用的服务只有一次依赖注入@Injectable()。或者，除了输入/输出之外，是否有任何差异只能用于父/子-comp。

下面是更好的可视化示例：

与@输入：

<parent-comp>
   <child-comp [inputFromParent]="valueFromParent"></child-comp>
</parent-comp>

ChildComponent：

@Component({
  selector: 'child-comp',
  template: ...
})
export class ChildComponent {
  @Input() public inputFromParent: string;
}

通过依赖注入

@Injectable()
export class Service {
   private value: string;

public get value(): string {
   return value;
}

public set value(input): void {
   value = input;
}

}

现在，我们可以在父comp中设置值。然后用依赖注入的方法得到孩子的值。ChildComponent：

@Component({
  selector: 'child-comp',
  template: ...
})
export class ChildComponent {
  private value: string;
  constructor(private service: Service) {
  this.value = this.service.getValue;
}

}

尽管第一种方法看起来更简单，但我认识到在父/子comp中使用3-4属性carriyng。与@Input/@Output使篡改非常混乱和笨重。

Answer 1

不是一个有明确答案的问题，但是.

如果父级和子级之间的通信只是父级和子级之间的通信，则@Input和@Output非常有用。如果有一个只为两个组件维护单例数据的服务(或者是嵌套得很深的祖父母、父->、父->子组件)，那就没有意义了。

如果你的父母需要对孩子的变化做出反应，它们也是有用的。例如，单击子组件中调用父组件中函数的按钮：

<my-child-component (myOutputEmitter)="reactToChildChange($event)"></my-child-component>

在父母中：

reactToChildChange(data: any) {
  // do something with data
}

如果您发现自己将许多@Input属性传递给一个子对象，并且希望清理一个模板，那么您可以为输入定义一个接口，然后将它传递给它。例如：

export interface MyChildProperties {
   property?: any;
   anotherProperty?: any;
   andAnotherProperty?: any;
}

然后，您可以将一个定义传递给您的子级，该定义是从父级设置的：

childProperties: MyChildProperties = {
    property: 'foo',
    anotherProperty: 'bar',
    andAnotherProperty: 'zoob'
}

那么您的子组件可能有：

@Input properties: MyChildProperties;

你的模板变成：

<my-child-component [properties]="childProperties"></my-child-component>

您的孩子可以从properties.property、properties.anotherProperty等访问这些属性。

干净、整洁，您的数据现在包含在那些需要通信的组件中。

但是，在需要访问多个组件以在整个应用程序中读取/写入数据的情况下，应该使用服务。例如，考虑一个UserService，其中许多不同的组件需要能够访问当前登录的用户。在这种情况下，服务是明智的，因为它是单例的，因此一旦您设置了登录用户，任何注入UserService的组件都可以访问它的数据和函数。

类似地，如果您要使用服务来响应更改，那么您将发现自己编写了带有可观察性的服务，以便组件可以订阅数据中的更改。Eventemitters已经在@Output中给出了这个模式，如上面所示。

如果它是一个简单的父->子通信，这是不必要的开销，应该避免。

尽管如此，如果您发现自己使用服务来管理全局状态，则最好使用某种形式的状态管理，如ngrx