Get the App
SLTechnology News&Howtos  ›  Development  › 

How to keep the separation of concerns in Angular instructions

Shulou Source: shulou.com Published: 2022-06-02 05:58:05 09月29日 Update

Editor to share with you how to maintain the separation of Angular instructions, I believe that most people do not understand, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Suppose we have a date selector component in our application. Each time the user changes the date, an event is sent to the analysis provider. So far, we have only used it once, so this analysis interface can be placed in the component that uses it:

Header-1.ts

Import {UntilDestroy, untilDestroyed} from'@ ngneat/until-destroyed';@UntilDestroy () class FooComponent {timespanControl = new FormControl (); ngOnInit () {this.timespanControl.valueChanges .pipe (untilDestroyed (this)) .subscribe (({preset}) = > {this.analyticsService.track ('timespan-filter apply', {value: preset,});});}}

However, now that we have more places to use the interface of this analysis, we don't want to write the same code over and over again. One might suggest that this code can be merged into a date selector and passed as an input parameter. [recommended for related tutorials: "angular tutorial"]

Data-picker-1.component.ts

Class DatePickerComponent {@ Input () analyticsContext: string; constructor (private analyticsService: AnalyticsService) {} apply () {this.analyticsService.track ('timespan-filter apply', {context: this.analyticsContext, value: this.preset,});.}}

Yes, this can be achieved, but it is not an ideal design. Separation of concerns means that the date selector itself has nothing to do with the analysis interface, and it does not need to know any information about the analysis interface.

In addition, because the date selector is an internal component, we can modify its source code, but what if it is a third-party component? How to solve the problem?

A better choice here is the Angular instruction, create an instruction, get a reference to the form through DI, and subscribe to changes in internal values to trigger analysis events. DatePickerAnalytics.directive.ts

@ UntilDestroy () @ Directive ({selector:'[datePickerAnalytics]',}) export class DatePickerAnalyticsDirective implements OnInit {@ Input ('datePickerAnalytics') analyticsContext: string Constructor (private dateFormControl: NgControl, private analyticsService: AnalyticsService) {} ngOnInit () {this.dateFormControl .control.valueChanges.pipe (untilDestroyed (this)) .subscribe (({preset}) = > {this.analyticsService.track ('timespan-filter apply', {value: preset, context: this.analyticsContext});});}}

You can now use the date selector every time you use it.

The above is all the contents of the article "how to keep the separation of concerns in the Angular directive". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Tags: Dates analyses selections instructions interfaces components concerns articles events code content tutorials more not much location information parameters places most applications Apple Docker Huawei Linux macOS MariaDB Microsoft MySQL NVidia OPPO Reno Shulou Information macOS Huawei MariaDB Redmi