Using Redux with React

programming
1
React is cool. Redux is cool. What if we combined them both to create something...extra cool?!! This tutorial explores this topic in greater detail: http://www.kirupa.com/react/using_redux_with_react.htm :stuck_out_tongue:
1 Like
2

I loved reading your react redux tutorial. Which software you used to create diagrams for this tutorial. They are pretty neat.

  • Saurabh
3

Adobe Animate :slight_smile:

Glad you liked it!

4

seriously, i love it … :yum::yum:

5

Finally understood the simplicity of Redux… Thank you!

6

There is a tricky semicolon

// Map Redux state to component props
function mapStateToProps(state) {
  return {
    countValue: state.count;  // <- here
  }
}

I am happy to find it cause I am happy I actually read your articles and not only the code. Thank you very much for these tutorials :slight_smile:

1 Like
7

thank you! I was getting an error and couldn’t figure out why! I appreciate it.

In case if someone get’s the same error:
Parsing error: Unexpected token, expected “,”

5 | function mapStateToProps(state) {
6 | return {

7 | countValue: state.count;
| ^
8 | };
9 | }
10 |

8

This app is a simple Counter… does any one know how to make the App able to display the count also (beside the counter showing it)?

(it is said that

You can initiate a state change and involve only the components that are impacted directly. This directness reduces a lot of overhead you would otherwise have to maintain to ensure that your data (and any changes to it) gets to its intended destination without causing unnecessary renders. Pretty cool, right?
)

9

@jianlin can you clarify? The count is showing in the counter. That’s the number between the + and - buttons.

10

@senocular I mean the App component able to show the count. Not by the Counter component showing it, but by the App component itself.

That means, inside the App code, it should be able to do something like { count } and be able to show it.

11

I understand now. Thanks for clarifying :slight_smile:

When saying “involve only the components that are impacted directly,” that is in reference to the additional functionality given to a component from the connect() function. Redux’s connect() is how you specify what component types are created with the ability to access, and change as a result of changes within, the Redux state.

At the bottom of Counter.js in your example, you can see where connect() is called with Counter to create a connectedComponent which represents the new version of Counter that has access to the Redux state - or at least the part of it which is defined by mapStateToProps and mapDispatchToProps. You can do something similar with App. All you need to do is call connect() in a similar way for the App component. Assuming you only want the counter value and are not worried about allowing App to change that value, you only need to specify a mapStateToProps to pull the counter from the state and provide it to App as a prop. App.js could then look something like this:

import React from "react";
import Counter from "./Counter";
import { connect } from 'react-redux';

function App(props) {
  console.log("APP is re-rendering", props);

  return (
    <div>
      App says hello { props.countValue }
      <Counter />
    </div>
  );
}

function mapStateToProps(state) {
    return {
        countValue: state.count
    }
}

let connectedComponent = connect(
    mapStateToProps
)(App);

export default connectedComponent;
12

Thank you. That makes sense… only inject the needed props to minimize re-rendering…

I also heard, usually we won’t inject the props to App, but create another component such as Display, and inject it as props to Display. In this case, when the props change, only the Display needs to re-render. If it is injected to App as props, the whole App and the subtree, meaning every single component in the App will re-render.

There is an advanced question too… maybe difficult to answer unless very familiar with the React internals: https://stackoverflow.com/questions/60395221/how-does-redux-make-the-component-re-rendering-minimal

13

Kind of, but also not necessarily.

At a high level, when any component renders, no matter what the reason, it also renders its children. This is natural since a component is, itself, a collection of its children. If the component renders, so too would be the need for its children, being a part of that component.

But at the same time, not all children need to render when a parent component renders. If only one part of a component needs to change, the other parts wouldn’t need to render because they wouldn’t be affected by the change. React provides a way to check for this using the shouldComponentUpdate (in class-based components). Any component can use shouldComponentUpdate to decide whether or not anything changed that would necessitate a render to be necessary. If not, it will not render. React even provides an alternative to Component called PureComponent which automatically implements shouldComponentUpdate, checking for any changes in props and, if not, aborting a render. This way, if a parent component renders, any child thats a PureComponent won’t render unless the parent also changed the child’s props. You can imagine an App component hierarchy like this:

<div>
   <NormalChild />
   <PureChild />
</div>

Assuming PureChild extends PureComponent and NormalChild does not, whenever App renders, the NormalChild component will also render but the PureChild component will not. PureChild would only render from App if its props had changed.

Note that functional components, while they don’t have an equivalent to shouldComponentUpdate, can use React’s memo() function to get PureComponent-like behavior by preventing renders when props don’t change.

Moving changes to a child component like a Display component does something similar. It too avoids renders, but instead if does this simply by moving the change further down in the hierarchy. This is not necessary in many cases, depending on how many other children there are in a component that would also be affected by renders.

As far as Context goes, its not much different than connect() in Redux. Context is simply another version of a props or state change that’s coming from another source (the Provider). The same thing applies where, if the data changes, the component referring to that data renders with then the possibility of all its children also rendering depending on whether or not they’re set up to check for their own need to.

1 Like