DEV Community: Richard Ng

Why you can stop writing all that Redux boilerplate

Richard Ng — Mon, 02 Dec 2019 19:54:54 +0000

Should I read this post?
I think that you are more likely to find value in reading this post if you:

Are interested in trying to cut down your Redux boilerplate; or
Enjoy it when conventional coding patterns are challenged; or
Like investigating shiny new libraries for state management!

I have a provocative opinion. I contend that a lot of your Redux boilerplate can be entirely eliminated.

Not all of it - I've not completely lost my mind. Just a great deal of it.

Here's how I'm going to make my case.

Firstly, I'm going to introduce a fictional project scenario;
Secondly, I'm going to look at what Redux boilerplate might typically be used;
Thirdly, I'm going to demonstrate how this boilerplate can be eliminated.

Project Scenario

Situation: a web development agency and a client

Let's suppose that we have a web development agency, Devs2U, working on a project with a new client, MegaCorp.

It's an important project, both for MegaCorp and Devs2U - currently, neither are profitable, but if this project works out then it could turn things around for both of them.

Given the importance of the project, Devs2U's CTO, Maisy, has staffed herself on the project and is currently planning out who else to staff, and what exactly they'll be doing.

// initialState.js

export const initialState = {
  project: {
    agency: {
      name: 'Devs2U',
      revenue: 50000,
      costs: 80000
    },
    client: {
      name: 'MegaCorp',
      revenue: 1500000,
      costs: 7400000
    },
    budgeted: {
      days: 2,
      salaries: 10000
    },
    stagesCompleted: {
      discover: false,
      design: false,
      develop: false,
      test: false
    },
    technologies: {
      languages: ['javascript'],
      libraries: ['react'] // look, ma, no Redux! (... yet)
    }
  },
  persons: [
    {
      name: 'Maisy Ware',
      title: 'CTO',
      employedBy: 'agency',
      status: 'determined'
    },
    {
      name: 'Maddie Swanson',
      title: 'CTO',
      employedBy: 'client',
      status: 'anxious'
    },
    {
      name: 'Kian Bernard',
      title: 'Junior Developer',
      employedBy: 'agency',
      status: 'eager'
    }
  ]
}

Complication: The developer team don't love Redux state management

As she's planning and scoping out the project, Maisy realises that, despite her initial plan to not use Redux, it's going to make the state management significantly easier if she does.

However, although Maisy loves Redux, some of her team don't - they've complained to her that it can be tedious to set up, difficult to learn and painful to maintain.

As such, Maisy decides to take responsibility for architecting the project's Redux code in a way that is quick to setup, easy to learn and simple to scale.

Question: How can we set up Redux with minimal boilerplate?

Let's model this situation using a Redux store.

// store.js
import { createStore } from 'redux'
import { initialState } from './path/to/initialState'

const store = createStore(/* our root reducer */)
store.dispatch(/* some 'LIBRARY_ADDED'-ish action */)
store.getState().project.technologies.libraries // desired: ['react', 'redux']

So, how can we get our root reducer and this action to add Redux to the list of libraries used?

Typical approaches

Here, I'll show three approaches that might be used, and discuss and compare them.

Vanilla
Immer
ReduxToolkit
- createAction with createReducer
- createSlice

It's probably worth noting that in all these cases, it would be more common to break up the root reducer into child reducers and then make a call to Redux's combineReducers - but this is more set up work to do, and we're interested here in handling our 'LIBRARY_ADDED' case as quickly and straightforwardly as possible, so we'll exclude that from our examples.

Vanilla

A 'vanilla' approach might look like this:

// actions.js
export const addLibrary = (library) => ({
  type: 'LIBRARY_ADDED',
  payload: library
})

// reducer.js
export const rootReducer = (state = initialState, action) => {
  switch (action.type) {
    case 'LIBRARY_ADDED':
      return {
        ...state,
        project: {
          ...state.project,
          technologies: {
          ...state.project.technologies,
          libraries: [...state.project.technologies.libraries, action.payload]
        }
        }
      }

    default: return state
  }
}

