DEV Community: Alexander Goncharuk

11 friends of state management in Angular

Alexander Goncharuk — Fri, 19 Jan 2024 09:16:42 +0000

Intro

What you find below is an opinionated list of rules based on trial and error working on Angular projects of different type and size. After making some mistakes and over-complicating things where they shouldn't be complicated, I came up with this list of rules that works well for all recent projects I have contributed to. And I hope these make enough sense to be shared with the community.

The rules provide ❌ Avoid and ✅ Prefer code snippets where possible, as well as some reasoning behind each recommendation. The first two rules are more foundational, and hence I want to provide a bit more explanation for them. The rest are mostly short practical recommendations.

💡 Note this article doesn't delve into the world of signals. Signals are great and open path for a whole new way of dealing with synchronous reactivity in Angular apps. No doubt these are going to impact the state management topic a lot. But I believe we need more time for best practices to emerge in this area. Hence for this read choose to focus on those recommendations that are well tested and battle and which I can vouch for.

Rule 1: Use dedicated tools for state management

Angular is a framework that provides a lot of tools out of the box to build complex applications. Which often makes devs question the fact we need any dedicated libraries for managing state. At first glance, this makes sense. Why introduce more dependencies and complexity when we have services, Subject and BehaviorSubject and an army of RxJs operators? I would like to start with clearing this question up by saying you should use a library. And explain how I came to this conclusion.

Indeed, there are several ways of implementing management using Angular and RxJs APIs only without any help from the dedicated libraries. But the problem is, this fact alone opens a little Pandora's box for our codebase maintainability over time. Consider we have a team of several developers, and they worked on the different features of our app:

First developer relies on simple class properties and imperative state updates.

public synchronousState: State = initialState;

Second developer is more into reactive programming and uses Subject and BehaviorSubject to manage state in
the feature they've built:

public behaviourSubjectState$ = new BehaviorSubject<State>(initialState);

public subjectState$ = new Subject<State>();

Third developer is even more into reactive programming, so one will multicast the state using shareReplay operator to make sure every consumer won't create a new observable:

public
subjectStateMulticasted$ = this.subjectState$.pipe(
  shareReplay({ shareReplay: 1, refCount: true })
);

Fourth developer will do the same, but one is not that much into Angular and RxJs, so is unaware of all the tips
and tricks for shareReplay operator and will not use refCount:

public anotherSubjectStateMulticated$ = this.subjectState$.pipe(
  shareReplay(1)
);

A quick off-topic for this one. Under certain conditions, which are not that hard to meet, such shareReplay usage will result in a memory leak and maybe even browser crashing with an "Out of memory" error caused by subscriptions to source observable create by shareReplay never being unsubscribed. RxJs is great, but with great power comes great responsibility. I will not go more into details here, but you can read about the mentioned shareReplay behaviour in RxJS: What’s Changed with shareReplay?.

Fifth developer is coming from the server side world mostly with years of object-oriented programming experience. So will prefer private fields with getters and setters:

private _getterAndSetterState: State = initialState;

public get getterAndSetterState(): State {
  return this._getterAndSetterState;
}

public set getterAndSetterState(state): void {
  return this._getterAndSetterState = state;
}

And below are a couple of examples of the side effects management.

A simple method that calls some other methods:

public simpleMethodForSideEffect(state: State): void {
  const data = this.someService.calculateData();
  this.someOtherService.doSomethingWithData(data);
}

A long-living subscription that listens to a trigger observable and calls some other methods:

public observableListenerForSideEffect$ = this.someSubject$.pipe(
  tap(() => {
    const data = this.someService.calculateData();
    this.someOtherService.doSomethingWithData(data);
  })
).subscribe();

The features built by our developers will likely need to both hold some state and manage some side effects, basically any CRUD use case qualifies for this. So we can multiply these 5 × 2 since nothing forbids us to mix and match them. And then let's multiply by two once again, because some devs will put state management and side effects in component classes, but some will put them in services. Some of these services will likely have providedIn: 'root', which means created once for particular screens user navigated to they will stay living in memory regardless of if they're needed further or not. Others will be bound to the lifecycle of components they serve to.

This is not an extensive list of all the combinations you can have. The approach of every made-up developer is not necessarily bad. But the thing is, in every scenario listed below:

I start working on a new feature.
I need to dive into an existing feature built by someone else to debug it to fix an issue or to introduce a change.
A new developer joins the team and wants to get going fast.

All these different ways of doing the same thing we have across the app will be my enemy. The codebase becomes hard to reason about and there is no "go-to" solution for a new feature implementation because you get lost in a variety of existing approaches and are likely to pick the wrong one only because that is how it was done in a .ts file located nearby.

It sounds like a bit "captain Obvious" type of conclusion. But from my observations, the idea to just use BehaviourSubject turns out to be very appealing up till the late point of realizing that codebase has become huge and hard to refactor. It is not always a bad idea to avoid external dependency. But trust my experience, state and side effects management is no the area where you want to implement your own wheel.

It also turns out to be likely to overestimate your and your teammates' ability to keep things consistent and follow the agreed way of doing things. Don't put that extra burden on yourself and your team. Delegate it to a well-maintained library with simple APIs. Find more on this ⬇️.

Rule 2: Always prefer local state unless you have a good reason to use global state

💡To reason about global versus local state approach, this section compares concrete implementations of both: NGRX global store and NGRX component store. These are both part of @ngrx libraries family and are the two most popular libraries used for state management in framework ecosystem according to npm statistics. While the code examples provided below could also be implementation agnostic, I found this would be a somewhat artificial generalization for the sake of generalization. And I intentionally wanted this article to be a collection of practical recommendations. The main local vs global reasoning still applies to other implementations of your choice, just not all the details from the examples below will be applicable.

Before I dive into the benefits of local store, I would like to say that I'm not an opponent of global state as a concept. Neither am I an opponent of NGRX global store as the most well known and widely used implementaton of it in the Angular ecosystem. I don't find the necessity to create feature.actions.ts, feature.reducer.ts, feature.effects.ts that big of a burden as some people do. Moreover, I'm grateful to the NGRX team for all the great work they've done over the years, and the effort they put into making the global store library simpler to use, like introducing createActionGroup.

From what I've read on this topic, it seems to me there is a misconception in the community that these files exist
to have a state management solution only. Which makes people who prefer fewer files think of these as an overkill.
But in fact, it is not only about state management and unidirectional data flow. The great value actions bring is indirection between the action dispatcher, and the part of your system that processes this action. Different parts of your system can react to it differently. Some environments your app runs in can choose to ignore some actions not relevant for them. This gives you a lot of control to make your codebase more flexible. I had an experience building an app for brokers and traders who used it both a browser app and a desktop app running in an Electron-based wrapper. The classical global NGRX store was a great fit for this app thanks to the indirection it offers.

If you need this indirection, the global store is the right choice for you. But in most projects, I very likely don't need it. And what I need instead is a simple but consistent solution to exposing public APIs for reading and manipulating the state, and triggering side effects. I want state selectors, updators, and effects to reside next to each other in the same place to keep related things close. And I want the state to be local, in other words, I want it to be created and destroyed along with the component tree using this state. A common pattern is to provide it in the component providers:

@Component({
  providers: [FeatureStore],
  template: `
    @for(item of store.items$ | async; track item.id) {
      {{...}}
    }
    <button (click)="store.removeItem(item.id)">Remove item</button>
    <button (click)="store.loadItems()">Refresh</button>
  `
})
export class FeatureComponent implements OnInit {
  public store = inject(FeatureStore);
}

And from my experience, usually this is all you need for state management without introducing extra complexity and coupling component trees with root app-level providers. It is easier to ensure data freshness thanks to state being bound to component lifecycle. It is easier to refactor local state to global state when necessary than the other way around.

When necessary, this approach also makes it simple to re-use code across different components sharing the same state/side effects logic. Each component gets an instance of the store configured to its. Configuration can be done in different ways, by using DI tokens, for example. But here is an example of a simple configuration object passed to the store provider factory:

export class ListDataStore extends ComponentStore<ListDataState> {
  constructor(private config: Partial<ListDataState>) {
    super({
      ...initialState,
      ...config
    });
  }
}

@Component({
  providers: [{
    provide: ListDataStore,
    useFactory: () => new ListDataStore({ 
      pageSize: DEFAULT_PAGE_SIZE 
    })   
  }],
})

@Component({
  providers: [{
    provide: ListDataStore,
    useFactory: () => new ListDataStore({ 
      sortBy: DEFAULT_SORT_SIZE, 
      sortDirection: DEFAULT_SORT_DIRECTION 
    })   
  }],
})

You can thus share all the special logic for list data manipulation you have in your system. But at the same time, leave space for customization for each particular feature need. This is a very powerful and very underused pattern for logic sharing in Angular. You can read more on the power of private providers in Make the most of Angular DI: private providers concept.

