DEV Community: Akshay Mahajan

Easy state management in Angular

Akshay Mahajan — Thu, 21 Apr 2022 14:10:07 +0000

Angular provides useful feature of services where we encapsulates all our Business Logic (BL) [back-end integration] inside the services. BL does includes persistence of state/data that would probably be meant for other components too. With increased components hierarchy, we tend to increase services that are associated with them which leads to application getting bloated and data communication between services and counter components gets messy.

To fix this problem, we need opinionated state management and vast majority of solutions are already available in OSS market like NgRx, Ngxs, Akita, Elf, RxAngular etc. But this solution comes with a cost which is their associated learning curve and boilerplate code just to have its initial setup hooked into our application.

To reduce this pain and get your system ready up (bare metal) and setup-ed in less time frame, I have created a dead simple state management solution in just less than 50 lines of code.

Yes, you hear it right, its just less than 50 lines of code. 😉

I'm not gonna say that this is a full fledged state management solution that advanced libraries does. This is a bare metal need of state management which can suffice a need of many developers in their day to day task. For obvious reason when your task and need is more complex, one should consider using an opinionated state management libraries as stated above since they are tested well within the community and are scale-able enough.

So the basic fundamental of state management is to cache recurring data which is to be passed along a lot of component hierarchy. Input/Props drilling is one the issue where state management methodology like flux comes to resort. A central global store that will act as hydration of data to our components and probably act as single source to truth for many entities in your application.

So certain check list needs to be considered when implementing state management that is refer below.

✅ Central store for most of the entities (single source of truth).
✅ The store should be reactive (pushing instead of polling. Polling can be additional feature too).
✅ Select a certain slice of cached data.
✅ Update/Destroy the cached entity.
✅ No mutation for cached entity outside of reducer.

The state management solution that I'm gonna present is CRUD based. And this is gonna suffice 70-80% of use cases.

The syntax for function wrapper is gonna remind you of slice from Redux Toolkit.

Create a wrapper function

We are going to create a wrapper function that will help with the initial implementation of slice.

export function createSlice(opts) {
}

Setting up Initial Data (🇨RUD)

This is the phase where we are going to create a slice with the initial state/data.

Typings for createSlice Options would look like:

export type CreateSliceOptions<T> = {
  initialValue: T;
};

Using this type inside the function wrapper.

export function createSlice<T>(opts: CreateSliceOptions<T>) {
  let _value = opts.initalValue;
}

Reading the value from inside the slice (C🇷UD)

We need to expose a function from inside the createSlice wrapper that will fetch us the current state inside the slice.

Typings for createSlice Instance would look like:

export type CreateSliceInstance<T> = {
  ...
 /**
  * Returns the current value of slice
  */
  getValue: () => T;
  ...
}

Using this type inside the function wrapper.

  return {
    ...,
    getValue: () => _value;
  }

Updating the data inside of slice (CR🇺D)

In order to update the slice, we will expose a method called update that will update the value inside the slice.

Let's add the update typing to the CreateSliceInstance.

export type CreateSliceInstance<T> = {
  ...
 /**
  * Callback to update the value inside the slice.
  */
  update: (state: Partial<T>) => void;
  ...
}

Implementing the update method in the slice wrapper.

  return {
    ...,
    update: (state: Partial<T>) => {
      _value = state;
    }
  }

How come this approach would be reactive? How would I subscribe to the changes I performed via update method?

In order to make our slice reactive, we need to re-adjust some implementation inside the createSlice wrapper, but although the typings will remain same.

NOTE: For now, the implementation only supports objects, and not primitive like string, number, boolean etc.

function createSlice<T>(opt: CreateSliceOptions<T>): CreateSliceType<T> {
  let _ob$ = new BehaviorSubject<T>(null);
  let _value = new Proxy(opt.initialValue ?? {}, {
    set: (target, property, value, receiver) => {
      const allow = Reflect.set(target, property, value, receiver);
      _ob$.next(target as T);
      return allow;
    },
  });
  return {
    valueChanges: _ob$.asObservable().pipe(debounceTime(100)),
    getValue: () => _ob$.getValue(),
    update: (state: Partial<T>) => {
      Object.keys(_value).forEach(key => {
        if (state.hasOwnProperty(key)) {
          _value[key] = state[key];
        }
      });
    },
  }
}

WOW, there are a lot of changes. Let's discuss them step-by-step:

We have created a BehaviorSubject that will emit the value inside it whenever we trigger next on it.
Instead of assigning initalValue directly to _value, we will create a new Proxy object, where we will override various handler methods on the target object. To read more about Proxy Pattern, refer this.
We will override the set method of the target object i.e. initialValue and will emit an new value, whenever a target is mutated.
For the update method, we will iterate over to the properties of the supplied state as param to update method and check if the property key in the state belongs to initialValue object and updating the _value[key]. The usage of hasOwnProperty will help us eradicate any miscellaneous (unknown) property from the slice's state.
We have use debounceTime in order to aggregate (iteration inside the update method) the changes in a certain time frame i.e. 100ms and will emit the target finally.