// store.js
const store = createStore(rootReducer)
store.dispatch(addLibrary('redux'))
store.getState().project.technologies.libraries // => ['react', 'redux']

Immer

immer is a cool library that lets you write immutable updates in a way that feels mutable:

// actions.js
export const addLibrary = (library) => ({
  type: 'LIBRARY_ADDED',
  payload: library
})

// reducer.js
import produce from 'immer'

export const rootReducer = (state = initialState, action) => (
  produce(baseState, draftState => {
    case 'LIBRARY_ADDED':
      // not actually mutating state below, but modifying a draft
      // which immer uses to return the new state
      draftState.project.technologies.libraries.push(action.payload)
  })
)

// store.js
const store = createStore(rootReducer)
store.dispatch(addLibrary('redux'))
store.getState().project.technologies.libraries // => ['react', 'redux']

Redux Toolkit

Redux Toolkit is the new and officially recomended way to write Redux, a library written by the Redux maintainers.

Here are two examples of how we might use the library to handle this specific case of adding a library.

a) `createAction` with `createReducer`

// actions.js
import { createAction } from '@reduxjs/toolkit'

export const addLibrary = createAction('LIBRARY_ADDED')

// reducer.js
import { createReducer } from '@reduxjs/toolkit'

export const rootReducer = createReducer(initialState, {
  [addLibrary]: (state, action) => {
    // action.payload will be the argument passed to addLibrary
    // RTK uses immer under-the-hood for the same mutative 'feel'
    state.project.technologies.libraries.push(action.payload)
  }
})

// store.js
const store = createStore(rootReducer)
store.dispatch(addLibrary('redux'))
store.getState().project.technologies.libraries // => ['react', 'redux']

b) `createSlice`

// reducer.js
import { createSlice } from '@reduxjs/toolkit'

export const root = createSlice({
  name: 'root',
  reducers: {
    addLibrary:(state, action) => {
      state.project.technologies.libraries.push(action.payload)
    }
  },
  initialState
})

// store.js
const store = createStore(root.reducer)
store.dispatch(root.actions.addLibrary('redux'))
store.getState().project.technologies.libraries // => ['react', 'redux']

Discussion

Strong direction of travel

I think there's clearly a good direction of travel throughout these examples. In particular, I know that Mark Erikson (maintainer of Redux) has put a great deal of work into Redux Toolkit, and I think that shows: createSlice is, imo, a big improvement on having to manually write your action creators and reducer logic separately.

All are painful to scale...

I believe that there's a core problem not being addressed, though - they're all going to be painful to scale.

In the different approaches, handling a single case / action type is being optimised - but as your application grows, you'll still need to handle a whole bunch of different cases.

This either means that your root reducer grows into a tremendously large beast, or (more likely) you split it up into reducers handling different slices of state, which leads to a great proliferation of files that you need to maintain.

One of these is certainly the lesser of two evils, but both are additional developer work for you to do.

Redux-Leaves: write once, reduce anywhere

This is why I wrote Redux-Leaves: to make Redux quicker to setup and simpler to scale.

Boilerplate? What boilerplate?

// store.js

import reduxLeaves from 'redux-leaves'

const [reducer, actions] = reduxLeaves(initialState)
const store = createStore(reducer)

store.dispatch(actions.project.technologies.libraries.create.push('redux'))
store.getState().project.technologies.libraries // => ['react', 'redux']

Here's the key difference: unlike the typical approaches, with Redux-Leaves you're not having to manually set up specific cases for trivial things like pushing to an array. Redux-Leaves gives you a bunch of sensible default action creators out-of-the-box, that can be used at an arbitrary leaf of your state tree.

Simple usage: describe the change you want to see

If you can describe the state change you want to see, you can dispatch the correct action.

You can play around with these simple examples on RunKit.

Pushing `'redux'` to the libraries array

1. Where do we want state to change?

