What are the top things you wished you knew when you first started implementing Redux with a React app?

React-Redux is conceptually pretty simple. It subscribes to the Redux store, checks to see if the data your component wants has changed, and re-renders your component.

However, there's a lot of internal complexity to make that happen, and most people aren't aware of all the work that React-Redux does internally. I'd like to dig through some of the React design decisions and implementation details of how React-Redux works, and how those implementation details have changed over time.

Understanding Redux Store Subscriptions

It's been said that "Redux is just a [dumb] event emitter". There's actually a fair amount of truth in that statement. Earlier MVC frameworks like Backbone would allow triggering any string as an event, and automatically trigger events like "change:firstName" in models. Redux, on the other hand, only has a single event type: "some action was dispatched".

As a reminder, here's what a miniaturized (but valid) implementation of the Redux store looks like:

function createStore(reducer) {
    var state;
    var listeners = []
 
    function getState() {
        return state
    }
    
    function subscribe(listener) {
        listeners.push(listener)
        return function unsubscribe() {
            var index = listeners.indexOf(listener)
            listeners.splice(index, 1)
        }
    }
    
    function dispatch(action) {
        state = reducer(state, action)
        listeners.forEach(listener => listener())
    }
 
    dispatch({})
 
    return { dispatch, subscribe, getState }
}
 

Let's focus in particular on the dispatch() implementation. Notice that it doesn't check to see if the root state actually changed or not - it runs every subscriber callback after every dispatched action, regardless of whether there was any meaningful change to the state or not.

In addition, the store state is not passed to the subscriber callbacks - it's up to each subscriber to call store.getState() if desired to retrieve the latest state. (See the Redux FAQ entry on why the state isn't passed to subscribers for more details.)

The Standard UI Update Cycle

Using Redux with any UI layer requires the same consistent set of steps:

1. Create a Redux store
2. Subscribe to updates
3. Inside the subscription callback:Get the current store state Extract the data needed by this piece of UI Update the UI with the data
4. If necessary, render the UI with initial state
5. Respond to UI inputs by dispatching Redux actions

Here's an example with a vanilla JS "counter" app, where the "state" is a single number:

// 1) Create a store
const store = createStore(counter)
 
// 2) Subscribe to store updates
store.subscribe(render);
 
const valueEl = document.getElementById('value');
 
// 3. When the subscription callback runs:
function render() {
    // 3.1) Get the current store state
    const state = store.getState();
 
    // 3.2) Extract the data you want
    const newValue = state.toString();
 
    // 3.3) Update the UI with the new value
    valueEl.innerHTML = newValue;
}
 
// 4) Display the UI with the initial store state
render();
 
// 5) Dispatch actions based on UI inputs
document.getElementById("increment")
    .addEventListener('click', () => {
        store.dispatch({type : "INCREMENT"});
    })
 

Every Redux UI integration layer is simply a fancier version of those steps.

You could do this manually, in every React, component, but it would quickly get out of hand, especially once you start trying to cut down on unnecessary UI updates.

Clearly, the process of subscribing to the store, checking for updated data, and triggering a re-render can be made more generic and reusable. That's where React-Redux and the connect API come in.

READ MORE

SOURCE: Idiomatic Redux: The History and Implementation of React-Redux · Mark's Dev Blog