I hope this all makes sense to you all till now.

Deleting/Destroying the value inside the slice (CRU🇩)

When the slice is no longer in need, we can simply destroy the slice by calling the destroy on it.

Typing and implementation for destroy would be like:

   ...
   /**
   * Destroy the slice and closure data associated with it
   */
  destroy: () => void;
   ...

return {
   ...,
   destroy: () => {
      _ob$.complete();
      // In case the target reference is used somewhere, we will clear it.
      _ob$.next(undefined);
      // Free up internal closure memory
      _value = undefined;
      _ob$ = undefined;
    },
   ...
}

Resetting the slice's state (with intialValue)

There might be possibility where you might want to reset the state inside the slice.

Typings and implementation of reset would be like:

  ...
  /**
   * Reset the data with initial value
   */
  reset: () => void;
  ...

return {
  ...,
  reset: () => {
      const {initialValue} = opt;
      Object.keys(initialValue).forEach(key => {
        _value[key] = initialValue[key];
      });
   },
  ...
}

Complete Implementation

BONUS

If we see the implementation properly, the mutation can be possible via fetching target value from either getValue or valueChanges observable subscription. Although the mutation should not be happening outside the reducer (i.e. inside the slice context only).

We can fix this behaviour by wrapping the value inside the Object.freeze(target). Here is the revised implementation for getValue and valueChanges respectively.

return {
  ...,
  valueChanges: _ob$.asObservable().pipe(
      debounceTime(100),
      map(value => Object.freeze(value)),
  ),
  getValue: () => Object.freeze(_ob$.getValue()),
  ...
}

Final thoughts

Thanks you for staying till here. You probably have learned something new today and that's a better version of you from yesterday's.
If you like this article, do give it a like or bookmark it for future reference. And if you feel there's need for some improvisation, do let me know in the comments. Would love to learn together.

Easily consume back-end API's in Angular 4x faster!

Akshay Mahajan — Tue, 01 Mar 2022 19:48:07 +0000

Angular is the web framework of choice for many professional developers. The future development roadmap for angular seems promising and will prevail increasingly high demand in coming years. This is the reason why I'm heavily invested in the angular ecosystem.

I work as full-stack web developer and developing a feature for the product is highly intensive task and require working on front-end and back-end simultaneously.

Actual Problem

Working on back-end with ORM hooks is easy when either its plain old CRUD or with extended Business Logic (BL). But when it comes to consuming API's on front-end, this can be tedious task to write every single API for the back-end. We sure can implement abstract BaseHttpAPIService and extend it to our services, but support for params, pathParams, transformer/adapter and many other can be tedious and require much planning and can prove to be a a lot of boilerplate.

So how do I do it the efficient way?

Well, I have come up with a solution which did helped me in consuming the API's 4x faster. The number quantified over here may differ for other's but it surely proved to be right for me.

The solution is based on Repository pattern with the help of Entity model.

Let me show you how I did it.

Create a Model

I know many of you usually declares model in your project and are on the same page as like me. But still, I would like to show you with some code snippets.

Annotate the Model with @Entity decorator

Just a bare simple @Entity decorator which will have just 1 property (for now) as path that corresponds to the back-end relative path like /users.

Redeem a token for User Repository Service

We injected (via DI) the User Repository Service like we normally do in Angular constructor.

You must be thinking from where the @Entity decorator, RepoToken and Repository came from; Right? Just stay with me, this is going to get excited.

Consuming the API in an efficient manner

Since now we have injected the service, we can access the methods of the repository which sounds like findAll, findOne, createOne etc.

Shut-up and tell me how to use it now!

Hahahah! Okay! You wanted to know how I did it. I created a library that can help you in doing all this and even more with configurations.

I have curated 😎 the ngx-crudx library to solve the huddle of consuming the API in angular. Go checkout the library. Below are the list of features currently supported:

Features

Single codebase, yet different Repository for entity. Hence, DRY followed. 😃
Annotate Entity model with @Entity decorator to add extra metadata.
Add support for Custom Repository.
Support for multiple micro-services (URL bindings) as multiple connections.
Ability to transform (Adapter) body and/or response payload on the fly with easy configuration.
Engineered an interceptor for query params (both at entity level and as well as individual route level).
Produced code is performant, flexible, clean and maintainable.
Follows all possible best practices.

Final Thoughts

The ngx-crudx is amazingly powerful and configurable. If you like the library, give it a star ⭐ which keeps me motivated to build great stuff. If you want to contribute or find any typo/bug, raise an Issue and lets discuss about it.

Github repository: https://github.com/androizer/ngx-crudx
NPM Package: https://www.npmjs.com/package/ngx-crudx