Forem: Morgan Worrell

Advanced NgRx: Building a Reusable Feature Store

Morgan Worrell — Wed, 04 Aug 2021 19:03:40 +0000

As an angular application grows in scale and complexity, so often is the need for state management to help simplify its many moving parts. What often occurs is an increase in the amount of boilerplate involved in managing many feature states, and stores.

Increase in store size can often lead to repetitive patterns, much like in poor component design. However, if state is written well, an application can utilize a less common pattern- a reusable feature store- as we attempt to eliminate much of this boilerplate headache.

The following proposes a pattern where we’ll create a pattern for properly consolidating several stores, gain consistency across similar features with a reusable store, and address any pitfalls in this pattern.

When to use consolidating state management patterns

Before we get too deep into consolidating, we should first stop, and assess, when and why we're attempting this task.

Why consolidate in the first place?

Reduce repeating patterns in feature design.
Increased maintainability of similar features.
Quicker iterations.
A better shared abstracted layer that can be extended as needed for edge cases.
Similar or extensible UI or data stores.

When should you consider consolidating?

A hard to answer question, but one that's satisfied by having really good foresight, a roadmap of how an app's features will work, or a set of existing features that may need a few iterations to bring them closer in overall design.

What this means for both approaches is that a feature can be initially designed similarly to another, or be made to function similar to another to make it DRY-er (Don't Repeat Yourself) later on.

A closer look at the store pattern

Now that there's a direction and reason for our efforts, let's look at the pattern using a mock version of photo website - Unsplash - to build out a data store.

Let's say we have several states that look like this:

export interface WallpapersState {
    photos: Photo[];
    isLoading: boolean;
}

export interface PeopleState extends Photo {
    photos: Photo[];
    isLoading: boolean;
}
...
// rest of states for remaining photo types

Fortunately for us, our photo assets follow a very similar pattern. This state is simple as it will contain photos in a simple state. However, we can squash these into one state like this:

export interface PhotoState {
  photos: Photo[];
  isLoaded: boolean;
  isLoading: boolean;
}

export interface PhotoTypeState {
  [assetType: string]: PhotoState;
}

And with that simple bit of code, we've opened up the possibility to reuse a data store per photo type into a single store!

For example, a website like Unsplash could use several strategies to fetch and display photos like filtering by photo type on navigation, or pre-fetching chunks of photo types in a resolver. Imagine if each photo type acted as an individual store? That would be a lot of stores to maintain!

Building the new state and reducer

As this new feature store is built, keep in mind that typings become tricky when you begin to use an indexed interface as a type.

Typing pitfalls

Typescript doesn't like when we add more properties onto indexed interfaces because it assumes that we'd only be adding properties that follow the initial type we assigned to the index property. In this case Photo[].

For example, this will work:

export interface PhotoTypeState {
  [assetType: string]: PhotoState;
}

But this won't, because PhotoType on selectedPhotoType doesn't overlap in types:

export interface PhotoTypeState {
  selectedPhotoType: PhotoType; // for selecting the right photo store
  [assetType: string]: PhotoState;
}

To overcome this, we can use an Intersection Type like so:

export interface PhotoTypesState {
  [photoType: string]: PhotoState;
}

export type State = PhotoTypesState & {
  selectedPhotoType: PhotoType;
};

Defining the reusable part of state

We want some amount of flexibility in our store, but we have to tell the new store what features we intend to keep similar in pattern. One way we could do this is by creating a dictionary of features. Building the initial state for the photo types could look like:

// Dictionary referencing the phtoto types as features
export enum PhotoType {
  Promos = "Promos",
  Wallpapers = "Wallpapers",
  People = "People",
  Nature = "Nature",
  Architecture = "Architecture",
  Misc = "Misc",
}

// Initial state for each photo type
export const INITIAL_PHOTO_TYPE_STATES: PhotoTypeState = Object.keys(
  PhotoType
).reduce((acc, val) => {
  acc[PhotoType[val]] = [];
  return acc;
}, {});

And initial state for the reducer:

/**
 * Initialize the default photo type.
 *
 * NOTE: we have to assign an initial value in this
 * example's load strategy so our selector doesn't read
 * the state as `undefined`.
 *
 * Because we used an indexed type, we would have to
 * force type properties to `any` to avoid type conflicts.
 *
 * To get around an initial value and use `null`, change
 * your load to one that makes sense for you app.
 */
export const INITIAL_PHOTOS_STATE: PhotosState = {
  selectedPhotoType: PhotoType.Promos as any,
  ...INITIAL_PHOTO_TYPE_STATES,
};

Another win for reusable store pattern

Maybe you noticed already, but what if each of the individual states used entities? We could help ourselves, and speed up our dev time some more with the adapter methods and selectors exposed per PhotoType. Our biggest win here comes from the fact that we can still use NgRx Entities even in these seemingly nested states of state. The above piece changes like so:

    export interface PhotoEntitiesState extends EntityState<PhotoState> {
        // additional entity state properties
    }

    export interface PhotoTypeEntitiesState {
        [photoType: string]: PhotoEntitiesState;
    }
    ...
    const adapter: EntityAdapter<PhotoState> = createEntityAdapter<PhotoState>({
        // additional entity state properties
    });

And give the state slices an initial state:

export const INITIAL_PHOTO_TYPE_STATES: PhotoTypeState = Object.keys(
  PhotoType
).reduce((acc, val) => {
  acc[PhotoType[val]] = adapter.getInitialState({});
  return acc;
}, {});

Tying it together with the reducer and selectors

Now that we have the state accurately defined. We can access the select slices of our single store using the selectedPhotoType property:

export const photosReducer = createReducer(
  INITIAL_PHOTOS_STATE,
  on(PhotoActions.loadPhotoSuccess, (state, { photos }) => ({
    ...state,
    [state.selectedPhotoType]: {
      ...state[state.selectedPhotoType],
      photos,
    },
  }))
);

And for the selectors:

export const photosState = createFeatureSelector("photos");

export const selectActivePhotoTypeState = createSelector(
  photosState,
  (state) => state[state.selectedPhotoType]
);

export const selectAllPhotos = createSelector(
  selectActivePhotoTypeState,
  (state) => state.photos
);

Again, we can use the entity adapter and leverage entity methods and selectors. Full Code Example Here.

Conclusion

When working with state management stores in NgRx, it shouldn't be a mess of maintaining boilerplates and changes that affect several data sources with the same store shape. As developers, we want to think of future-proofing strategies that abstract enough, yet still help us understand exactly how the application works.
By leveraging a reusable store strategy, we gain consistency with like features, a level of abstraction and sharability between like features, with the ability to extend for edge cases, and easier maintenance.

This Dot Labs is a modern web consultancy focused on helping companies realize their digital transformation efforts. For expert architectural guidance, training, or consulting in React, Angular, Vue, Web Components, GraphQL, Node, Bazel, or Polymer, visit thisdotlabs.com.

This Dot Media is focused on creating an inclusive and educational web for all. We keep you up to date with advancements in the modern web through events, podcasts, and free content. To learn, visit thisdot.co.

Introduction to Redux Pattern

Morgan Worrell — Tue, 19 Jan 2021 18:38:57 +0000

Introduction to Redux Pattern

In this overview of the Redux Pattern, we'll dig into the basics and answer these pressing questions:

What is the Redux?
Why do we use the Redux?
When do we use the Redux?

Redux patterns in applications created in React or Angular are very handy tools in helping define state and managing active and passive events.

What is the Redux Pattern?

Redux is a pattern and library for managing and updating application state, using events called "actions". - Redux Documentation

Not only is redux great for defining events, it also guides the flow of events through predictable event tracking.

What Redux Pattern is not

Redux and Redux patterns are not to be confused with Flux patterns or Flux architecture. The main difference between these two patterns is the "single source of truth" concept.

Stores are our single sources of truth containing the state of our application. In Flux, the store can be split and defined in multiple locations throughout the application.

Redux as a single source of truth means that we can better maintain and improve our applications by merging state and events into a single location. This single location feeding the application is one of the key considerations developing for the architecture and scalability of an application.

Why do we use the Redux Pattern?

...Redux makes it easier to understand when, where, why, and how the state in your application is being updated, and how your application logic will behave when those changes occur. - Redux Documentation

While Redux's use is simple for managing a "global" or "single source" level of state, there are some other impacting benefits:

Predictability of Events.

When we know what event will happen next if we click a button or link, we take away all assumptions about events triggering other events.

Better Debugging from Event Tracing.

Personally, event tracing is one of the huge benefits I like about state management because defects in events can be pinpointed accurately. If state wasn't updated correctly, we can make better logical assumptions.

Complex State Change

State is the one thing we can rely on and sometimes this state can receive asynchronous updates from different events. Redux makes these updates easier to manage.

When do we use the Redux Pattern?

Ideally, Redux should be used for parts of an application that share state.

Here are a few other considerations when deciding to use the Redux pattern.

Frequency of State Changes

State can be small or large, simple or complex, but in every case where events are performed, state will always be updated.

Application Scalability

First, we need to predict how an application will grow in size from the number of features. As an application scales from a simple set of functions to an enterprise-level experience, duplicated code and events decrease performance.

Additionally, a Single Page Application (SPA) benefits greatly from Redux. For example, event-based routing behaves differently from a "regular" website since we conditionally generate new pages. As the SPA increases in features or pages, so does its need for state management.

Complexity of State Changes and Logic

Sometimes application state complexity increases as the application scales. Technical debt takes on a different form when the state isn't properly managed. Red, Green, Refactor is a simple, effective strategy to help minimise state technical debt - debt cause from a lack of code hygiene.

In Red, Green, Refactor we identify what needs to change, determine how we make the change, then execute the change. In the case for state, we can merge similar portions of state together or split apart state by feature or function, making it easier to access parts of state. Likewise, any logic that relies on combined or nested state should be updated as you make those changes.

How to Start Using Redux Today

While this is an introduction to using Redux, it's helpful to note where we can start to add it in our projects.

File Structure

First, we defined a store location. We can choose to have this live on the same directory level as our other components and services:

    src
    |- components
    |- services
    |- ...
    |- store
        |- actions
        |- reducers
        |- ...

React

Next, we can utilise state management. For vanilla JavaScript apps, we can use Redux as is, but there is special version of it created for React applications called React-Redux. The main difference here is the React integration:

    import ReactDOM from "react-dom";
    import ReactDOM from "react-dom";
    ...
    import { Provider } from "react-redux"; // needed to supply store to app
    import store from "./redux/store"; // your implementation of the store

    import TodoApp from "./TodoApp";

    const rootElement = document.getElementById("root");
    ReactDOM.render(
      <Provider store={store}> // now the app has access to our store
      <TodoApp />
      </Provider>,
      rootElement
    );

Angular

Similarly for the popular Angular framework, we have NgRx, a version of Redux created specifically for Angular.

    import { BrowserModule } from '@angular/platform-browser';
    import { NgModule } from '@angular/core';

    import { AppComponent } from './app.component';

    import { StoreModule } from '@ngrx/store'; // needed to supply store to app
    import { todoReducer } from './store/to-do.reducer'; // your implementation of the store

    @NgModule({
      declarations: [AppComponent],
      imports: [BrowserModule, StoreModule.forRoot({ todo: todoReducer })],
      providers: [],
      bootstrap: [AppComponent],
    })
    export class AppModule {}

You can choose your own adventure with state management. Choose wisely!

Closing Thoughts

Talking about the glories of Redux comes with its cons as well. Keep in mind that using Redux also means defining a state that can become overly complex and require more overhead for Red-Green Refactoring. The benefits far outweigh this cost, however.

The key things to remember about Redux is that it's meant to define a predictable set of events, manage and share application state in a single source of truth, and should be used when a project becomes large and complex.