![fininte state machine](//images.ctfassets.net/vwq10xzbe6iz/6JNh1Rpi6a1VUnTux03TzW/c69b8b54a1be48ec820cec8e721163af/fininte_state_machine.png)

Finite State Machines allow cross-functional teams to visually design complex logic before committing expensive resources to design and code implementation.

It is a powerful tool for product teams and business owners to communicate on customer requirements in order to identify rabbit holes and poor UX early in the process.

They have been widely used in electrical engineering and in the logic design of electronic devices for decades. 

To illustrate the power of Finite State Machines, imagine we have been briefed by the business to build a customer feedback form widget.

## Phase 1 - Simple Feedback Widget
The first phase of our brief is for a simple feedback widget that will do the following:
- Ask for positive or negative feedback
- If positive display a happy success message
- If negative display an apology
- Allow user to cancel the feedback form

We can visualise this simple application using Finite State Machines below:
![phase1](//images.ctfassets.net/vwq10xzbe6iz/3aRVidpZK6c6qevtvEWLfB/9a09666917aeeddc3170c9a4ef80cfcf/phase1.png)

Our application has 4 states:
1. __START__ - our initial state where a user can click to begin the survey
2. __RESPONSE__ - where a user is asked for a positive or negative response and where they can cancel to go back to START
3. __POSITIVE CONFIRM__: an end state upon a user clicking POSITIVE
4. __NEGATIVE CONFIRM__: an end state upon a user clicking NEGATIVE

Our 4 states are also characterised by 4 events and transitions which are conditional upon the current state the application is in.

Our application also triggers actions such as saving the rating and updating the message upon certain events and entering different states.

Once the logic and user flow has been agreed we can easily convert this to design and code stage. In the examples below we use the open source library [XState](https://xstate.js.org/docs/) by [David Khourshid](https://github.com/davidkpiano) to codify our Finite State Machine and use ReactJS to render our UI.

<iframe src="https://codesandbox.io/embed/feedbackphase1-stkhm?fontsize=14&hidenavigation=1&theme=dark&view=preview"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="feedbackPhase1"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>

## Phase 2 - Negative Feedback Reason
The business has now come back asking for us to capture the main reasons for negative feedback.

Our application now must:
- Ask the user to select the main reason for negative feedback (Service, Product, Price)
- Also allow a user to select POSITIVE again if they accidentally selected NEGATIVE

With Finite State Machines we can easily modify and expand our logic without breaking any previous logic:
![phase2](//images.ctfassets.net/vwq10xzbe6iz/38VI5AsXioynO833DlaAzM/9f8c7edb547374d6044b6bff26400c85/phase2.png)

Our application has a new __NEGATIVE FEEDBACK__ state which allows a user to select from three of the main reasons for the negative response (SERVICE, PRODUCT or PRICE). Upon selecting an event the reason is captured and the state transitions to the NEGATIVE CONFIRM end state and displays an apology message.

We have now also added a new POSITIVE event which a user can click on to transition directly to the POSITIVE CONFIRM end state.

Our team can now confidently update our application with the new business logic:

<iframe src="https://codesandbox.io/embed/feedbackphase2-lg6sy?fontsize=14&hidenavigation=1&theme=dark&view=preview"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="feedbackPhase2"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>

## Phase 3 - Advanced Feedback
The business comes back wanting to direct users to contact sales for pricing discussions if they select PRICE as a negative response. In addition they want to capture any other reasons for negative feedback.

Our application must now grow in complexity to handle the following:
- If user selects PRICE as a negative response, send to different end state with pricing discussion CTA
- New OTHER option for a user to select with ability to leave comment

Once again we modify our Finite State Machines to expand our logic
![phase3](//images.ctfassets.net/vwq10xzbe6iz/6wb9cvXQflR8QIBGul2SOU/b8e775fd2c86f028a3c4652602219969/phase3.png)

Our application has now added two new states:
1. __PRICE CONFIRM__: end state when a user selects PRICE as a negative response. We will display a contact number for pricing discussions. Creating a new end state provides us with flexibility if the business may want to display discount offers or ask the user for more contact information in the future
2. __COMMENT__: when a user selects OTHER as a new reason for their negative response. This state includes three events where a user can UPDATE COMMENT to capture the reason, SUBMIT COMMENT to transition to end state and CANCEL to go back and select a different reason

Once again, our Finite State Machine is able to handle increasing complexity without breaking previous logic. Our designer and developer team can now confidently work on implementing the new logic:

<iframe src="https://codesandbox.io/embed/feedbackphase3-8y5dx?fontsize=14&hidenavigation=1&theme=dark&view=preview"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="feedbackPhase3"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>

## Future Complexity
Our application will naturally grow in complexity as business and user requirements evolve. 

Examples may include:
- Ask for feedback for positive response
- Invite user to add users after a positive response
- Ask user to provide the name of the poor service representative
- Introduce a passive response in addition to positive and negative
- etc.

With Finite State Machines we can confidently continue modelling this advanced complexity into our design and visually see how it interacts with previous functionality.


How Finite State Machines allow cross-functional teams to visually design complex logic before committing expensive resources to design and code implementation.

Finite State Machines - A Common Tool for Product Owners, Designers & Developers

> [Click here for github repo of todoapp](https://github.com/howardmann/react-projects/tree/master/todoapp) and [here for live demo of app](http://mannhowietodoapp.surge.sh/)

A visual framework to use for applying React & Redux using the classic Todo App teaching exercise. 
## 1. Overview of TodoApp
While simple, our Todo App covers all the core frontend features of: CRUD, filtering and live reload.
![1. TodoApp](//images.ctfassets.net/vwq10xzbe6iz/1lAWM6TneRs77W6nNoELbK/4b6d1ff28385d2e3e1019160b0cf82da/1._TodoApp.png)

## 2. Break Into Components
Our root App component will contain all the state and logic and will pass this down to its child components.
![2. Components](//images.ctfassets.net/vwq10xzbe6iz/56Zz924eNEdkXu56HSX6Aj/2e6a7456392eaf86bb6e34560a624677/2._Components.png)
Separate each child component by a given responsibility:
1. `<APP/>` Stores our state, actions and renders all immediate children
2. `<NEW_TODO_FORM/>` Accepts text input and triggers "ADD" todo action
3. `<FILTER/>` Changes what items we want to display ("SHOW_ALL" or "SHOW_DONE")

> *Optional: Do not separate out `<NEW_TODO_FORM/>` and `<FILTER/>` into children components if logic is simple and instead keep within `<APP/>`*

4. `<TODOLIST/>` maps over filtered todo items and renders either `<TODO_ITEM/>` or `<EDIT_TODO_FORM/>`
5. `<TODO_ITEM/>` renders the item and includes key action handlers such as mark as done, edit and delete
6. `<EDIT_TODO_FORM/>` renders the input as an input form with its own internal state. Note: we create this as a separate component as we require the feature to undo the edit and only update the state if "Update" button is clicked

## 3. Data Down Actions Up (DDAU)
React follows the principle of Data Down Actions Up (DDAU):
![3. DDAU](//images.ctfassets.net/vwq10xzbe6iz/6LpqSeupvNnkf6xbZahPwr/c5fcafdcebed3460fbcc418ccfe519e2/3._DDAU.png)
1. All/ Majority of application state is stored in a root parent component as a POJO. Also, action callbacks to change state are stored in the parent component
2. Parent then passes down the relevant state and action callbacks to its children as `props`
3. Children components render the `props` and listen for UI events to trigger action callbacks
4. Parent components then execute the callback functions to change state
5. React then does the heavy-lifting to update the UI only for the state that has changed


## 4. Create our State (aka: the source of truth)
All dynamically rendered content should be kept in the state:
![4. State](//images.ctfassets.net/vwq10xzbe6iz/3qe9e2C2w5xq5eCbI8b25C/5b397126cbf13ba0cd118e11fb782060/4._State.png)
All items should be kept in an items array as a single source of truth. 

To filter data, create a helper function to render the items array based on what filter type is in the state - ***Do not duplicate state data***.

Decide whether a `<TODO_ITEM/>` vs. `<EDIT_TODO_FORM>`is rendered by creating an array of items that are marked as edit `isEdit: [4...]`.

## 5. Identify Action Handlers
Identify key UI locations where we will trigger changes to state:
![5. Actions](//images.ctfassets.net/vwq10xzbe6iz/57rSFI8h4I07xjsV3IHqzB/f55ba6cca39dfa591ebe13d1a9f4e182/5._Actions.png)

## 6. Separate out Business Logic
Create a reducer which will be the black box handling our business logic. This is the basic principle of Redux:
![6.Reducer](//images.ctfassets.net/vwq10xzbe6iz/43yPgsyUVgpOfNGuLAsOPF/c1f81dac738207400f6235ebe9548d91/6.Reducer.png)
The reducer accepts three paramaters:
1. `prevState`: the entire state that this reducer is responsible for handling
2. `action.type`: simple text instruction for our reducer to execute relevant function e.g. `"ADD_TODO"`
3. `action.payload`: payload options our action.type and function requires to modify state

A new state is then created without mutating previous state. This business logic is easy to unit test and independent of framework. We then require the reducer to update the state of our components.

*Fin*
***

#### Further reading materials with code:
- [React tutorial](https://reactjs.org/docs/hello-world.html)
- [Redux tutorial](https://redux.js.org/basics/basic-tutorial)
- [You don't need redux](https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367)
- [Code your own combineReducer](https://blog.jakoblind.no/code-your-own-combinereducers/)




How to structure your next web project using React and Redux principles. A visual framework template you can use. 

Howie Mann
Startup & Investing Advice
About Articles Stocks

Articles > javascript

Finite State Machines - A Common Tool for Product Owners, Designers & Developers

Learn React - A Visual Explanation

Howie MannStartup & Investing AdviceAboutArticlesStocks

Articles > javascript

Finite State Machines - A Common Tool for Product Owners, Designers & Developers

Learn React - A Visual Explanation

Howie Mann
Startup & Investing Advice
About Articles Stocks