Code Log 072516 — React Redux
Today, I’m going to be crash coursing React and Redux. This is all for he hydroponic monitoring system I’ve been going on about. While the back end still needs work, finishing, and tidying, I’ve decided to take my sparest of time to look to the future (and at my weaker area) and learn some front end.
As I’ve already spent a fair amount of time getting the basics of React down, I’m going through the Learn Redux course by Wes Bos. At the time of this initial posting, I’m 9 videos into the 20, and so far so good. A major pro to this course is just how short and sweet each video is. The full course is 2.5 hours which is shorter (by far) than every Lord of the Rings movie. Add in taking notes and taking time to grok the info, and it comes out to a bit longer, but highly doable in one or two sittings. (And probably still shorter than every LOTR movie.)
If you’re new to React, the official tutorial is a great hands on resource, and the docs are easily navigable.
So, what is Redux? It’s an application state manager. What is state? Straight from Redux’s docs:
…state can include server responses and cached data, as well as locally created data that has not yet been persisted to the server. UI state is also increasing in complexity, as we need to manage the active route, the selected tab, whether to show a spinner or not, should pagination controls be displayed, and so on.
So React displays its components based on state. Redux manages the state. It’s a match made in heaven. (Note: Redux is not a React specific library, but they do work nicely together.)
The short on Redux. It revolves around three things:
Actions: When anything happens on the app, Redux dispatches (emits) an action (a lil package of data). You click a button, go back a page, leave the window — Redux knows. You must define what actions are important. In this case, I build an image sharing site, so liking posts and adding/deleting comments are important actions:
Reducer: It’s the logic on what actions to listen for and what to do when they happen. When the reducer receives the lil package of data from the action, it alters the store of data. (Coming from an MVC framework, reducers seem a lot like a controller.) You’ll have a reducer file for every piece of state (in this app, there are posts and comments)
Two important things about reducers:
- While there are separate reducers files, there can only be one reducer interface for the rest of the app. All reducer files must be imported into one “root reducer”
- Any time any action is emitted, every reducer gets run. But of course not all reducers need to response to every action. Perfect use case for a ‘switch/case’.
(Read in order of index →posts →comments.)
So the reducer has access to both the current state of the application before it runs anything and the action that just got emitted (type and payload). It decides whether to act on the action by checking its type against the switch/case options.
Within the reducer, a “new” state is created (as the return object/array) and after the code is run, the reducer returns this new state which gets presented to the user via React. Importantly, the old state is not mutated.
/*The code written here is dependent on the format the data is stored in. Posts are in an array of objects, each object has a unique ‘code’ property. Comments are in an object with keys that match the posts’ unique ‘codes’ (specifying which post the comment is on). The values are arrays with each element being an object with the individual comment’s author and text.*/
Interesting fact: You cannot use an async operation in a reducer with raw Redux. But there are plugins for that.
Store: Collection of all important state information and how to alter it if necessary.
It’s pretty self-explanatory although to know what going on under the hood, you’ll have to read some docs. Everything on line 21 is solely for enabling Chrome’s Redux DevTools and can be omitted from createStore.
So how is any of this useful to React?
Well, it’s not unless all of the information gets connected, and for that, the react-redux library comes in handy.
As the long comment at line 20 says, the point of this file is to make the State and Actions available to React components as props. The Main component is the root parent component in this app, so it makes sense to surface the props there and pass them down to the children as necessary. In fact, by rendering the Main component with…
All of the children of Main have the props of Main. They have the state and actions available immediately. Which is great because the actions get hooked onto button clicks, etc, and it would take a decent amount of extra code to go through passing props down through each child individually.
That’s a lot of stuff! I get what I’m doing, but this application relied a lot on external libraries. I have to dig in a little into those libraries to build my own app, but this course definitely provided a foundation of vocabulary and uses.
That’s it for now. Happy codings!