I will not copy-paste component-store APIs description here, but will provide a link to the [official docs (https://ngrx.io/guide/component-store/initialization) instead. Just a couple more points related to this library that I believe are worth highlighting:

All state selectors have distinctUntilChanged and shareReplay by default, so you don't have to remember to add them every time.
The library is tiny: 1.9kB minified + gzipped.

Rule 3: Limit component code by view-related logic only

For components that contain a fair amount of business logic, prefer moving state and side effects logic to component stores. Besides the importance of consistency, this makes components cleaner and easier to maintain in several ways:

Enables using DI instead of input drilling to pass data to child components that belong to the same feature and need to work with the top-level state.
Makes it easier to use the same logic somewhere else if necessary.
Makes unit testing easier since you're testing just TypeScript classes as opposed to testing TestBeds imitating components with all related complexities.
Makes accessing state reactive by convention.

❌ Avoid

@Component({
  ...
})
export class FeatureComponent implements OnInit {
  private cd = inject(ChandeDetectorRef);
  private dataService = inject(DataService);

  public data: Data;
  public filteredData: Data;
  public filterCriteria: FilterCriteria;

  ngOnInit() {
    this.loadData();
  }

  private loadData(): void {
    this.dataService.getData().pipe(
      tap((data) => {
        this.data = newData;
        this.applyFilter();
      })
    ).subscribe();
  }

  private apllyFilter(): void {
    this.filteredData = this.data.filter(item => item.name === this.filterCriteria);
    this.cd.detectChanges();
  }
}

<div *ngFor="let item of filteredData">
...
</div>

✅ Prefer

export class FeatureStore extends ComponentStore<FeatureState> {
  private dataService = inject(DataService);

  constructor() {
    super({ data: [], filterCriteria: null});
  }

  public data$ = this.select(state => state.data);
  public filterCriteria$ = this.select(state => state.filterCriteria);
  public filteredData$ = this.select(
    this.data$,
    this.filterCriteria$,
    (data, filterCriteria) => data.filter(item => item.name === filterCriteria)
  );

  public loadData = this.effect(trigger$ => trigger$.pipe(
    switchMap(() => this.dataService.getData()),
    tap(data => this.setData(data)),
  ));
}

@Component({
  ...
})
export class FeatureComponent {
  public featureStore = inject(FeatureStore);

  ngOnInit() {
    this.featureStore.loadData();
  }
}

<div *ngFor="let item of featureStore.filteredData$ | async">
...
</div>

While the recommended approach can sometimes require a bit more lines of code, it becomes much easier to maintain:

Data dependencies are expressed in a declarative and reactive manner.
Public methods exposed by the store are available for both the feature container component and all its children.
Observables are efficient and memory safe. Effects are auto subscribed when the store host component is initialized and auto unsubscribed when one is destroyed.

Cases when the state belongs to the component

While the component store is a lightweight state management solution that can be applied to both complex and simple features and even to generic UI controls that are rich enough with stateful logic, the rule to use it is not set in stone. Common sense should always prevail.

Small presentational components and simple UI controls

Consider a simple UI control like this:

@Component({
  selector: 'app-slider',
  ...
  @Input({required: true}) state: boolean;
  @Input() infoTooltipText: string;
  @Output() stateChange = new EventEmitter<boolean>();
  //... formControl implementation
})

For small presentational components and simple controls like this, introducing a separate class for state management would be an overkill. It makes more sense to have it in the component class itself.

This particular example is a bit artificially simplified, you can have more data in the component. The key indicator to use a dedicated store is the need to manipulate this data (combine, filter, etc.) and handle side effects as part of the logic encapsulated in this component.

Data aggregation is very specific to this component use case only

When a component store is used for a tree of components, we want to keep logic that is already or will potentially be shared by different components of the tree in the store class. But at the same time, we don't want to bloat the store class with all possible use cases handling.

If we have a component like this that shows a very specific loading indicator, that should consider a couple of factors:

public secondResourceLoadingStep$ = combineLatest([
  this.store.firstResourceHasLoaded$,
  this.store.secondResourceHasLoaded$,
]).pipe(
  ([firstResourceLoaded, secondResourceLoaded]) => firstResourceLoaded && !!secondResourceLoaded
)

We might want to have it in the class of the component displaying the indicator instead of handling it in the store
class. Unlike firstResourceHasLoaded$ and secondResourceHasLoaded$ selectors, which we might need in different places, this indicator is very specific to this component's use case and is a read-only operation, which makes it a good candidate to put closer to the view where it is used.

Other use cases

A general rule to follow when deciding whether a particular piece of business logic to the store or component class is to ask yourself the following questions:

Is the same logic needed in other parts of this component tree?
Does this logic only make sense in the context of the particular component template? For example, depends on its specific HTML structure.

When logic is coupled to the view, it makes sense to have it in the component class.

Rule 4: Always separate stateful and stateless services

Don't mix stateful and server API logic in the same class. Data fetching/manipulation logic and app state are separate concerns that should be separated on the code level as well.

❌ Avoid

export class FeatureStore extends ComponentStore<FeatureState> {
  private httpClient = inject(HttpClient);
  //...
  public loadData = this.effect((trigger$) =>
    trigger$.pipe(
      switchMap(() => this.httpClient.get<Data>(`${this.baseUrl}/data`)),
      //...
    ),
  );
}

✅ Prefer

export class FeatureStore extends ComponentStore<FeatureState> {
  private dataService = inject(DataService);
  //...
  public loadData = this.effect((trigger$) =>
    trigger$.pipe(
      switchMap(() => this.dataService.getData()),
      //...
    ),
  );
}

export class DataService {
  public getData(): Observable<Data> {
    return this.httpClient.get<Data>(`${this.baseUrl}/data`);
  }
}

Rule 5: Access state synchronously when it makes sense

RxJs is a great tool that helps to make applications reactive and express data relations in a declarative manner, but one is not a silver bullet for every use case.

While RxJs shines when it comes to asynchronous data streams, sometimes all we need is to get a slice of our state synchronously. Utilizing observable for this does nothing else but makes the code more complex. In this case, it is perfectly fine to use synchronous getters selectors available in the component store via a private get method of the component store.

It is important to ensure reactivity serves us, not the other way around. When the code looks like you're working RxJs around, prefer synchronous logic instead:

❌ Avoid

public doSomethingInUserContext(): void {
  this.userStore.userId$.pipe(
    take(1),
    tap(userId => {
        //... logic using userId here
    }),
    this.untilDestroyed()
  ).subscribe();
}

// or:

public async doSomethingInUserContext(): Promise<void> {
  const userId = await this.userStore.userId$.pipe(
    take(1)
  ).toPromise();
  //... logic using userId here
}

✅ Prefer

public doSomethingInUserContext(): void {
  const userId = this.userStore.userId; // where userId is a synchronous getter in the store class that uses component store `get` under the hood
}

Rule 6: Do not create "proxy methods" for no good reason

When you need to expose a store method to the component template, a common approach is to create a method in the component class that just calls the store method. This is very common to meet this approach in store usage examples, both global and component store, and even in official docs. And this is a valid approach when you have some extra logic to run before control is passed to the store.

But when you don't, these are just extra lines of code that make the codebase a bit more verbose and refactoring a bit longer without any real benefits. And it is even more relevant for state selectors in scenarios when there is no need to apply any processing to the data returned by the selector.

❌ Avoid

@Component({
  providers: [FeatureStore],
  template: `
    @for(item of items$ | async; track item.id) {
      {{...}}
    }
    <button (click)="removeItem(item.id)">Remove item</button>
    <button (click)="loadItems()">Refresh</button>
  `
})
export class FeatureComponent implements OnInit {
  private store = inject(FeatureStore);
  private items$ = this.store.items$;

  public removeItem(id: string): void {
    this.store.removeItem(id);
  }

  public loadItems(): void {
    this.store.loadItems();
  }
}

✅ Prefer

@Component({
  providers: [FeatureStore],
  template: `
    @for(item of store.items$ | async; track item.id) {
      {{...}}
    }
    <button (click)="store.removeItem(item.id)">Remove item</button>
    <button (click)="store.loadItems()">Refresh</button>
  `
})
export class FeatureComponent implements OnInit {
  public store = inject(FeatureStore);
}

There is a well-known practice to keep services private and expose their public interface to the component template via public methods. But in the case of component stores, I prefer to see component store provider as an extension of the component class itself that embraces logic composition. So it is up to store itself to know which its methods to expose as public to consuming components and which to keep private.

And if there is a good reason to create this method in the component class, you can always do this. But don't create this proxy code just for the sake of conforming to "providers are always private" rule.

Rule 7: Prefer less verbose APIs whenever possible

For most state update operations when you don't need to run any logic in the updater, you can use patchState:

❌ Avoid

public setElement = this.updater((state: BlockSettingsState, element: BlockElement) => ({
  ...state,
  element,
}));

✅ Prefer

private setElement(element: BlockElement): void {
  this.patchState({element});
}

Rule 8: Remember about multicasting observables returned by selectors

While shareReplay is added to every selector of the component store by default, you lose it for successive computations when you apply pipe to your selector. Combining selectors is the best solution in this scenario:

❌ Avoid

public combinedSelector$ = this.data$.pipe(
  withLatestFrom(otherData$),
  map(([data, otherData]) => expensiveComputations(data, otherData)) // will run for every subscriber in this case

✅ Prefer

public combinedSelector$ = this.select(
  this.data$,
  this.otherData$,
  (data, otherData) => expensiveComputations(data, otherData))
);

If the combined selector solution doesn't fit for any reason, add shareReplay operator at the end of the pipe:

.pipe(
 //... other operators
 shareReplay({refCount: true, bufferSize: 1}),
);

Rule 9: Use state management APIs, but do not limit yourself to it

While consistency is the goal, it doesn't mean in the store class we should limit ourselves to the library APIs only. Library APIs like updaters, selectors and effects cover most of our needs, but it is often convenient and absolutely fine to extract some logic into simple private methods of the same component store class.

Another common use case is when part of the state should live in a reactive FormGroup which provides great built-in APIs for manipulating and validating form controls. In this case, you create a FormGroup as a property of the store class and use its API in store selectors and effects when necessary.

import { combineLatest } from 'rxjs';
import { debounceTime, shareReplay } from 'rxjs/operators';
this.filtersForm = new FormGroup({
  name: new FormControl('', [Validators.required]),
  //...
});

this.users$ = this.select((state) => state.users);
this.filteredUsers$ = combineLatest(this.users$, this.filtersForm.name.valueChanges.pipe(debounceTime(200))).pipe(
  map(([users, filtersName]) => users.filter((user) => user.name.includes(filtersName))),
  shareReplay({ refCount: true, bufferSize: 1 }),
);

Rule 10: Embrace pure functions and static methods

If methods don't use class instance properties at all, there is no reason to make them instance methods. Prefer pure functions or static methods instead. This approach gives you several benefits:

Saves memory if many instances of this component are created at the same time (e.g., in a list or table)
Makes code easy to cover with unit tests since there is no need to create a component instance, mock providers for its DI, etc.

❌ Avoid

private square(value: number): number {
  return value * 2;
}

✅ Prefer

export const square = (value: number): number => {
  return value * 2;
};

The choice between pure functions living in a separate file like feature.fn.ts next to the component file and static methods of the component class is up to you. As a rule of thumb, pure functions should be the preferable choice since these are easier to test and reuse. But sometimes there is not enough stateless logic to justify creating a separate file for
it. In this case, static methods of the component class can be a reasonable choice as well.

Rule 11: Make sure you handle errors in effects

Because an effect is long-living observable, you should make sure errors thrown inside the operator chain are handled correctly to keep effects alive.

In most real-world scenarios when an error is thrown inside the operator chain, you don't want to stop the entire observable, which would happen without correct error handling. Use catchError operator and return of(<DATA PLACEHOLDER>) or EMPTY to keep the observable alive.

❌ Avoid

public listenToSomeTrigger(): void {
  this.someTrigger$.pipe(
    switchMap(() => this.someService.getData().pipe(
      map((data) => ...), // error can occur here, but no error handling is provided
    )),
    tap(() => ...),
  ).subscribe();

✅ Prefer

public listenToSomeTrigger(): void {
  this.someTrigger$.pipe(
    switchMap(() => this.someService.getData().pipe(
      map((data) => ...),
      catchError(error => {
        ...
        return of([]);
      }),
    )),
    tap(() => ...)
  ).subscribe();
}

⚠️ Error should be handled in the inner observable chain (created with switchMap) to keep the outer observable alive.

For operators outside inner observables, like the ones created by switchMap or mergeMap, make sure you wrap data manipulations done by the methods called by these operators in try/catch blocks and return meaningful data placeholders when necessary.

Conclusion

Hope these rules help you to make your codebase more consistent and easier to maintain. These work well for me, but I'm still receptive to any feedback that leads to a reasonable discussion. So if you have anything to say or ask, don't
hesitate to do so in the comments and I will be happy to get back.

You don't want a BaseComponent in your app

Alexander Goncharuk — Thu, 09 Mar 2023 12:53:50 +0000

In this article, I will do my best to explain why I believe having BaseComponent in your Angular project is a bad option for code sharing. And the more your project evolves, the bigger your regret will be.

While some thoughts in this article are probably applicable to other modern SPA frameworks as well, it is mainly relevant to Angular projects and operates with Angular APIs.

We will also explore several better alternatives available in the framework to keep your code DRY.

Why BaseComponent even exists

Before looking into problems one causes, let's analyze why it is not uncommon to find a class named BaseComponent in different code bases.

Angular on its own is a mix of different software paradigms and OOP is one of them. Hence, it may be tempting to put the repeating logic pieces in a class called BaseComponent that will provide every child component extending it with all the shared functionality needed. Consider the following example:

export abstract class BaseComponent implements OnDestroy {
 protected destroy$ = new Subject<void>;
  protected abstract form: FormGroup;

  constructor(private analyticsService: AnalyticsService,
              private router: Router) {}

  public trackPageVisit() {
    const currentUrl = this.router.url;
    this.analyticsService.pageViewed({url: currentUrl})
  }

  get isFormValid(): boolean {
    return this.form.valid;
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }

  // ... many other shared methods added over time
}

The need to share functionality is one of those needs a developer will likely have in almost every software project. Inheritance is one way to achieve this goal. But using inheritance for this purpose in Angular is a bad idea both because of the problems it creates and because of the alternative powerful techniques this framework offers to achieve the same goal.

Let's start with the problems part.

What is wrong with BaseComponent

It breaks the meaning of inheritance

It is hard to argue with the fact OOP is by far the most widely used programming paradigm in commercial development. This doesn't mean though it is a universal solution to every problem. Inheritance as one of the OOP pillars is meant for Object A is a subtype of Object B relationship. While in BaseComponent it is used for Object A and Object B need a Function C relationship instead.

✅ FullTimeEmployee extends Employee and HourlyRateEmployee extends Employee is a good example of inheritance.

❌ FullTimeEmployee extends WithLogger and HourlyRateEmployee extends WithLogger is a bad example of inheritance.

I guess that such a light-headed take on good OOP practices can be explained by the fact engineers sometimes apply different rules to code in the domain model and code in the view layer. This practice is wrong though and doesn't make it less of an anti-pattern.

💡 Using inheritance, where it should not be used, is wrong regardless of which layer of application it happens in.

You don't get to choose what to inherit

If you have a BaseComponent in your application like the one provided above, you may soon find your application in the following state:

Different components using takeUntil(this.destroy$) for subscriptions done in the component classes, will extend the BaseComponent for the sake of its shared unsubscription logic.
Only some of these child components need the page tracking method.
Only some of these child components contain forms and hence need an ifFormValid getter.
Finally, not every component that actually tracks page visits or contains a form does manual subscriptions. Many of them might not need the destroy$ logic at all.

Extending BaseComponent pollutes component classes that now contain every single method and property of the base class. This has no positive effect, but brings the following negative effects:

Application pays an extra cost for every component inheriting all the methods of the parent class regardless of if this method is needed or not.
Debugging experience gets worse since components are cluttered with non-relevant properties and methods.

Makes it easy to shoot yourself in the foot by rewriting lifecycle hooks

This particular mistake I've seen in almost every Angular project I worked on:

export class MyComponent extends BaseComponent implements OnInit, OnDestroy {
  // ...

  ngOnInit(): void {
    this.subscription$ = this.service.getSubscription$().pipe(
      takeUntil(this.destroyed$)
    ).subscribe();
  }  

  ngOnDestroy(): void {
    this.cleanupMyComponentStuff();
  }
}

Did you spot the problem here? The takeUntil(this.destroyed$) will never work, because destroyed$.next() is called in the extended BaseComponent's ngOnDestroy hook, and we forgot to call super.ngOnDestroy() in the MyComponent's ngOnDestroy body.

How can we make such a naive mistake with all the experience in OOP that the team has? How come the linter rules not catch such a thing? We could have been more careful and could have had an eslint rule for this. But here is the thing: it just happens, believe it or not. And results in memory leaks.

Creates stronger coupling in the app

As your application evolves, you may find yourself in a situation where particular pages of your app qualify to be moved into a separate package. Usually, there are several factors leading to this, like the size of the module and its independence from the rest of the application. Such modules can be developed by dedicated teams and even deployed independently if follow the micro-frontend architecture principles. It can also be just a publishable library exporting modules or components that belong to one business domain, or a library in a monorepo that is not published to any repository, but still clearly defines its public interface and should not depend on imports from any other domain libraries or the main app.

Finding out that your Angular components that are about to be extracted from the monolith extend BaseComponent is not a piece of cake. You will unlikely move one to a shared library. Also, there is no good place for such thing as BaseComponent among shared libraries, because over time it tends to turn into a swiss-army knife providing different shared functions for different parts of your app. This may become an impediment slowing down your refactoring initiatives.

Passing constructor arguments every time

When you extend a BaseComponent, you also get to pay the price of calling super() with all of the parameters that the parent's constructor expects:

@Component({...})
export class OrderHistoryComponent extends BaseComponent {
  constructor(private router: Router, 
              private cd: ChangeDetectorRef, 
              @Inject(LOCALE_ID) private localeId: string,
              private userService: UserService,
              private featureFlagService, FeatureFlagService,
              private orderHistoryService: OrderHistoryService) {
    super(router, cd, localeId, userService, featureFlagService);
}

The only provider we actually need in this service is OrderHistoryService. The rest is tax paid to the BaseComponent which we are likely extending for a small reason like getting destroyed$ subject from it. And you are forced to repeatedly pay this tax in every child class, i.e. every component extending BaseComponent. This is both tedious and annoying.

Angular 14 introduced a new way to inject providers - the inject function is now callable during the component's construction phase:

private router = inject(Router);

There are several reasons to like it. Eliminating the problem outlined above is one of them. But it will take time until this will become the standard way of injecting providers in components if it ever will.

Alternatives

I sincerely believe you found the reasons above good enough to get rid of BaseComponent. But our need to share code doesn't go anywhere when we decide to drop one. Also, advice to not do something that is not complemented by what to do instead is not much of advice.

Let's explore the well-known alternative techniques of sharing application logic between multiple components. Depending on your needs you might need one or another, but what they have in common is that each of these options is better than another method in the BaseComponent. These techniques also embrace a very well-known OOP principle.

We are not going to dive very deep into each of these techniques as they deserve separate topics and there are plenty of articles written on these already. But will have a brief intro to each instead and links attached to some of these to explore the topic in more detail.

View providers

A technique I sincerely believe is heavily underestimated in Angular community is view providers. Or the providers you define in the providers property of @Component decorator's metadata.

Say you don't want to repeatedly inject Router and get page settings in the component's initialization phase, and need a way to easily reuse this logic in many components where it is needed.

@Component({    
  ...    
  providers: [PageSettings]
})

private pageSettings = inject(PageSettings); // or provided the old good way in the component's constructor

This technique is very powerful:

You have full access to DI container, just like in the host component.
The lifecycle of such a provider is bound to the lifecycle of the host component it is used with. You even have ngOnDestroy hook called in the provider class when the host component is destroyed (but not other component lifecycle hooks).
It allows hiding such dependencies behind injection tokens which improves testability a lot. In your TestBed you can replace these dependencies with their mocks implementing the interface of the injected token.

And at the same time, you can create generic component-level providers with shared logic and fine-tune them to specific component needs. This can be achieved by using provider factories. Consider the following example:

{
  provide: PAGE_SETTINGS,
  deps: [SettingsService, ActivatedRoute],
  useFactory: pageSettingsFactory(SettingsStorage.LOCAL)
}

Where the factory would get the necessary page data from the route params and map it to the page settings. The pageSettingsFactory parameter will let the factory know that settings should be read from the local storage. In a different place where this generic provider is used, you might want to read them from the server by passing SettingsStorage.REMOTE. You can read more in this article.

ComponentStore from NgRx library is another good example of this technique. It's small and addresses most of your component's needs for local state management.

Directives of different kinds

Whenever the logic you need to share can be applied in the template, directives are your best friends. Use structural directives when you need to conditionally create or destroy DOM elements, and attribute directives when manipulating properties of the host element is enough:

<div *appRole="'ADMIN'; else: defaultTemplate">Content shown to admins only</div>

<div copyOnClick>This will be copied to the clipboard when clicked on</div>

With the latest host directives API a whole new world of opportunities opens to Angular developers. From simple attribute directives composition to more complex scenarios. You can choose which part of your host directives API to keep private and which to expose behind custom names. Consider this example from the official documentation:

@Component({
  selector: 'admin-menu',
  template: 'admin-menu.html',
  hostDirectives: [{
    directive: MenuBehavior,
    inputs: ['menuId: id'],
    outputs: ['menuClosed: closed'],
  }],
})
export class AdminMenu { }

<admin-menu menuId="top-menu" (menuClosed)="logMenuClosed()">

A component can inject its hostDirectives and vice versa. This makes the interaction between those seamless.

Pipes

A pipe is a very good choice for sharing data transformations in templates. So-called pure pipes are widely used for this purpose. In case simple data transformation is not enough for your needs, just like in directives in pipes you have access to DI, which gives your great power (comes with great responsibility:)).

If you work with Angular, you probably are familiar with these concepts already, so the only thing I would like to add is a handy gotcha on how you can create generic data transformation pipes like this:

<div *ngFor="let item of items | map : pickFirstN : 4">{{item}}</div>

Where instead of pickFirstN your components can provide any other function for their needs that complies with the expected function signature.

Don't overuse pipes though. This is a great tool, but not the right choice for every data manipulation task. Follow the guidelines from Angular documentation:

💡 Use pipes to transform strings, currency amounts, dates, and other data for display.

Decorators

One of the most common things to find in BaseComponent is unsubscription logic. We already highlighted above the downsides of using the extended component's ngOnDestroy hook for this purpose. Let's see how we can solve the same problem with help of Typescript decorators:

@UntilDestroy({ checkProperties: true })
export class MyComponent { 
  subscription$ = interval(2000).pipe(
    tap(() => { /* work done here */ })
  .subscribe();
}

That is it from the user's perspective. The subscription$ will be unsubscribed automatically when MyComponent is destroyed. No need to use takeUntil for unsubscription sake only, no risk of creating memory leaks by not calling parent ngOnDestroy like in the example above.

You can find the code of the UntilDestroy decorator by this link. All it does is patches the component's ngOnDestroy with unsubscription logic and call the original method at the end.

I would warn you about getting over-excited with decorators though. There are a couple of reasons why:

The Typescript implementation of decorators differs significantly from the ECMAScript standard decorators proposal that is currently in Stage 3.
Decorators are less explicit than alternative sharing techniques. This might be a matter of taste and depends on how much you are into metaprogramming. But in general code explicitness is a good thing, we don't want to have too much magic in our business logic code.

💡 Using decorators for routine work you would prefer the framework to do for you (just like it does for @Component, @pipe, etc.) is a good rule of thumb.

Resolvers

Not an option for every component. But when the logic to share is loading data for a component bound to a route in your application, a resolver is your friend:

{
  path: 'page/:id',
  component: PageComponent,
  resolve: { settings: PageSettingsResolver }
}

export const pageSettingsResolver: ResolveFn<PageSettings> = (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
  return inject(PageSettingsService).getPageSettings(route);
};

You can get the resolved data from the data property of ActivatedRoute provider in your component.

Typescript and Javascript at your disposal

It is worth nothing to say that often vanilla JS/TS code-sharing techniques are just enough when you don't need to integrate with the rest of the DI tree. Along with simple functions exported from a file, you can use static methods to group actions that logically belong together.

If for some reason you wanted your own implementation of max and min, there is really no need to create multiple copies of functions that are not using the context of the class they are called from. At the same time, grouping such functions as static methods of the same Math class improves code organization by keeping related things close:

export class CustomMath {
  public static customMin(a: number, b: number): number {
    ...
  }

  public static customMax(a: number, b: number): number {
    ...
  }
}

There are also less often used, but still powerful techniques like mixins and proxies.

And of course, a collection of design patterns well tested by time and implementable in Typescript.

Wrapping up

I hope you found the arguments against the BaseComponent reasonable and the mentioned alternatives useful. As you see, Angular offers plenty of powerful tools to make your application DRY.

Thanks for reading and see you at the next one someday!

A better feature flag directive in Angular

Alexander Goncharuk — Tue, 11 Oct 2022 12:56:33 +0000

Custom structural directives are powerful. They promote a declarative approach and help you keep your Angular components DRY and clean. In this article, we are going to build a simple yet useful structural directive that will show one or another piece of the template depending on the value of the feature flag. Here is what we expect from our feature flag directive's public interface:

Directive will allow conditionally showing parts of the template depending on the feature flag's status.
No additional code should be needed in the component class apart from importing the directive itself to make it available in the template.

How is this one better

Directives like this are quite common in Angular projects. But with a bit of additional knowledge, we can build a more powerful directive by implementing an option to use an alternative template to show in case the feature flag's value is falsy. This option is very convenient, and yet it is not used as often as it deserves, at least based on my experience working with several Angular codebases.

If you have used *ngIf=A; else B syntax in your Angular templates, you already know that it is possible to have a behavior like this. Here is how our structural directive will be used in the component's template:

  <div *appIfFeatureFlag="'FEATURE_1'; else: defaultTemplate">Feature 1 template</div>
  <ng-template #defaultTemplate>Default template</ng-template>

We will also use some APIs that Angular team introduced not so long time ago. In particular, standalone directives and the inject function as an alternative to injecting via the constructor's arguments.

Why feature flag use case

We could pick any shared feature for the structural directive demo purpose. I'd hence like to say a couple of words about the reasoning behind picking the feature flags use case before we start.

The path to building bug-proof applications is long and challenging. It entails many things to learn and many practices to adopt. You need very good test coverage, correct abstractions, short development cycle to name a few. Introducing feature flags takes nowhere near as much time as mastering the above-mentioned practices. By no means do feature flags replace these things, but they are the right first step on this path. You get the option to roll back problematic changes in any environment within seconds without redeploying.

I strongly believe that feature flags are a must-have thing in any application that runs in production.

This is crucial both for users who are no longer forced to use the broken feature waiting for the fix, and for developers who are thus able to address issues in non-stressful conditions.

Implementation

Without further ado, let's create the directive. We will start with the directive's Inputs and dependencies:

@Directive({
  selector: '[appIfFeatureFlag]',
  standalone: true
})
export class FeatureFlagDirective implements OnInit {
  @Input()
  appIfFeatureFlag!: string;
  @Input()
  appIfFeatureFlagElse?: TemplateRef<unknown>;

  private templateRef = inject(TemplateRef<unknown>);
  private viewContainerRef = inject(ViewContainerRef);
  private featureFlagService = inject(FEATURE_FLAGS_SERVICE);

  //...
}

We are using standalone: true to make our directive importable directly without NgModule. And define two inputs for the name of the feature flag we will be checking and the alternative template to show in case of falsy flag value. The code is written in Typescript strict mode, so we explicitly mark optional and mandatory inputs with corresponding assertion operators.

Pay attention to how these inputs are named.

To use the desired syntax in templates we need to prefix all additional inputs with the name of the directive, which is appIfFeatureFlag in our case.

Hence, if we want to specify the alternative ng-template to show in the else parameter, we should name the relevant input appIfFeatureFlagElse.

Bear in mind how the last part of the input's name written in camel case turns into lower case automatically when the directive is used in the template:

<div *appIfFeatureFlag="'FEATURE_1'; else: defaultTemplate">Feature</div>

And then we inject the following providers:

templateRef - holds the reference to the template we want to show if the feature flag in question is turned on, i.e. the content of the element *appIfFeatureFlag is attached to.

If we removed the * symbol at the beginning of the directive's name we would get a No provider for TemplateRef found error. As you see, we don't specify anywhere in the @Directive decorator's metadata that this is a structural directive as opposed to attribute directive. Instead, the * symbol serves as syntactic sugar for us, wrapping the host element in the following construction:

<ng-template [appIfFeatureFlag]="'FEATURE_1'">
  <div>Feature</div>
</ng-template>

The dependencies directive injects are:

viewContainerRef - the container used to create embedded views withing the current host element
featureFlagService - the service exposing APIs to work with feature flags provider. We will shed some light on good practices when working with similar dependencies further in the article.

Since Angular 14 we get these providers without injecting them via the constructor with help of the inject function that now can be called during the component's construction phase.

Now let's implement the view creation logic:

  async ngOnInit() {
    try {
      const featureFlag = await this.featureFlagService.getFeatureFlag(this.appIfFeatureFlag);
      featureFlag ? this.onIf() : this.onElse();
    } catch (error) {
      this.onElse();
      // additional error handling logic goes here
    }
  }

  private onIf(): void {
    this.createView(this.templateRef);
  }

  private onElse(): void {
    if (!this.appIfFeatureFlagElse) {
      return;
    }

    this.createView(this.appIfFeatureFlagElse);
  }

  private createView(templateRef: TemplateRef<unknown>): void {
    this.viewContainerRef.createEmbeddedView(templateRef);
  }

What happens here is pretty straightforward. When the component is initialized, the directive fetches the feature flag's value and depending on the result calls either onIf method that creates the view of the provided templateRef or onElse method that checks if the fallback template was provided to create an alternative view.

The createView method just calls the relevant method of the viewContainerRef to create a view from the provided templateRef.

Preparing dependencies

For our feature flag directive to work we need a way to get the value of the feature flag. Let's create an interface FeatureFlagsService and an injection token FEATURE_FLAGS_SERVICE with this interface passed as a generic. The interface will contain a single method getFeatureFlag returning a Promise that should resolve to a boolean value.

export interface FeatureFlagsService {
  getFeatureFlag(flagName: string): Promise<boolean>;
}

export const FEATURE_FLAGS_SERVICE = new InjectionToken<FeatureFlagsService>('feature.flags.service');

Why not just create a FeatureFlagService?

We want our directive to depend on abstraction instead of implementation.

This allows us to easily use different FEATURE_FLAGS_SERVICE implementations behind this token depending on the context. For example, we might decide to switch to a different feature flags provider in the future or use a local stub service when using this directive in tests.

Directive in action

Let's test our directive in battle. For this demo purpose, we will use a stub for the FeatureFlagsService service implementation that will return true for FEATURE_1 and false for FEATURE_2:

const FEATURE_FLAGS_MOCK: Record<string, boolean> = {
  FEATURE_1: true,
  FEATURE_2: false
}

@Injectable({providedIn: 'root'})
export class FeatureFlagServiceMock implements FeatureFlagsService {
  public getFeatureFlag(featureFlag: string): Promise<boolean> {
    return Promise.resolve(FEATURE_FLAGS_MOCK[featureFlag]);
  }
}

Now let's import the directive. Since it's a standalone directive, we can import it both in Angular modules and in standalone entities.

  imports: [FeatureFlagDirective]

And use one in the template:

  <div *appIfFeatureFlag="'FEATURE_1'; else: defaultTemplate">Feature 1 template</div>
  <div *appIfFeatureFlag="'FEATURE_2'; else: defaultTemplate">Feature 2 template</div>
  <ng-template #defaultTemplate>Default template</ng-template>

This gives us the following result:

Feature 1 template
Default template

As you see, our conditional display logic becomes declarative and very concise.

Possible enhancements

The directive we built is deliberately simple. But depending on your application's needs you might want to support additional features like:

Flag values different from true/false, e.g. strings.
Sub-properties of feature flags (sometimes called feature variables in third-party services).
Reacting to appIfFeatureFlag changes instead of running the check once in ngOnInit lifecycle hook. It will make your directive more universal, allowing you to pass the feature flag's name dynamically if there is a use case for this.

Keep in mind that reasonable default values are your friends when adding additional options.

Links

You can find the complete version of the code by this link.

Read more about structural directives in the official docs.

Wrapping up

I hope that the practices described in this read and the results we achieved will motivate you to delegate more work to structural directives. If you haven't been doing that already in your Angular projects:)

Thanks for reading and see you in future articles!

Enrich your Javascript with simple functional programming techniques

Alexander Goncharuk — Thu, 18 Aug 2022 08:27:00 +0000

Being a multi-paradigm programming language, Javascript allows writing code in different styles. And while you probably don't want to mix OOP and functional approaches on the architectural level, there is no reason to limit the power of a multi-paradigm language on a smaller code unit level. Nonetheless, functional programming techniques are often ignored where they would fit nicely. In this article, I'd like to demonstrate how one of such simple techniques can make our code better.

Without further theoretical reasoning, here is what we are going to do:

Write a module that checks if all object fields pass the provided validation rules.
Start with the most straightforward imperative implementation and improve the code in a couple of steps.
Compare the results.

We will not do this just to demonstrate how different techniques can be used to solve the same problem. Our goal is to improve two very important metrics of clean code: re-usability and readability. This article covers the very basics, but I will provide some links at the end if you want to dive a little deeper into this topic.

Just make it work first

Assume our application allows users to publish new articles that will show up somewhere in the feed. Just like the one you are reading now. The shape of the article will be as simple as possible:

{
  title: String;
  tags: Array<String>;
  text: String;
}

On the server side before saving a new article in the database we have to validate if article fields conform to the following validation rules:

title is a string not shorter than 20 and not longer than 200 characters.
tags is an array of strings with at least one element in it.
text is a string not shorter than 200 characters and not longer than 100 000 characters.

Translated to code, the first and most naive definition of validator rules might look like this:

const rules = {
  title: value => typeof value === 'string' && value.length > 20 && value.length < 200,
  tags: value => Array.isArray(value) && value.length > 0,
  text: value => typeof value === 'string' && value.length > 200 && value < 100_000
}

(side note) Yes, you can use the _ symbol as a numeric separator in big numbers since ES2021 to improve readability. Just in case you don't do this yet:)

Now let's create the function that will iterate over the object's fields and validate each of those. Instead of just returning true or false to indicate if the object passed validation, we want the function to return an array of erroneous fields (if any) so we can provide some feedback to the client.

const getValidationErrors = (rules, objectToValidate) => {
  return Object.entries(rules).reduce((acc, [key, validatorFn]) => {
    const value = objectToValidate[key];
    if (!validatorFn(value)) {
      return [...acc, key];
    }
    return acc;
  }, []);
}

The validation algorithm is quite primitive:

Create an array of key-value pairs of the rules object where the key is the name of the field we are validating.
For each key-value pair get the relevant field's value and run the validator function provided for this field name in the rules. If validation fails, add the key name in question to the errors array.
Return the errors array (return value of the reduce function).

We would want more from this algorithm in a real-world application(validate inputs, handle errors), but for this demo purpose let's keep the shortest version.

Obvious refactoring

There are some drawbacks to this implementation that we can spot immediately. We will likely need to validate the same conditions in other places in our application. Extracting these validators into reusable functions exported from the validation utils module is an obvious improvement.

export const isString = (value) => {
  return typeof value === 'string' || value instanceof String;
}

export const isNonEmptyArray = (value) => {
  return Array.isArray(value) && value.length > 0;
}

export const lengthIsInRange = (value, min, max) => {
  return value.length > min && value.length < max;
}

No changes needed in the getValidationErrors function. But rules now look much better:

const rules = {
  title: isString(value) && lengthIsInRange(value, 30, 250),
  tags: isNonEmptyArray(value),
  text: isString(value) && lengthIsInRange(value, 0, 100_000)
}

Let's look at the code we have written so far and evaluate it:

Our code does its job, fields are being validated.
The getValidationErrors function is not too bad. It's concise and provides feedback.
Validators are defined as reusable functions, so our code is DRY enough.

Are we good to push the changes and open a PR? 👌

It's probably OK to do so at this point. But our code can be made better with very little effort. We are calling functions, but do not use good functional programming practices.

Currying to make it elegant

If you look at the code you will likely notice how we repeatedly write (value) calling each validator and apply the logical AND operator multiple times. When you see this, chances are high that these repeating parts can be abstracted.

In my validator rule, I'd like to just list validators separated by commas. Then inside getValidationErrors function, I will call each of these validator functions with the value to validate as a single parameter. It's easily doable for isString and isNonEmptyArray, but lengthIsInRange has two other parameters that we need to apply in advance before the function will be called along with other validators. This is where a simple concept of currying comes into play. Let's rewrite lengthIsInRange as a higher order function:

export const lengthIsInRange = (min, max) => {
  return (value) => value.length > min && value.length < max;
}

Here we prepare our validator by fixing min and max arguments beforehand in the lexical context of the outer function. This allows us to call the actual validator function later with only one argument: the object to validate. Which is exactly what we needed.

All we need to do the getValidationErrors function is to rename validatorFn to validators and change this line:

if (!validatorFn(value))

to:

if (!validators.every((rule) => rule(value)))

Here is the full version of the updated getValidationErrors:

const getValidationErrors = (rules, objectToValidate) => {
  return Object.entries(rules).reduce((acc, [key, validators]) => {
    const value = objectToValidate[key];
    if (!validators.every((rule) => rule(value))) {
      return [...acc, key];
    }
  }, []);
}

And our rules definitions will now look like this:

const rules = {
  title: [isString, lengthIsInRange(30, 250)],
  tags: [isNonEmptyArray],
  text: [isString, lengthIsInRange(200, 100_000)]
};

Compare this version to previous implementations. The goal we set at the beginning was to improve code re-usability and readability. I will leave it up to you to decide which version looks better from this point of view.

Bonus: function as a language first-class object

We probably don't want to run any additional validations if the field is optional and the value for this field is missing. We hence need a way to distinguish between required and optional fields. Let's create a separate validator in its simplest possible version for this purpose:

export const isDefined = (value) => {
  return value !== undefined;
}

And update our rules, making tags field optional:

const rules = {
  title: [isDefined, isString, lengthIsInRange(30, 250)],
  tags: [isNonEmptyArray],
  text: [isDefined, isString, lengthIsInRange(200, 100_000)]
};

Now in our getValidationErrors function, we can check if isDefined is among validators first and only then run the remaining validations, otherwise just proceed to the next field. How do I do this? As you know, functions are first class objects in Javascript, so I can check for function presence in an Array just like I would do for a string or a number:

if (!isDefined(value) && !validators.includes(isDefined)) {
  return acc;
}

Full version of revamped getValidationErrors:

const getValidationErrors = (rules, objectToValidate) => {
  return Object.entries(rules).reduce((acc, [key, validators]) => {
    const value = objectToValidate[key];
    if (!isDefined(value) && !validators.includes(isDefined)) {
      return acc;
    }
    if (!validators.every((rule) => rule(value))) {
      return [...acc, key];
    }
  }, []);
}

If the value is not defined and isDefined is not among validators the function returns early. Since it happens in the reduce context, don't forget to return the unchanged accumulator value. This way, we keep our rules definitions clean, avoiding the need of creating data structures like {required: true, validators: [...]}. 👏

Bear in mind this is not necessarily the way to go for every single task. You should always weigh the pros and cons and pick the right data structure for your requirements. But to make efficient choices it is paramount to be aware of the capabilities that language offers you.

Is `getValidationErrors` getting too messy?

It probably is. While the function body is still only 9 lines long and its readability is acceptable, the function is doing several things now. Since we are talking about functional programming techniques, let's turn getValidationErrors into a chain of operations applied to the rules object entries:

const getValidationErrors = (rules, objectToValidate) => {
  return Object.entries(rules)
    .map(([field, validators]) => ({
      field,
      validators,
      value: objectToValidate[field]
    }))
    .filter(shouldReportValidationError)
    .map(({field}) => field);
}

const shouldReportValidationError = (validationData) => {
  return shouldBeValidated(validationData) && !passesAllValidators(validationData);
}

const shouldBeValidated = ({validators, value}) => {
  const canSkipValidation = !isDefined(value) && !validators.includes(isDefined);
  return !canSkipValidation;
};

const passesAllValidators = ({validators, value}) => {
  return validators.every((rule) => rule(value));
};

A quick look at the getValidationErrors is enough now to understand it is doing the following things for every field:

Mapping the field's validation rules and value to a data structure for further processing.
Applying validation rules abstracted in shouldReportValidationError.
Mapping erroneous fields to the correct error format (just the name of the field in our case).

In a real-world scenario when the logic behind every step will likely be more complex, the value of such refactoring grows. We decomposed the logic in several steps and no longer mix array processing with imperative code on the getValidationErrors level.

Code examples

You can play around with code examples from this article in an online editor by this link. Just type node <file name>.js in the terminal to run the code.

Conclusion

Hope this article motivates you to leverage currying and other useful functional programming techniques in your Javascript code.

If you wish to learn more about functional techniques in Javascript I highly recommend this series of articles by Randy Coulman. In particular, the third article in the series explains the idea of currying or partial application in more detail.

Thanks for reading!

Wrap your library in a React hook

Alexander Goncharuk — Wed, 29 Jun 2022 09:36:23 +0000

This is the third and last article in a series on designing a Javascript library for different frameworks to use. In the first article in the series, we have built a vanilla TS/JS library for swipe detection in the browser. Although it can be used in your application built with any popular JS framework as is, we want to go a little further and make our library a first-class citizen when used in the framework of your choice.

In this article, we are going to wrap our swipe detection library in a React hook.

💡 The article implies you are familiar with the public interface of the swipe detection library used under the hood. If you haven't read the first article in the series, this section alone will be enough to follow along with the material of this one.

How should it work

We want to wrap the swipe detection functionality of the underlying library in a reusable React hook. Let's call one useSwipe as it is important to follow the hooks naming convention. This is how the hook will be used in a consumer component:

const swipeElement = useSwipe({
  onSwipeEnd: (event: SwipeEvent) => {
    console.log(`SwipeEnd direction: ${event.direction} and distance: ${event.distance}`);
  }
});

return <div ref={swipeElement}>Swipe me!</div>

Complete solution

The wrapper hook will be quite concise:

import { createSwipeSubscription, SwipeSubscriptionConfig } from 'ag-swipe-core';
import { RefCallback, useCallback } from 'react';
import { Subscription } from 'rxjs';

export const useSwipe = (config: Pick<SwipeSubscriptionConfig, 'onSwipeMove' | 'onSwipeEnd'>): RefCallback<HTMLElement> => {
  let swipeSubscription: Subscription | undefined;

  return useCallback((domElement: HTMLElement) => {
    if (domElement) {
      swipeSubscription = createSwipeSubscription({
        domElement,
        ...config
      });
    } else {
      swipeSubscription?.unsubscribe?.();
    }
  }, []);
}

What we want from the hook is:

get a reference to the DOM element the swipe listener should be attached.
react to one being mounted/unmounted to perform subscription and unsubscription tasks correspondingly.

Our first intention could be to use a combination of useRef and useEffect hooks, but what we actually need is a combination of ref and useCallback:

... the callback ref will be called only when the component mounts and unmounts

Couldn't ask for a better fit. If the domElement parameter value coming from ref is truthy i.e. component has been mounted, we call createSwipeSubscription with provided onSwipeMove and/or onSwipeEnd handlers. If the value is falsy i.e. the component has been unmounted, we use the swipeSubscription reference to unsubscribe.

To learn more on how ref and useCallback work together see this section in React documentation.

Wrapping up

You can find the complete library code on GitHub by this link.

And the npm package by this link.

That was it! We have built a simple React hook wrapper for our swipe detection library in 17 lines of code.

This article completes our short series. Thanks for reading and stay tuned!

Wrap your library in an Angular directive

Alexander Goncharuk — Wed, 29 Jun 2022 09:36:05 +0000

This is the second article in the series on designing a flexible JS library to be used in multiple frameworks.

In the first article in the series, we have built a vanilla TS/JS library for swipe detection in the browser. Although it can be used in your application built with any popular JS framework as is, we want to go a little further and make our library a first-class citizen when used in the framework of your choice.

In this article, we are going to wrap our swipe detection library in an Angular directive.

How should it work

When we need to detect swipes on an element in our Angular component, doing this should be as easy as attaching a dedicated attribute directive to the target element:

  <div ngSwipe (swipeEnd)="onSwipeEnd($event)">Swipe me!</div>

An attribute directive will be just enough here as we are not going to manipulate the DOM.

Getting access to the host element

Let's recall what our swipe subscription expects. According to the public interface of the underlying library, we should provide the following configuration:

export function createSwipeSubscription({
    domElement,
    onSwipeMove,
    onSwipeEnd
  }: SwipeSubscriptionConfig): Subscription {
// ...
}

So we need to get access to the host element our directive is attached to and pass one to the createSwipeSubscription function. This is a no-brainer type of task for our Angular component:

constructor(
  private elementRef: ElementRef
) {}

The nativeElement property of the injected elementRef holds the reference to the underlying native DOM element. So when creating a swipe subscription, we can use this reference to pass the target DOM element:

this.swipeSubscription = createSwipeSubscription({
  domElement: this.elementRef.nativeElement,
  //..
});

Complete solution

The rest of the directive code is pretty straightforward. Here is the complete solution:

import { Directive, ElementRef, EventEmitter, NgZone, OnDestroy, OnInit, Output } from '@angular/core';
import { Subscription } from 'rxjs';
import { createSwipeSubscription, SwipeEvent } from 'ag-swipe-core';

@Directive({
  selector: '[ngSwipe]'
})
export class SwipeDirective implements OnInit, OnDestroy {
  private swipeSubscription: Subscription | undefined;

  @Output() swipeMove: EventEmitter<SwipeEvent> = new EventEmitter<SwipeEvent>();
  @Output() swipeEnd: EventEmitter<SwipeEvent> = new EventEmitter<SwipeEvent>();

  constructor(
    private elementRef: ElementRef,
    private zone: NgZone
  ) {}

  ngOnInit() {
    this.zone.runOutsideAngular(() => {
      this.swipeSubscription = createSwipeSubscription({
        domElement: this.elementRef.nativeElement,
        onSwipeMove: (swipeMoveEvent: SwipeEvent) => this.swipeMove.emit(swipeMoveEvent),
        onSwipeEnd: (swipeEndEvent: SwipeEvent) => this.swipeEnd.emit(swipeEndEvent)
      });
    });
  }

  ngOnDestroy() {
    this.swipeSubscription?.unsubscribe?.();
  }
}

The directive does the following simple routine:

Gets the reference of the underlying DOM element.
Creates a swipe subscription with onSwipeMove and onSwipeEnd event handlers that emit to directive's Outputs whenever a relevant event occurs.
Unsubscribes when the ngOnDestroy hook is called (host component is being destroyed).

We also need to ship our directive in an Angular module that the consuming application will be importing:

@NgModule({
  imports: [CommonModule],
  declarations: [SwipeDirective],
  exports: [SwipeDirective]
})
export class SwipeModule {}

By the way, this is no longer the only option. We are just not hipster enough to use a cutting edge feature like standalone directives in a public library yet.

A couple of things worth mentioning

zone.runOutsideAngular()

You may have noticed we have one more provider injected:

private zone: NgZone

And later used to wrap the swipe subscription in zone.runOutsideAngular. This is a common practice of avoiding unnecessary change detection triggers on every tracked asynchronous event happening in the DOM. In our case, we don't want the change detection to be triggered excessively on every mousemove event.

Subscribing to both swipeMove and swipeEnd

The public interface of the ag-swipe-core library we used under the hood allows providing only one of two event handlers: onSwipeMove and onSwipeEnd. In the Angular wrapper though, we avoid additional input parameters and always handle both events and leave it up to the directive consumer to only listen to the Output it is interested in.

In this case, it is a conscious choice to prefer a simpler directive contract to possible performance optimization. I believe that simplicity should prevail over the optional optimization when it makes sense, but it is a subject for discussion of course.

Wrapping up

You can find the complete library code on GitHub by this link.

And the npm package by this link.

That was it! We have built a simple Angular directive wrapper for our swipe detection library in 30 lines of code. Spoiler alert: the React version will be shorter. 😄 But that's a whole different story for the next article.

Detect swipes with reactive programming

Alexander Goncharuk — Sat, 25 Jun 2022 13:25:37 +0000

In this article, we are going to build a library for swipe detection on touchscreen devices with help of a popular library RxJS that brings functional-reactive programming to the Javascript world. I would like to show you the power of reactive programming that provides the right tools to deal with event streams in a very elegant manner.

Please note this article implies that you are familiar with some basic concepts of RxJS like observables, subscriptions, and operators.

The library will be built in Typescript and will be framework-agnostic i.e. can be used in any Typescript/Javascript project. But we will follow some good practices to make it easy to use our library in framework-specific wrappers that we are going to create later.

Defining the public interface of the library

We will get to the reactive part soon enough. But first, let's address some general things we should take care of when designing a library.

A good starting point for building any library (or any reusable module in your codebase) is to define the public interface i.e. how our library is going to be used by consumers.

The library we are building will only detect simple swipe events. That means we are not going to handle multitouch interactions such as two-finger or three-finger gestures but only react to the first point of contact in touch events. You can read more about touch events WEB API in the docs.

Our library will expose only one public function: createSwipeSubscription. We want to attach the swipe listener to an HTML element and react to the following events emitted by the library

onSwipeMove - fires on every touch move event during the user swiping the element.
onSwipeEnd - fires when swipe ends.

The function will accept a configuration object with three parameters and return a Subscription instance:

export function createSwipeSubscription({
    domElement,
    onSwipeMove,
    onSwipeEnd
  }: SwipeSubscriptionConfig): Subscription {
    // ...
}

Where configuration object implements the following interface:

export interface SwipeSubscriptionConfig {
  domElement: HTMLElement;
  onSwipeMove?: (event: SwipeEvent) => void;
  onSwipeEnd?: (event: SwipeEvent) => void;
}

export interface SwipeEvent {
  direction: SwipeDirection;
  distance: number;
}

export enum SwipeDirection {
  X = 'x',
  Y = 'y'
}

And last but not least, as we are dealing with observables here, we have to think about the unsubscription logic. Whenever the swipe listener is no longer needed the subscription should be terminated. The right approach will be to delegate this action to the consumer of the library as the consumer will know when it is the right time to execute it. This is not part of the configuration object but is an important part of the public interface our library should expose. We will cover the unsubscription part in more detail in the dedicated section below.

Validating the user input

When the public interface of the library expects some input parameters to be passed from the library consumer side, we should treat those just like we would treat user input. Developers are library users after all, as well as human beings. 😄

That being said, at the very top of our createSwipeSubscription method we want to check two things:

Provided domElement should be a valid HTML element. Otherwise, we cannot attach any listeners to it.
At least one of the event handlers should be provided (onSwipeMove or onSwipeEnd or both). Otherwise, there is no point in swipe event detection if we don't report anything back.

if (!(domElement instanceof HTMLElement)) {
  throw new Error('Provided domElement should be instance of HTMLElement');
}

if ((typeof onSwipeMove !== 'function') && (typeof onSwipeEnd !== 'function')) {
  throw new Error('At least one of the following swipe event handler functions should be provided: onSwipeMove and/or onSwipeEnd');
}

Tracking touch events

Here are all four event types we need to track:

const touchStarts$: Observable<SwipeCoordinates> = fromEvent(domElement, 'touchstart').pipe(map(getTouchCoordinates));
const touchMoves$: Observable<SwipeCoordinates> = fromEvent(domElement, 'touchmove').pipe(map(getTouchCoordinates));
const touchEnds$: Observable<SwipeCoordinates> = fromEvent(domElement, 'touchend').pipe(map(getTouchCoordinates));
const touchCancels$: Observable<Event> = fromEvent(domElement, 'touchcancel');

RxJS provides a useful utility function fromEvent that works similar to the native addEventListener but returns an Observable instance which is exactly what we need.

We use the getTouchCoordinates helper function to transform touch events to the format we need:

function getTouchCoordinates(touchEvent: TouchEvent): SwipeCoordinates {
  return {
    x: touchEvent.changedTouches[0].clientX,
    y: touchEvent.changedTouches[0].clientY
  };
}

Since we are only interested in event coordinates, we pick clientX and clientY fields and discard the rest. Note we only care about the first touchpoint as stated earlier, so we ignore elements in the changedTouches array other than the first one.

Detecting the swipe start

Next we need to detect the start and the direction of the swipe:

const touchStartsWithDirection$: Observable<SwipeStartEvent> = touchStarts$.pipe(
  switchMap((touchStartEvent: SwipeCoordinates) => touchMoves$.pipe(
    elementAt(3),
    map((touchMoveEvent: SwipeCoordinates) => ({
        x: touchStartEvent.x,
        y: touchStartEvent.y,
        direction: getTouchDirection(touchStartEvent, touchMoveEvent)
      })
    ))
  )
);

The touchStartsWithDirection$ inner observable waits for the third consecutive touchmove event following the touchstart event. We do this to filter out accidental touches that we don't want to process. The third emission was picked experimentally as a reasonable threshold. If a new touchstart is emitted before the 3rd touchmove was received, the switchMap inner observable will start waiting for three consecutive touchmove events again.

When the third touchmove event is received, we map the initially recorded touchstart event to SwipeStartEvent form by taking the x and y coordinates of the original event and detecting the swipe direction with the following helper function:

function getTouchDirection(startCoordinates: SwipeCoordinates, moveCoordinates: SwipeCoordinates): SwipeDirection {
  const { x,y } = getTouchDistance(startCoordinates, moveCoordinates);
  return Math.abs(x) < Math.abs(y) ? SwipeDirection.Y : SwipeDirection.X;
}

We will use this object further to calculate swipe move and swipe end events properties.

Handling touch move and touch end events

Now we can subscribe to the touchStartsWithDirection$defined earlier to start tracking touchmove and touchend events:

return touchStartsWithDirection$.pipe(
  switchMap(touchStartEvent => touchMoves$.pipe(
    map(touchMoveEvent => getTouchDistance(touchStartEvent, touchMoveEvent)),
    tap((coordinates: SwipeCoordinates) => {
      if (typeof onSwipeMove !== 'function') {
        return;
      }
      onSwipeMove(getSwipeEvent(touchStartEvent, coordinates));
    }),
    takeUntil(touchEnds$.pipe(
      map(touchEndEvent => getTouchDistance(touchStartEvent, touchEndEvent)),
      tap((coordinates: SwipeCoordinates) => {
        if (typeof onSwipeEnd !== 'function') {
          return;
        }
        onSwipeEnd(getSwipeEvent(touchStartEvent, coordinates));
      })
    ))
  ))
).subscribe();

We utilize the switchMap operator again to start listening to touchmove events in an inner observable. If the onSwipeMove event handler has been provided, it gets called on every event emission.

Thanks to the takeUntil operator our observable only lives until the touchend event is received. When this happens, if the onSwipeEnd event handler has been provided, it gets called.

In both cases we use two helper functions:

getTouchDistance calculates the swipe distance comparing the processed event's coordinates with the touchStartEvent coordinates:

function getTouchDistance(startCoordinates: SwipeCoordinates, moveCoordinates: SwipeCoordinates): SwipeCoordinates {
  return {
    x: moveCoordinates.x - startCoordinates.x,
    y: moveCoordinates.y - startCoordinates.y
  };
}

and getSwipeEvent creates library output events containing the information about swipe direction and distance:

function getSwipeEvent(touchStartEvent: SwipeStartEvent, coordinates: SwipeCoordinates): SwipeEvent {
  return {
    direction: touchStartEvent.direction,
    distance: coordinates[touchStartEvent.direction]
  };
}

Handling edge cases

The touchend event is not the only event that can signalize touch move interruption. As the documentation states, the touchcancel event will be fired when:

one or more touch points have been disrupted in an implementation-specific manner (for example, too many touch points are created).

We want to be prepared for this. That means we need to create one more event listener to capture the touchcancel events:

And use it in our takeUntil subscription:

takeUntil(race(
  touchEnds$.pipe(
    map(touchEndEvent => getTouchDistance(touchStartEvent, touchEndEvent)),
    tap((coordinates: SwipeCoordinates) => {
      if (typeof onSwipeEnd !== 'function') {
        return;
      }
      onSwipeEnd(getSwipeEvent(touchStartEvent, coordinates));
    })
  ),
  touchCancels$
))

What happens here is we are creating a race with two participants: touchend and touchcancel. We utilize the RxJS race operator for this:

race returns an observable, that when subscribed to, subscribes to all source observables immediately. As soon as one of the source observables emits a value, the result unsubscribes from the other sources. The resulting observable will forward all notifications, including error and completion, from the "winning" source observable.

So whichever event fires first will win the race and terminate the inner touchmove subscription. In case it is touchcancel we don't need to emit the onSwipeEnd event as we consider the swipe to be interrupted and don't want to handle this as a successful swipe end.

Let's stop here for a second to give some credit to Rx. Out of the box we have the right operator to solve the problem in one line. 💪

Unsubscribing

As it was mentioned earlier, the consumer of our library should be able to unsubscribe from swipe event listeners when the subscription is no longer needed. For example, when the component's destroy hook is called.

We achieve this by returning the instance of RxJS Subscription that in its turn extends the Unsubscribable interface:

export interface Unsubscribable {
  unsubscribe(): void;
}

This way the consumer of the library will be able to hold the reference to the returned Subscription in a variable or a class property and call the unsubscribe method when it should be called.

We will make sure this happens automatically when creating framework-specific wrappers for our library.

Complete solution

You can find the complete library code on GitHub by this link.

And the npm package by this link.

Usage

Time to see the library in action. Why did we build one in the first place? 😄

import { createSwipeSubscription, SwipeEvent } from 'ag-swipe-core';

const domElement: HTMLElement = document.querySelector('#swipe-element');

const swipeSubscription = createSwipeSubscription({
  domElement,
  onSwipeEnd: (event: SwipeEvent) => {
    console.log(`SwipeEnd direction: ${event.direction} and distance: ${event.distance}`);
  },
});

If you want to track onSwipeMove as well, just add the corresponding handler function to the createSwipeSubscription configuration object.

And when swipe events should no longer be tracked:

swipeSubscription?.unsubscribe?.();

Online preview:

https://typescript-hey3oq.stackblitz.io

Live editor to play around with:

💡 Don't forget to choose the right device type in DevTools if opening on the desktop.

Conclusion

This article covered the core logic of the swipe detection library. We used some of the RxJS powers to implement it in a neat reactive manner.

In the next articles, we are going to create wrappers around the library to make it a first-class citizen in popular Javascript frameworks.

Hope this one was useful to you. Thanks for reading and stay tuned!

Things you want to know before localizing your app

Alexander Goncharuk — Sat, 04 Jun 2022 09:06:10 +0000

Original photo by Etienne Girardet

The task of translating texts on the screen to different languages may seem easy in comparison to product features development. Especially when the business estimates the effort. But the reality may be very different when you will start translating a big enough application that was not built with localization in mind from day one.

This article sheds some light on several important aspects of localization that are not necessarily obvious for those who deal with this for the first time. But at the same time are very important to take into account from the very beginning of this process.

Parts of the system that are subject to translation

If your system has already grown big enough there is a risk of underestimating the effort needed to translate every single text that the user can see on the screen. And this is our goal, otherwise, localization will look incomplete. Texts to be translated can come from:

HTML templates (most obvious)
Libraries used on the client-side, both internal and 3rd party (e.g. internal components library, 3rd party date picker library)
Server-side code (e.g. error and success messages, enums with string values)
Database (e.g. category names, menu items)

And then you can have internal libraries built with different technologies that will require a completely different approach for localization. And the same is true for microservices on the server-side.

Choose translation management platform carefully

The translation management platform is the place where you will upload all the texts in the source language and where professional translators will be translating them. This is the very basic function of the platform, but to automate your processes, you will likely need many other features from the platform, like:

integration with Git providers
import/export settings
translations QA
tasks automation
chat with translators
other features specific to your project

Don't underestimate the importance of choosing a good translation management platform. This will be one of the most impactful things defining the overall success of the product localization effort and the continuous localization process in the future.

I have a favorite among all available options that my company has chosen after comparing different vendors. I prefer to not mention the name here though as the article is not supposed to promote any services. If you are interested in my opinion, feel free to PM me (you can find contacts in my profile).

Glossary before everything

Regardless of how much in rush you are, you want to have a glossary before translators will start their work. It is paramount to make sure that terms critical for your business domain will always be translated correctly and consistently.

Do not plan translation agency selection as the last thing to be done when everything else is in place. Agency selection should happen in parallel with technical work. As soon as you have both the translation management platform and agency (or whoever will be doing the translation work for you) you are good to start glossary translation. The list of glossary terms can be prepared even before that by someone from your team.

Be prepared for language differences

Imagine the following sentence you can easily have in your application:

{{ timeInSeconds }} seconds ago

The most straightforward way to approach localization here would be providing only the seconds ago part to translators as we don't need to translate the number. That makes sense. But unfortunately, word order is not the same in all languages. For example in Spanish phrase 5 seconds ago will look like this:

Hace X segundos

Do you see the problem here? In Spanish ago is written in a verb form and it goes at the beginning of the sentence. Expecting word order in all languages to be the same is similar to testing the happy path scenario only. It will be
an impossible mission for the Spanish translator to translate it correctly unless you will:

choose a localization solution that supports placeholders (you likely will)
make sure you and your colleagues follow the best practice to provide full sentences in localization keys: {{ timeInSeconds }} seconds ago
make sure the translation management platform allows translators to move placeholders in translations

Provide translation context

If for whatever reason you can't provide the full sentence as suggested in the previous paragraph, make sure your localization solution supports providing additional context for translation keys. Assume we have the following pseudo-code snippet:

function getUploadProgressMessage(percents) {
  return __('You file is being uploaded: ') + percents + '%' + __('left');
}

Where __() is the function responsible for marking text as translatable. This function will look for the translation(say for the German version) in a JSON file that might look like this:

{
 "Your file is being uploaded": "Ihre Datei wird hochgeladen",
 "left": "?"
}

For you, as a developer, it's clear what is the meaning of the word left here. But a professional translator who will encounter this word as a separate translation key somewhere in the translation management platform will likely have no clue in which context left is used here. Is it a noun or a verb? Could be left for later, could be just a standalone left.

In cases like this translator will ask for context first to translate the word correctly. If you don't have a way to provide the context in advance, you will doom developers or a localization manager (often both) to never-ending Q&A sessions with translators as new translatable content is being pushed all the time. To avoid this, your translation tools should support providing context, for code example above it could look like this:

__('left', 'Full sentence: Your file is being uploaded: 30% left');

And translation file for the German language could look like this:

[
 {
   source: "left",
   target: "",
   comment: "Full sentence: Your file is being uploaded: 30% left"
 }
]

Note this is just pseudo-code using JSON format for simplicity. Whatever format you choose, make sure your translation management platform will display these comments and they will be treated by translators as comments. Pay attention to standards like XLIFF that are supported by most translation management platforms and can be used if supported by your localization tooling.

Do not agree on routine work before you have explored all the options available to automate the process

When you have an existing application that has been developed for several years and should be now localized, expect a lot of routine work. Regardless of what technology stack is used in your project, there is a high chance that someone has already faced this challenge before and created tools to reduce the burden of routine work. It's mostly about your time that can be spent more efficiently but also about the chances of missing something out in the code. You might be interested in code analysis tools that can automate the following things:

Finding all strings that look like translatable content
Marking these texts for translation

For HTML content it is possible. Concrete implementation depends on the frameworks and libraries used. For other types of files, some patterns can point to the fact this string looks like translatable text, e.g. string is starting with a capital letter, no underscores used, etc.

Trust and verify

This is an important addition to the previous advice. You likely don't want to rely on automation completely. Applications are very different and there is no "silver bullet" type of tool that can take everything into account. Just to give you an example: in the world of SPA in your HTML templates, you likely have some attributes that should be translated e.g. placeholders and some custom attributes that have special meaning in the context of your project and should not be translated.

Let the automation tools find and mark texts for you and then verify the results and correct them where necessary before committing the changes.

Continuous localization

This is an existing term that makes a lot of sense. Just like with any other task that should run on every change (unit and e2e tests, code smell checks, etc.) you want to automate your localization processes.

Concrete tasks to be automated will depend on your localization workflow. But here are some examples of tasks you will likely want to automate:

Pushing new translation keys to the translation management platform
Pulling the latest translation files from the translation management platform

And if your chosen localization tools allow automating this as well:

Extracting new translation keys from the application source code

Make sure your company on is the same page as you

Unlike other changes in software products, localization is not something you implement once and it just works from now on without any attention needed. New pages, tabs, and forms will be created in your Web application all the time, bringing new texts. Existing text wording will change as well. That means, when you are done marking existing texts for translation, you need to make sure the following will be true:

Everyone in the company is aware of the fact that your product supports multiple languages from now on and marking new texts for localization is everyone's responsibility.
Translation keys extraction, upload, and download processes are automated as much as possible.

Here are some tips (quite obvious, but still) that can help you achieve this:

Document all the processes.
Communicate it the right way. Probably you will need to do this multiple times.
Do your best to make it impossible to commit code that contains new texts that are not marked for localization. Linting tools can help to achieve this.

Conclusion

I hope this article will help you to estimate the effort needed to localize your application properly. Not necessarily all of the tips above apply to your project. But most of them are very generic and hopefully can save you and your colleagues some time.

If you have any questions feel free to ask here in the comments or reach out to me directly on the social platforms you will find in my profile.

DEV Community: Alexander Goncharuk

11 friends of state management in Angular

Intro

Rule 1: Use dedicated tools for state management

Rule 2: Always prefer local state unless you have a good reason to use global state

Rule 3: Limit component code by view-related logic only

Cases when the state belongs to the component

Small presentational components and simple UI controls

Data aggregation is very specific to this component use case only

Other use cases

Rule 4: Always separate stateful and stateless services

Rule 5: Access state synchronously when it makes sense

Rule 6: Do not create "proxy methods" for no good reason

Rule 7: Prefer less verbose APIs whenever possible

Rule 8: Remember about multicasting observables returned by selectors

Rule 9: Use state management APIs, but do not limit yourself to it

Rule 10: Embrace pure functions and static methods

Rule 11: Make sure you handle errors in effects

Conclusion

You don't want a BaseComponent in your app

Why BaseComponent even exists

What is wrong with BaseComponent

It breaks the meaning of inheritance

You don't get to choose what to inherit

Makes it easy to shoot yourself in the foot by rewriting lifecycle hooks

Creates stronger coupling in the app

Passing constructor arguments every time

Alternatives

View providers

Directives of different kinds

Pipes

Decorators

Resolvers

Typescript and Javascript at your disposal

Wrapping up

A better feature flag directive in Angular

How is this one better

Why feature flag use case

Implementation

Preparing dependencies

Directive in action

Possible enhancements

Links

Wrapping up

Enrich your Javascript with simple functional programming techniques

Just make it work first

Obvious refactoring

Currying to make it elegant

Bonus: function as a language first-class object

Is getValidationErrors getting too messy?

Code examples

Conclusion

Wrap your library in a React hook

How should it work

Complete solution

Wrapping up

Wrap your library in an Angular directive

How should it work

Getting access to the host element

Complete solution

A couple of things worth mentioning

zone.runOutsideAngular()

Subscribing to both swipeMove and swipeEnd

Wrapping up

Detect swipes with reactive programming

Defining the public interface of the library

Validating the user input

Tracking touch events

Detecting the swipe start

Handling touch move and touch end events

Handling edge cases

Unsubscribing

Complete solution

Usage

Conclusion

Things you want to know before localizing your app

Parts of the system that are subject to translation

Choose translation management platform carefully

Glossary before everything

Be prepared for language differences

Is `getValidationErrors` getting too messy?