Flux, React and Redux

Posted on June 29, 2018


React is declarative

The data and operations seem mangled up

React Component class or react component type A component takes parameters called props and returns a hierarchy of views to display via the render method

Haskell speak: component :: render -> props -> hierarchy of views It’s as if a render is a functor and component is fmap

render returns a description of what you wish to render react takes the description and renders it to a screen render returns a react element (a lightweight description of what to render)

Each React element is a real JavaScript object that you can store in a variable or pass around your program.

React components can have state by setting this.state in the constructor, which should be considered private to the component.

In JavaScript classes, you need to explicitly call super(); when defining the constructor of a subclass.

We even have a topic on lifting state

When you want to aggregate data from multiple children or to have two child components communicate with each other, move the state upwards so that it lives in the parent component. The parent can then pass the state back down to the children via props, so that the child components are always in sync with each other and with the parent

It is conventional in React apps to use on* names for the attributes and handle* for the handler methods.

controlled components - child components that receive their state from a parent component

react components are made up of react elements which so far look just like HTML elements to me


Imperative rendering

React comes in here: re renders diffs

From: [A Case against the GO TO Statement by Edward Dijkstra] > we should do (as wise programmers aware of our limitations) our utmost best to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

Make things snapshottable: * one state to next state

When data changes react re renders entire component

referentially transparent functions/endpoints - trivial tp predict for given input - easy to test

Stateful DOM or any stateful UI toolkit

Solution is a virtual DOM which is implemented in a lib called react

immutability plays well with diffing two states

Functional components

Rather than return a class extending React.Component, write a fn that takes props and returns what should be rendered


State is similar to props, but it is private and fully controlled by the component. Local state is exactly that: a feature available only to classes.

State updates may be asynchronous

React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state.

to fix this use a version of setState that accepts a function e.g

this.setState((prevState, props) => {
  counter: prevState.counter + props.increment

State updates are merged

merges the object you provide into the current state. merging is shallow i.e. leaves other key value pairs untouched

Handling events

When using React you should generally not need to call addEventListener to add listeners to a DOM element after it is created. Instead, just provide a listener when the element is initially rendered.

You have to be careful about the meaning of this in JSX callbacks. In JavaScript, class methods are not bound by default. If you forget to bind this.handleClick and pass it to onClick, this will be undefined when the function is actually called.

you can use an arrow fn in the callback e.g

onClick={(e) => this.handleClick(e)}

The problem with this syntax is that a different callback is created each time the LoggingButton renders. In most cases, this is fine. However, if this callback is passed as a prop to lower components, those components might do an extra re-rendering. We generally recommend binding in the constructor or using the class fields syntax, to avoid this sort of performance problem.

Lifecycle hooks

methods run during the life cycle events such as mounting and umounting

this.setState({}) takes an object of new state constructor runs before the object is created

modifying state directly e.g this.state.comment = “I’m new…” doesn’t lead to a rerender. use set state

The only place where you can assign this.state is the constructor.


App.js has all the paths triggers container for that component


flux arch for building UIs using react

think of flux as new MVC

action: comes into the system dispatcher: traffic controller for the whole thing store: data layer updates whenever we get a new action view: re render whenever store says something has changed

Difference from MVC 1. use explicit data instead of derived data 2. separate data from view state 3. avoid cascading effects by preventing nested updates - x updates y which updates z - let data layer completely finish processing before triggering any additional actions

single direction flow: action -> stores -> views

flux action -> dispatcher -> store -> view ^—– action —–|

the dispatcher ensures that until store is done views or anything else can’t put an action through the system

advantages: - improved data consistency: everything in sync - easier to pinpoint root of a bug - easier unit tests because modules are pure-ish/atomic/functional


can trigger actions


enforces no cascading effects once an action goes into store you can’t put another until store is done processing it


Redux has no relation to react but works especially well with it because react let’s you describe UI as a function of state. Redux emits state updates in response to actions.

actions pure functions in redux only 2 things allowed to interact with the store one is a reducer it changes the state others are selectors retrieve data from the state

containers are components aware of global state

all things that fetch lists should be aware of pagination

page numbers

generic for tasks, locations clients

connect(mapStateToProps, mapDispatchToProps, [mergeProps], [options])

Connects a React component to a Redux store. connect is a facade around connectAdvanced, providing a convenient API for the most common use cases.

It doesn’t modify the component class passed to it; instead it returns a new, connected component class for you to use.

reference [React-redux “connect” explained][Usage with React](https://redux.js.org/basics/usage-with-react) source code


the result must be a plain object which will be merged into the component’s props.



To allow all components to access the store use a d special react redux component to make the store available to all container components in the app without passing it explicitly. provider docs

Action creator

A function that creates an action. > action is a payload of information, and an action creator is a factory that creates an action.

Calling an action creator only produces the action but does not dispatch it. You need to call the store’s dispatch fn to actually cause the mutation


Also called a reducing function function that accepts an accumulation and a value and returns a new value

reduce in other langs or fold in haskell.

reduce a collection of values into a single values

most important concept in redux


A helper function that turns an object whose values are different reducing functions into a single reducing fn you can pass to createStore.

the resulting reducer calls every child reducer and gethers the resilt into a single state object

The state produced by combineReducers() namespaces the states of each reducer under their keys as passed to combineReducers()


creates a single redux store that holds the complete state of your app.

Your app should have a single store

args: reducer, preloadedState, enhancer

enhancer: store enhancer optionally specify it to enhance the store with third party capabilities such as middleware, time travel, persistence etc

the only store enhancer that ships with redux is applyMiddleware


Lets you wrap the store’s dispatch method Middleware is composable

Most common use case is to support async actions without much boilerplate code or lib dependency. Does so by letting you dispatch async actions in addition to normal actions


lets the action creators invert control by dispatching functions. They would receive dispatch as an arg and may call it async. Such functions are called thunks.


Lets you dispatch a promise async action and dispatches a normal action when the promise resolves.

Middleware is not baked into createStore and is not a fundamental part of the Redux architecture, but we consider it useful enough to be supported right in the core. This way, there is a single standard way to extend dispatch in the ecosystem, and different middleware may compete in expressiveness and utility.

Async action

A value that is sent to a dispatching function but not yet ready for consumption by the reducer. It will be transformed by middleware into an action before being sent to the base dispatch fn


Holds the whole state tree of your app. A store is not a class. It’s just an object with a few methods on it.

There’s no way to directly modify the store only way is through reducers and only way to trigger reducers is to dispatch actions

to change data dispatch and action to obtain data we should (need to) go through a selector

we get the state of the application at the time we made the select


Smart components are not allowed to have any logic except dispatching actions. Smart components should always access state through selectors.

Place all business logic inside action handlers (thunks), selectors and reducers.

presentational and container components

reference: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 aka stateful and pure components among other names

this approach achieves: - separation of concerns - reusability


Abstract an external API

services must be stateless


In Redux, the reducer is the construct that holds state and updates it



Service workers


Other implementions of the store - backbone: instagram

[React-redux “connect” explained] :https://www.sohamkamani.com/blog/2017/03/31/react-redux-connect-explained/