3

Recently I've been learning Redux and while reading the docs, I came across something called reducers. According to the doc,

The reducer is a pure function that takes the previous state and an action, and returns the next state.

i.e. (previousState, action) => newState;

This sounds somewhat familiar to Finite State Automata which takes current state and an input and goes over to the next state.

So is it right to think of reducers as FSA or is it something different?

Animesh Kumar
  • 237
  • 3
  • 11

2 Answers2

3

A reducer describes deterministic state transformations so you are right to think that it sounds similar to an FSA.

The main difference is that a reducer only describes deterministic state transformations, it does not limit the possible states or actions it can be passed.

A reducer can be passed an infinite number of different states, and it can be passed an infinite number of different actions, so by itself a reducer does not describe a deterministic state automaton.

A reducer in combination with a description of a finite number of states and a finite number of possible actions that can be passed to it would together form the definition of a deterministic finite automaton.

Brian Adams
  • 43,011
  • 9
  • 113
  • 111
2

It's a bit of an abstract question, but I would say no.

While in general FSA does receive an action and updates the machine state in the same fashion as redux does, it still differs in one general concept, that the FSA has a finite number of states, where this is not true for redux reducer.

For most scenarios with redux you don't really know what payload the next action will contain.

Take this for example of a FSA: an elevator

Elevator has a finite number of levels. It can go to each one, or return to the default one (lobby). Everything here is tightly defined. It is possible to know each state and transition combination.

In redux, this could also be true for a filter dropdown, where user can select from a fixed list of items or reset the filtering.

However, if you are pushing a html input element value to the state, you don't really know what the user will input and each input will produce a new state. In that fashion the number of states within a redux reducer would be potentionally infinite

I would say that this would be more inline with Infinite tree automaton, which is an extension of the pattern you are looking after:

https://en.wikipedia.org/wiki/Infinite_tree_automaton

Vlatko Vlahek
  • 1,839
  • 15
  • 20
  • I got what you are trying to say and most part of the answer makes sense apart from this `However, if you are pushing a html input element value to the state, you don't really know what the user will input and each input will produce a new state. ` Are there any real-world use cases where one would like to create a new state from user input? – Animesh Kumar Jul 29 '18 at 17:42
  • 1
    A lot of them. Let's say that you have a multistep registration form (react native for example), and you want to save all user data to the onboarding reducer before pushing complete user info to a backend (firebase for example). Another example is the global searchbar component. It makes sense to push the state to a search reducer (let's say we have a prop named query there), so that your search doesn't reset if your user changes a route on your website. – Vlatko Vlahek Jul 29 '18 at 20:44
  • Thanks for the answer. It makes sense now. – Animesh Kumar Jul 30 '18 at 04:06