Angular-@Input和@Output与可注入服务 [英] Angular - @Input and @Output vs. Injectable Service

问题描述

我要问自己，上/下子组件和中的@Input/@Output和使用仅通过依赖注入@Injectable()被实例化的服务的区别在哪里?或者，除了输入/输出"仅可以在parent-/child-comp中使用之外，还有其他区别.

I'm asking myself where are the differences between @Input/@Output in parent-/childcomponents and using services which is only once instatiated with dependency Injection@Injectable(). Or are there any differences besides Input/Output can only be used in parent-/child-comp.

以下示例可提供更好的可视化效果:

Following Example for better visualization:

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

ChildComponent:

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;
}

}

现在我们可以在父组件中设置值.并通过依赖注入获得子代的价值. ChildComponent:

Now we can set the value in the parent comp. and get the value in the child comp with dependancy injection. ChildComponent:

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

}

尽管第一种方法看起来更简单，但我认识到通过父子组件使用了3-4个属性carriyng. @Input/@Output与tamplete一起非常令人困惑和笨拙.

Even though the first approach looks simpler, I recognized using 3-4 properties carriyng through parent-/child comp. with @Input/@Output makes the tamplete very confusing and clunky.

推荐答案

不完全是具有已定义答案的问题，但是....

Not exactly a question with a defined answer, but....

@Input和@Output很有用.拥有一个仅维护两个组件的单例数据的服务就没有任何意义(或者深嵌套的祖父母->父->子组件).

@Input and @Output are useful if the communication between a parent and child is just that, between a parent and child. It wouldn't make sense to have a service that maintains singleton data for just 2 components (or however deeply nested grandparent -> parent -> child components are).

如果您的父母需要对孩子的变化做出反应，它们也很有用.例如，单击子组件中的一个按钮，该按钮在父组件中调用一个函数:

They're also useful if your parent needs to react to a change in the child. For example, clicking a button in a child component that calls a function in the parent:

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

在父级中:

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

如果您发现自己将许多@Input属性传递给孩子，并且想要整理一个模板，则可以为输入定义一个接口，然后将其传递.例如

If you find yourself passing many @Input properties to a child, and want to tidy up a template, then you can define an interface for the input, and pass it instead. e.g.

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

然后，您可以将定义传递给您的孩子，该定义是由父级设置的:

Then you can pass a definition to your child, which is set from the parent:

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

那么您的子组件可能具有:

Then your child component may have:

@Input properties: MyChildProperties;

您的模板变为:

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

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

Your child can access those properties from properties.property, properties.anotherProperty, etc.

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

Clean, tidy, and your data is now contained to those components that need to communicate.

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

Services, however, should be used where more than one component needs access to read/write data across your entire application. Consider a UserService for example, where many different components need to be able to access the currently logged in user. In this case, a service is sensible, as its a singleton, so once you have set your logged in user, any components that inject the UserService can access its data and functions.

类似地，如果您要使用服务来对更改做出反应，那么您会发现自己在编写带有可观察对象的服务，以便您的组件可以订阅数据中的更改.如上所述，事件发射器已经使用@Output为您提供了这种模式.

Similarly, if you were to use a service for reacting to change, then you'd find yourself writing services with observables so that your components could subscribe to changes in the data. Eventemitters already give you this pattern with @Output as shown above.

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

If it were a simple parent -> child communication, this is unnecessary overhead, and should be avoided.

也就是说，如果您发现自己使用服务来管理全局状态，则最好使用某种形式的状态管理，例如

That said, if you find yourself using services to manage global state, you'd be better off using some form of state management such as ngrx

这篇关于Angular-@Input和@Output与可注入服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！