How to Build a Clean Redux Architecture With Redux-Observable and Typescript

SamuelRafini — Wed, 18 Nov 2020 07:56:49 +0000

How to Build a Clean Redux Architecture With Redux-Observable and Typescript

Easily create completely typesafe actions with less boilerplate and completely typesafe Reducers.

To be honest I used to hate Redux but my perspective changed quickly as soon as I had to work with large complicated codebases. Redux is amazing for that and once you have experience with such, you’ll appreciate it. In this article, I’m going to show you how I setup redux with redux-observables (also works with other middlewares like redux-saga ) and typesafe-actions to be clean and scalable.

Folder structure

The folder structure is pretty straightforward. Inside my src folder, I’ve added several folders:

components
pages
utils reusable fetch function and localstorage function
services with an http folder for my requests
redux well for redux 😆, notice I’m using the ducks architecture

Basically, in ducks architecture, you have a separate folder per domain or feature containing actions, epics/sagas, reducers, and selectors files.

On the official documentation of Redux they strongly recommend Structure Files as Feature Folders or Ducks

they strongly recommend Structure Files as Feature Folders or Ducks

In this example, I will create a simple application where you can search for NBA players and sort by name. I’m receiving data from www.balldontlie.io API.

Git Repo

📁 test-app/
┣ 📁 public/
┣ 📁 src/
┃ ┣ 📁 components/
┃ ┣ 📁 pages/
┃ ┣ 📁 redux/
┃ ┃ ┣ 📁 player/
┃ ┃ ┃ ┣ 📄 actions.ts
┃ ┃ ┃ ┣ 📄 epics.ts
┃ ┃ ┃ ┣ 📄 reducers.ts
┃ ┃ ┃ ┗ 📄 selectors.ts
┃ ┃ ┣ 📄 rootAction.ts
┃ ┃ ┣ 📄 rootEpic.ts
┃ ┃ ┣ 📄 rootReducer.ts
┃ ┃ ┣ 📄 store.ts
┃ ┃ ┗ 📄 utils.ts
┃ ┣ 📁 services/
┃ ┃ ┗ 📁 http/
┃ ┃   ┗ 📄 nbaRequests.ts
┃ ┣ 📁 utils/
┃ ┃ ┣ 📄 fetchApi.ts
┃ ┃ ┗ 📄 localstorage.ts
┃ ┣ App.tsx
┃ ┣ 📄 index.tsx
┃ ┣ 📄 interfaces.ts
┃ ┣ 📄 react-app-env.d.ts
┣ 📄 package.json
┗ 📄 tsconfig.json

Actions Setup

We create a simple fetch player’s actions inside players. Players, in this case, is the domain/feature of this application.

import { createAction } from 'typesafe-actions';
import { FetchPlayersRequest, Player, PaginationMeta, ErrorResponse } from '../../interfaces';

export const getPlayers = createAction("GET_PLAYERS")<FetchPlayersRequest>();
export const getPlayersSuccess = createAction("GET_PLAYERS_SUCCESS")<{data: Player[]; meta: PaginationMeta}>();
export const getPlayersFailed = createAction("GET_PLAYERS_FAILED")<ErrorResponse>();

Notice how createAction from Typesafe-actions helps us to reduce types verbosity. So basically getPlayersSuccess returns an action with an object of dataPlayer and meta as payload. for example

const getName = createAction("GET_FULL_NAME")<{firstName: string; lastName: string}>();

getName({firstname: "Samuel", lastName: "Rafini"}); // {type: "GET_FULL_NAME", payload: {firstName: 'Samuel', lastName: 'Rafini'}}

In the root of the redux folder, we then add rootAction.ts file with the following, so we can join actions from other features/domains.

import * as playerActions from './player/actions';

export default {
    player: playerActions,
};

Before going any further we can extend and add types of typesafe-actions like so

import { StateType, ActionType } from 'typesafe-actions';

/// <reference types="react-scripts" />

declare module 'typesafe-actions' {
  export type Store = StateType<typeof import('./redux/store').default>;

  export type RootState = StateType<typeof import('./redux/rootReducer').default>;

  export type RootAction = ActionType<typeof import('./redux/rootAction').default>;

  interface Types {
    RootAction: RootAction;
  }
}

Reducers Setup

the Reducer is also straightforward. for our player state, we create a PlayerState interface and an initial state, then we use createRudecer from Typesafe-actions which helps us write our reducers without the switch case statement.

import { createReducer } from 'typesafe-actions';
import { Player, PaginationMeta, ErrorResponse } from '../../interfaces';

export interface PlayerState {
    players: Player[];
    pagination: PaginationMeta;
    loading: boolean;
    error?: ErrorResponse;
}

const initState: PlayerState = {
    players: [],
    pagination: {
      total_pages: 0,
      current_page: 1,
      next_page: 0,
      per_page: 100,
      total_count: 0,
    },
    loading: false,
    error: undefined,
}

const playerReducer = createReducer<PlayerState>(initState, {
    GET_PLAYERS: (state, _) => ({...state, loading: true}),
    GET_PLAYERS_SUCCESS: (state, action) => ({...state, loading: false, players: action.payload.data, pagination: action.payload.meta}),
    GET_PLAYERS_FAILED: (state, action) => ({...state, loading: false, error: action.payload}),
});

export default playerReducer;

Just like the actions we have a rootReducer file where we combine all our reducers

import { combineReducers } from 'redux';
import playerReducer from './player/reducers';

export default combineReducers({
    player: playerReducer,
});

Middleware Setup (Redux-Observables)