storeState.project.technologies.libraries

2. What change do we want to see?

We want to push the string 'redux' into the array

3. What action should I create for dispatching?

actions.project.technologies.libraries.create.push('redux'):

actions.projects.technologies.libraries accesses the relevant path
.create opens up action creators at that particular path
.push('redux') means we create a 'push' action for the payload 'redux'

Budgeting more days and salaries

// At storeState.project.budgeted.days, I want to create an increment action
store.dispatch(actions.project.budgeted.days.create.increment())
store.getState().project.budgeted.days // => 3

// Similar for storeState.project.budgeted.salaries, but I want to increment by 5000
store.dispatch(actions.project.budgeted.salaries.create.increment(5000))
store.getState().project.budgeted.salaries // => 15000

Updating inside an array

// At storeState.persons, I want to update the status property of the 1st element to excited
store.dispatch(actions.persons[1].status.create.update('excited'))
store.getState().persons[1]
/*
  {
    name: 'Maddie Swanson',
    title: 'CTO',
    employedBy: 'client',
    status: 'excited'
  }
*/

Do a bunch of things together

import { bundle } from reduxLeaves

store.dispatch(bundle([
  actions.project.client.name.create.concat(' (definitely not evil)'),
  actions.project.stagesCompleted.discover.create.toggle(),
  actions.persons[0].create.set('lovesRedux', 'you bet!')
]))

store.getState().project.client.name // => 'MegaCorp (definitely not evil)'
store.getState().project.stagesCompleted.discover // => true
store.getState().persons[0].lovesRedux // => 'you bet!'

Advanced usage: write once, reduce anywhere

Sometimes you'll have some logic that is more bespoke.

With Redux-Leaves, you can write this custom logic once, and then use it at any arbitrary leaf of state.

You can play around with this advanced usage on RunKit.

import reduxLeaves from 'redux-leaves'

// break-even at arbitrary leaf state
const breakEven = leafState => {
  return {
    ...leafState,
    revenue: leafState.costs // set revenue property equal to the costs property
  }
}

// set all properties at arbitrary leaf state
//   payload received will be the value to set
const setAll = (leafState, action) => {
  const leafKeys = Object.keys(leafState)
  const newEntries = leafKeys.map(key => [key, action.payload])
  return Object.keys(newEntries)
}

// set some property for all elements of an array
const setEach = {
  reducer: (leafState, { payload: { prop, val } }) => {
    return leafState.map(element => ({
      ...element,
      [prop]: val
    }))
  },
  argsToPayload: (prop, val) => ({ prop, val })
}

const customReducers = { breakEven, setAll, setEach }
const [reducer, actions] = reduxLeaves(initialState, customReducers)


const store = createStore(reducer)

// make both agency and client breakeven
store.dispatch(actions.project.agency.create.breakEven())
store.dispatch(actions.project.client.create.breakEven())

// mark all stages complete
store.dispatch(actions.project.stagesCompleted.create.setAll(true))

// give each person a happy status
store.dispatch(actions.persons.create.setEach('status', 'happy'))

What next?

Summary

In this post, I argued that a lot of your Redux boilerplate can be entirely eliminated by using Redux-Leaves.

The typical approaches streamline handling specific reducer cases, action types and action creators, but there's still a scaling problem. Choose between:

very large reducer files; or
very many reducer files.

With Redux-Leaves, you can avoid choosing either: it's two lines of setup, one of which is an import.

Discussion points

Some advocate an eventful model of Redux actions. If you have opinions on that, I'd love to hear from you!