I will not go in details on Redux-observables but its worth noticing the isActionOf function from typeSafe-actions filter(isActionOf(getPlayers))

import { combineEpics, Epic } from 'redux-observable';
import { filter, mergeMap, debounceTime } from 'rxjs/operators';

import { isActionOf, RootAction, RootState } from 'typesafe-actions';
import { getPlayers, getPlayersSuccess, getPlayersFailed } from './actions';
import { fetchPlayers, fetchSeasonAverages } from '../../services/http/nbaRequests';
import { Player, SeasonAverages } from '../../interfaces';

export const getPlayersEpic: Epic<RootAction, RootAction, RootState> = (action$, state$) => {
    return action$.pipe(
        debounceTime(500),
        filter(isActionOf(getPlayers)),
        mergeMap(async ({payload}) => {
            const response = await fetchPlayers({search: payload.search, page: payload.page, perPage: payload.perPage});
            if (response.data) {
              const playersIds = response.data.map((player: Player) => player.id);
              const playersAvg = await fetchSeasonAverages(playersIds);

              const findAvg = (id: number) => playersAvg.data.find((item: SeasonAverages) => item.player_id === id);

              const players: Player[] = response.data.map((player: Player) => ({...player, seasonAverage: findAvg(player.id)}))
              return getPlayersSuccess({data: players, meta: response.meta})
            }
            return getPlayersFailed(response);
        }),
    )
};

export const playerEpics = combineEpics(
  getPlayersEpic
);

Yep, you’ve guessed it! RootEpics! 😆

import { combineEpics } from 'redux-observable';

import { playerEpics } from './player/epics';

export default combineEpics(

  playerEpics,

);

Store Setup

Last but not least you can set up the store as following nothing new actually.

import { createStore, applyMiddleware } from 'redux';

import { RootAction, RootState } from 'typesafe-actions';

import { createEpicMiddleware } from 'redux-observable';

import rootReducer from './rootReducer';

import rootEpic from './rootEpic';

import { composeEnhancers } from './utils';

import { loadState, saveState } from '../utils/localstorage';

export const epicMiddleware = createEpicMiddleware<

    RootAction,

    RootAction,

    RootState

>();

const middlewares = [epicMiddleware];

const enhancer = composeEnhancers(applyMiddleware(...middlewares));

const initialState = loadState();

const store = createStore(rootReducer, initialState, enhancer);

store.subscribe(() => {

  saveState(store.getState());

});

epicMiddleware.run(rootEpic);

export default store;

Alternative ways

If you still find setting up the store requires too much boilerplate or complicated you can use redux-toolkit which also is highly recommended in the official documentation of Redux.

It is intended to be the standard way to write Redux logic. I never used it myself yet, but will use it in my next project.

How To Approach Go (Golang)

SamuelRafini — Thu, 19 Dec 2019 15:27:17 +0000

There is a huge hype around Golang and the popularity is growing. So why not give it a “Go”.

But all joking aside, Go was invented by Robert Griesemer, Rob Pike, Ken Thompson and few other engineers at Google. In other words, Go was created by geniuses. Big companies such as Youtube, Twitter, Kubernetes, Docker, and Uber are using Go. Furthermore, Ryan Dahl, the creator of Node.js gave up his creation and promoted Go. Read more → Ryan Dahl
interview

Most people say Go is easy to learn

I have some experience programming in Java and javascript and I find it
indeed very easy to learn, well the basics 😅. Once you go through the tour of go https://tour.golang.org/basics/1 you will understand the majority of things in Go.

However, when it comes to design and architect your go code it’s a
bit challenging in the beginning.

Organize your code is very important, especially when you want to change some logic of your code then the well-structured project can easily adopt the changes. An old and popular style is Object-Oriented programming. Most popular programming languages like Java, C++, C# uses object-oriented programming.

In Go… well, 😑 Go is not considered an object-oriented language for some, because it does not have classes, no inheritance, and interfaces work differently blah blah blah…

But 🤷🏾‍♂️

“Go is a profoundly object oriented language.” — Rob Pike
(https://youtu.be/rKnDgT73v8s?t=750)

Structs instead of classes
Different approach to inheritance: Composition over inheritance Inheritance is when you design your types around what they are, and composition is when you design types around what they do-* → Fun Fun Functions
Go interfaces are very different: interfaces are satisfied implicitly.
this can be confusing at first. Type satisfies Interface without
implementing it.
→ → → Will write more about the topics mentioned above in the future* 🤗

So it’s safe to say that you could implement object-oriented behavior in Go *(still doesn’t make it object-oriented language)

What I’m trying to say

Just write Go like you’re writing Go. Don’t treat it like other languages.
It shifts our mindset about the usual flow of application development. With
Golang, you tend to think more about microservices than your old school Java monolithic projects. I love Java btw 🤫.

Uber, for example, has moved to service-oriented architecture (SOA)
they adopted a microservice architecture a design pattern where they can build independently deployable services. → https://eng.uber.com/service-oriented-architecture/

Another good read on how *Uber built their highest query per second service using Go * → https://eng.uber.com/go-geofence/

Thank you for reading!

Please don’t hesitate to share any feedback.

DEV Community: SamuelRafini

How to Build a Clean Redux Architecture With Redux-Observable and Typescript

How to Build a Clean Redux Architecture With Redux-Observable and Typescript

Folder structure

Actions Setup

Reducers Setup

Middleware Setup (Redux-Observables)

Store Setup

Alternative ways

How To Approach Go (Golang)

Most people say Go is easy to learn

But 🤷🏾‍♂️

What I’m trying to say