(In a previous post and discussion thread, I've outlined how I think this might: (a) not be necessary, since Redux-Leaves solves typical command action problems: and (b) how Redux-Leaves might be able to accommodate eventful action modelling. Please leave a comment!)

Read The Docs

Please read the docs and let me know any feedback you have about the library or its documentation - I'm on Twitter, or you can file an issue on GitHub!

Redux command actions that scale without boilerplate

Richard Ng — Fri, 29 Nov 2019 13:47:08 +0000

Should I read this post?

I think that you are more likely to find value in reading this post if you are:

Trying to cut down on your Redux boilerplate; or
Interested in improving your Redux architecture or file structure; or
Trying to navigate Redux actions as 'commands' versus 'events'.

Key takeaways are at the foot of this post.

I recently watched a recording of a great talk by Yazan Alaboudi, 'Our Redux Anti Pattern: A guide to predictable scalability' (slides here). I really love hearing and reading about people's thoughts on Redux architecture, as something I've thought a lot about.

In the talk, Yazan makes an excellent case for two points:

Writing Redux actions as commands¹ is an anti-pattern; and
A well-written Redux action should represent a business event.

In this particular post, I'm going to respond to the first of these points, with a view to discussing the second in a separate post.

Here, my core contention is this: Redux-Leaves solves most - and perhaps all - of Yazan's 'anti-pattern' criticisms of command actions.

I'll do this in two parts:

Firstly, I'll outline Yazan's case against command actions; and
Secondly, I'll demonstrate how Redux-Leaves solves those problems.

What is Yazan's case against command actions?

I recommend watching Yazan's own explanation, but below I will outline my interpretation of what he says.

Example code

Yazan provides some examples of command actions and their consequences:

Command Action Example (Redux setup)

  // in scoreboardReducer.js
  const INITIAL_STATE = {
    home: 0,
    away: 0
  };

  function scoreboardReducer(state = INITIAL_STATE, action) {
    switch(action.type) {
      case "INCREMENT_SCORE": {
        const scoringSide = action.payload;
        return { ...state, [scoringSide]: state[scoringSide] + 1};
      }
      default: return state;
    }
  }

  //in crowdExcitmentReducer.js
  const INITIAL_STATE = 0;

  function crowdExcitementReducer(state = INITIAL_STATE, action) {
    switch(action.type) {
      case "INCREASE_CROWD_EXCITEMENT": return state + 1;
      default: return state;
    }
  }

Command Action Consequences (Component dispatching)

  // in GameComponent
  class GameComponent extends React.Component {
    scoreGoal() {
      dispatch({ type: "INCREMENT_SCORE", scoringSide: "home"});
      dispatch({ type: "INCREASE_CROWD_EXCITEMENT"});
      // potentially more dispatches
    }

    render() {
      //...
    }
  }

In a key slide, he then lays out some costs that he sees in these command-oriented examples:

Disadvantages of Command actions

does not capture business semantics

actions are coupled to reducers

too many actions are firing

unclear why state is changing

leads to a lot of boilerplate

does not scale

Here are my observations on each of these (with the exception of 'business semantics', which I'll tackle in a separate post):

Actions are coupled to reducers

I think that, when it comes to the example code provided by Yazan, it's extremely fair to note that actions are coupled to reducers. The "INCREMENT_SCORE" action type looks entirely coupled to the scoreboardReducer, and the "INCREASE_CROWD_EXCITEMENT" looks entirely coupled to the crowdExcitementReducer.

This is not a good pattern because it means we have extremely low code reusability. If I want to increment something else, like the stadium audience size, I need to use another action type, "INCREMENT_AUDIENCE_SIZE", even though the resulting change in state is going to be extremely similar.

Too many actions are firing

Again, when it comes to Yazan's example code, I think it's fair to note that more actions are being dispatched in the scoreGoal function that feels necessary. If a goal has been scored, a single thing has happened, and yet we're triggering multiple actions.

This is not a good pattern because it will clog up your Redux DevTools with lots of noise, and potentially could cause some unnecessary re-renders with your Redux state updating multiple times instead of doing a single large update.

Unclear why state is changing

I'm not convinced that this is a big problem. For me, in Yazan's example code, it's not too difficult for me to make the link from scoreGoal to "INCREASE_SCORE" and "INCREASE_CROWD_EXCITEMENT".

To the extent that the 'why' is unclear, I think that this can be solved by better-commented code - which isn't a situation unique to command actions in Redux, but something that applies to all imperatively-flavoured code.

Leads to a lot of boilerplate / Does not scale

I think these two are both legitimate concerns (and, at core, the same concern): if, every time we decide we want to effect a new change in state, we have to decide on a new action type and implement some new reducer logic, we will quickly get a profileration of Redux-related code, and this means that it doesn't scale very well as an approach.

How does Redux-Leaves solve these problems?

First, let's look at some example code, equivalent to the previous examples:

Redux-Leaves setup

  // store.js

  import { createStore } from 'redux'
  import reduxLeaves from 'redux-leaves'

  const initialState = {
    crowdExcitment: 0,
    scoreboard: {
      home: 0,
      away: 0
    }
  }

  const [reducer, actions] = reduxLeaves(initialState)

  const store = createStore(reducer)

  export { store, actions }

Component dispatching

  // in GameComponent
  import { bundle } from 'redux-leaves'
  import { actions } from './path/to/store'

  class GameComponent extends React.Component {
    scoreGoal() {
      // create and dispatch actions to increment both:
      //    * storeState.scoreboard.home
      //    * storeState.crowdExcitement
      dispatch(bundle([
        actions.scoreboard.home.create.increment(),
        actions.crowdExcitement.create.increment()
        // potentially more actions
      ]));
    }

    render() {
      //...
    }
  }

Here's an interactive RunKit playground with similar code for you to test and experiment with.

Hopefully, in comparison to the example of more typical command actions given by Yazan, this Redux-Leaves setup speaks for itself:

Only one initial state and reducer to handle
No more writing reducers manually yourself
No more manual case logic manually yourself

I'll also now cover how it addresses each of the specific problems articulated above:

Actions are no longer coupled to reducers
Too many actions? Bundle them into one
Extreme clarity on what state is changing
Incredibly minimal boilerplate
Simple to scale

Actions are no longer coupled to reducers

Redux-Leaves gives you an increment action creator out-of-the-box, that can be used at an arbitrary state path from actions.

To increment...	`create` and `dispatch` this action...
`storeState.crowdExcitement`	`actions.crowdExcitement.create.increment()`
`storeState.scoreboard.away`	`actions.scoreboard.away.create.increment()`
`storeState.scoreboard.home`	`actions.scoreboard.home.create.increment()`

You get a whole bunch of other default action creators too, which can all be effected at an arbitrary leaf of your state tree.

Too many actions? Bundle them into one

Redux-Leaves has a named bundle export, which accepts an array of actions created by Redux-Leaves, and returns a single action that can effect all those changes in a single dispatch.

  import { createStore } from 'redux'
  import reduxLeaves, { bundle } from 'redux-leaves'

  const initialState = {
    crowdExcitment: 0,
    scoreboard: {
      home: 0,
      away: 0
    }
  }

  const [reducer, actions] = reduxLeaves(initialState)

  const store = createStore(reducer)

  store.getState()
  /*
    {
      crowdExcitement: 0,
      scoreboard: {
        home: 0,
        away: 0
      }
    }
  */

  store.dispatch(bundle([
    actions.scoreboard.home.create.increment(7),
    actions.scoreboard.away.create.increment(),
    actions.crowdExcitement.create.increment(9001)
  ]))

  store.getState()
  /*
    {
      crowdExcitement: 9001,
      scoreboard: {
        home: 7,
        away: 1
      }
    }
  */

Extreme clarity on what state is changing

In Yazan's example of command actions, it's not obvious how the overall store state is going to be affected by the dispatches - which score is being incremented in which bit of state?

With Redux-Leaves, the actions API means that you are extremely explicit in which state is being changed: you use a property path to the state you want to create an action at, just as you would if you were looking at your state tree and describing which bit of state that you wanted to effect.

(This isn't addressing quite the same point Yazan makes, which I think is asking, 'but why are we increasing crowd excitement?' - but, as I indicated in discussing that point, I think it's the responsibility of the developer to make the why of a command clear through a comment, if needed.)

Incredibly minimal boilerplate

Here's what we need to do to get our root reducer and action creators:

import reduxLeaves from 'redux-leaves'

const [reducer, actions] = reduxLeaves(initialState)

That's it. Two lines, one of which is an import. No faffing around with writing action constants, creators or reducer case statements yourself.

Simple to scale

Suppose we want to introduce some state to keep track of team names.

All we need to do is to change our initial state...

import reduxLeaves from 'redux-leaves'

const initialState = {
  crowdExcitement: 0,
  scoreboard: {
    home: 0,
    away: 0
  },
+  teams: {
+    home: 'Man Red',
+    away: 'Man Blue'
  }
}

const [reducer, actions] = reduxLeaves(initialState)
const store = createStore(reducer)

... and then we can straight away start dispatching actions to update that state, without having to write any further reducers, action creators or action types:

store.dispatch(actions.teams.away.create.update('London Blue'))
store.getState().teams.away // => 'London Blue'

Takeaways

You should watch Yazan's talk and look at his slides, both are really thoughtful
Yazan makes a strong case against how Redux command actions are typically written
I think that Redux-Leaves solves most of those problems, if not all

Endnotes

¹ An Redux action can be considered a command if it expresses intent to do something. Examples given by Yazan are:

{ type: 'SEND_CONFIRMATION' }
{ type: 'START_BILLING' }
{ type: 'SEND_LETTER' }
{ type: 'INCREMENT_SCORE' }
{ type: 'INCREASE_CROWD_EXCITEMENT' }

MAIN

Strangers on the internet who inspired my open-source library

Richard Ng — Thu, 28 Nov 2019 11:49:10 +0000

Should I read this post?

I think that you are more likely to find value in reading this post if you are:

Interested in my experience of learning from others; or
Curious about the history of Redux-Leaves; or
Made happy by expressions of gratitude to strangers on the internet.

A habit that I picked up during my academic studies is giving due credit to individuals who have been influential in shaping my thoughts, so I thought that it would be.

This occurred to me as I was preparing to give a couple of talks about an open-source library that I've written, Redux-Leaves.

Right now, I don't actually want to talk about myself or Redux-Leaves, but about how strangers on the internet who I have never met in real life made Redux-Leaves possible - not by contributing code to the repository, but by contributing ideas, blogs and talks to the public domain.

I think the time pressure in a talk would make it difficult for me to acknowledge those who have influenced my thought in a sufficiently eloquent or detailed way, and so I've decided to write up those thoughts in a blog post instead (and follow their example of putting things in the public domain!).

In no particular order, these individuals are are:

Dan Abramov
Mark Erikson
Shawn Wang
Kent C. Dodds
Tyler McGinnis

In some of these cases, I might be giving credit to an individual when it might actually be more appropriate to give it to a group of which said individual happens to be most prominent. This is not intentional and I apologise for people whom I have overlooked.

In writing this up, I've also realised that I'm missing out on a lot of learning by doing a VERY BAD JOB at finding diverse voices to learn from. So, selfishly, I'd love it if you would tweet me recommendations on individuals, newsletters or blogs to follow, particularly those more likely to have diverse viewpoints.

Without further ado, here's how each of those individuals contributed in some way to me writing Redux-Leaves.

Dan Abramov (@dan_abramov)

I'd like to credit Dan with three things:

For planting the seed of my 'a-ha!' moment;
For creating Redux; and
For giving great talks generally.

Planting the seed of my 'a-ha!' moment

What I say below will make a lot more sense if you watch at least the one minute of footage where Dan introduces the React useState hook, although I recommend watching more of the talk (because it's great!).

The way that Dan introduced name and setName as a pair made me realise that a Redux store's reducer, and the actions dispatched to it, could be a pair returned from a single function. A reducer needs to be closely related to the actions dispatched to it.

This influence is clear when you compare the signatures for useState and reduxLeaves:

const [state, setState] = useState(initialValue)
const [reducer, actions] = reduxLeaves(initialState)

That 'a-ha!' moment for an API which gave you both reducer and actions - I didn't have any implementation specifics, just the high-level API desire - eventually led to the development of Redux-Leaves, which I'll write about in more technical detail another time.

Creating Redux

Another great talk given by Dan was the one where he introduced Redux (reducers + flux). Clearly, as a library which came out of my experiences with Redux, Redux-Leaves is also existentially indebted to Redux, although that might be obvious and non-interesting.

It might be worth noting that Redux-Leaves uses a cursor-ish approach, which Dan might not have intended for Redux, so he might regard me as doing something completely barbaric with Redux-Leaves. I won't put words in his mouth here, though, as I think Dan's opinions on Redux may have changed since he created it.

Giving great talks

If it wasn't obvious from the fact that I've linked to two of his talks, I think Dan does really great talks. I think that they have a nice theatricality that brings in the audience, and it also looks like he just really enjoys giving them, which itself makes them enjoyable to watch.

I think it's partly Dan's talks that have inspired me to start giving my own talks - which is why it's also great that Dan has written about how he prepares for his talks.

Mark Erikson (@acemarke)

I'd like to credit Mark with three things:

An inspiring dedication to documentation;
Remarkably thorough writings on and around Redux; and
Maintaining Redux entirely outside his day job.

Dedication to documentation

Mark is seriously committed to good documentation. It's something that has inspired me with Redux-Leaves - I'm aiming to hit the same high bar of documentation. (I've even followed Mark in using Docusaurus.)

Writings on and around Redux

Mark has pulled together some really amazing writings on Redux - the two most significant being:

It's certainly not necessary to read these before using Redux or Redux-Leaves, but I think if you're serious about deeply understanding Redux, it's highly advisable to read them.¹ I can't strongly enough recommend Mark's posts for how well-written, researched and thought provoking they are.

Maintaining Redux

Mark also does a really heroic job of maintaining Redux - it's not his day job, he does it in his free time. I for one absolutely love the React-Redux hooks, released in v7.1.0, and rejoice in the prospect of never having to write another connect. Although the hooks seemed to appear like magic into my code with the update, an incredible amount of discussion and work went into them.

A big milestone recently was the official release of Redux Toolkit, which deserves to be looked at by all Redux developers. In particular, I'm a fan of its configureStore export as a big improvement on the API of createStore from the core Redux library.

Predictably, I personally prefer Redux-Leaves to createSlice, but I'd urge everybody to try out Redux Toolkit and see how they find it.

Kent C. Dodds (@kentcdodds)

Kent's writings on testing have made it significantly easier for me to refactor and publish updates to Redux-Leaves.

In particular, Kent brought two particular ideas to my attention:

Write tests. Not too many. Mostly integration.

The more your tests resemble the way your software is used, the more confidence they can give you.

What does this mean in practice?

Redux-Leaves as a library has very few unit tests, and quite a lot of integration tests, most of which are tests of documentation examples - i.e., tests that resemble the way the library is likely to be used.

The library has been through two refactors of note since I first wrote it. In the first refactor, I ended up dumping a lot of unit tests that were testing implementation and therefore completely wrecked by the refactor. I felt no qualms about this - the intended, documented use was covered by the integration tests, that were still passing after the refactor. In the second refactor, I don't remember having to rewrite or delete many tests at all, since the remaining tests were pretty much all about usage and not about implementation.

I now try to follow a process of 'Documentation-Driven Development' with Redux-Leaves. I start by writing the documentation for a new feature, and then I write tests for the documented usage that are agnostic about implementation, and then I start writing code. It's a marrying together of what Kent writes about testing with my dedication to documentation as inspired by Mark Erikson.

Shawn Wang (@swyx)

Shawn is famous for writing about learning in public.

I'm still trying to improve on this - for example, I sometimes worry about bothering people or looking like a shameless self-promoter, and Redux-Leaves has mostly been hacked together by myself, for myself - but I have nonetheless managed to gain some benefits from it. In the very early days of the library, I managed to get some really valuable feedback (with one particular signpost to Proxies leading to a major rewrite of the library).

This blog post itself is an example of me trying to be better at learning in public!

Tyler McGinnis (@tylermcginnis)

I subscribe to Tyler's weekly Javascript newsletter, which I like because it keeps a pipeline of cool projects coming into my inbox. I look at them, and I feel inspired to keep working on my own projects, the most major of which is - of course - Redux-Leaves!

What do I hope are the key takeaways from this?

Well, I'd like to think that this post helps encourage somebody to keep learning and working on their project, whether that be an open-source library like Redux-Leaves or something else.

The individuals I've cited all have pretty high-profiles, in that they all have at least 10k Twitter followers, so they certainly don't need me to promote them - but, even so, I think it's nice to thank people who've helped you, so I also would like to think that I've achieved that.

Finally, because I like the rule of three, I'll circle back to something I've alluded to earlier: I'm aware of an extreme lack of diversity in the figures I've cited here, which means that I'm missing out on a lot of learning. I want to fix this shortcoming. If you can think of anybody that I should follow, please tweet me a suggestion!

Endnotes

¹ One thing that comes out of Mark's posts is that there are many technically valid ways to write Redux code, but not all of these might be intended ways to write it. For example, Redux-Leaves is a cursor-ish library that is more suited to modelling setters than events, which is technically valid - but this is not necessarily the way that Redux is intended to be used.

I had a short conversation with Mark about this, where he said: (a) "it's a legitimate approach from a technical standpoint, but not how we're trying to encourage people to think about things"; and (b) "if you've found a variation on a usage pattern that works well for you, go ahead and do that".

So, caveat emptor with Redux-Leaves, but I will write a separate covering my thoughts in more detail at some point. Acknowledging that Redux-Leaves might not be following an intended usage pattern for Redux, I still find that the benefits for me when I use it greatly outweigh the costs. MAIN

DEV Community: Richard Ng

Why you can stop writing all that Redux boilerplate

Project Scenario

Situation: a web development agency and a client

Complication: The developer team don't love Redux state management

Question: How can we set up Redux with minimal boilerplate?

Typical approaches

Vanilla

Immer

Redux Toolkit

a) createAction with createReducer

b) createSlice

Discussion

Strong direction of travel

All are painful to scale...

Redux-Leaves: write once, reduce anywhere

Boilerplate? What boilerplate?

Simple usage: describe the change you want to see

Pushing 'redux' to the libraries array

1. Where do we want state to change?

2. What change do we want to see?

3. What action should I create for dispatching?

Budgeting more days and salaries

Updating inside an array

Do a bunch of things together

Advanced usage: write once, reduce anywhere

What next?

Summary

Discussion points

Read The Docs

Redux command actions that scale without boilerplate

What is Yazan's case against command actions?

Example code

Command Action Example (Redux setup)

Command Action Consequences (Component dispatching)

Disadvantages of Command actions

Actions are coupled to reducers

Too many actions are firing

Unclear why state is changing

Leads to a lot of boilerplate / Does not scale

How does Redux-Leaves solve these problems?

Redux-Leaves setup

Component dispatching

Actions are no longer coupled to reducers

Too many actions? Bundle them into one

Extreme clarity on what state is changing

Incredibly minimal boilerplate

Simple to scale

Takeaways

Endnotes

Strangers on the internet who inspired my open-source library

Dan Abramov (@dan_abramov)

Planting the seed of my 'a-ha!' moment

Creating Redux

Giving great talks

Mark Erikson (@acemarke)

Dedication to documentation

Writings on and around Redux

Maintaining Redux

Kent C. Dodds (@kentcdodds)

Shawn Wang (@swyx)

Tyler McGinnis (@tylermcginnis)

Endnotes

a) `createAction` with `createReducer`

b) `createSlice`

Pushing `'redux'` to the libraries array