React Native + Redux (Part 2)

Not a todo app example!

So Redux it is!. (PS: Just in case you were wondering at this point why redux, checkout this article) Before diving in, clear your minds from everything you read in Part 1(yes I mean everything. Because we don’t want to know how react works without redux to use redux as it can blur your understanding of how redux fits in react ecosystem. All we needed to know was the problem with not using redux). Lets look into how the lifecycle of this react app works when a state changes.

Lets try to understand what this flow is trying to achieve:

1. Entry point! This is the Mother Store, the single source of states for our entire app. This Store has all the state info the app needs to render all of its components. So the parent reads from the Store and renders all of the children based on the state.
2. These states from the parent are passed to its children or it uses to perform some conditional rendering.
3. Here we have an event fired from the user i.e a button is pressed. This button press wants to tell the app to change one of its states! So how is it going to convey the message to the Store? It sends out an action saying what state (or action type) it wants to change in the Store and what is the value it wants the state to be changed to!
4. Now we know something changed because of the action, but we don’t tell the Store about the changes. So here comes the Reducers! The reducer picks up the action(which has action type and value) and applies the changes to the state copy it has.
5. The store now somehow *magically* (we’ll dig further into the topic) knows reducer has the new values, picks up the changes from it and updates itself.
6. Once the Store updates itself, the components listening to the states in the store re-render based on the new values! And the cycle continues! Thats it! Thats what our component lifecycle should now look with redux.

Now lets break the cycle explained above in the form of code and go step by step.

Store

Lets create our store. This Mother Store at the very beginning has state types and its initial values that are declared in the reducer (huh? where’s the reducer? Hang on…). Updates to the store states happens when actions are triggered as and when we render components.

We wrap the ParentComponent with Provider tag that helps to pass the store down to the entire app. (Don’t be overwhelmed here since most of this is boiler plate code and Redux provides it for you!).

Reducer

In this tiny app, the state that we are looking for is login state. This login state will let us login to our app and logout of it on button press. This login state is initialized in the Reducer. The Reducer also, also picks up the changes from the Action and applies to the login state. Here’s how:

• We are initializing our login state in this reducer which the store picks up from.
• We have a function that picks up the action that changed the state. Since one reducer can maintain many states, we have the switch case to check which action was modified. It picks up the action.type and assigns the status of our login state with action.status (which means login status is false)

Now we have our reducer and store, but where is the action?

Action

The action basically listens to dispatch from the component and sends it to the maps it to the reducer that listens to this action type.

Thats it so tiny? Yep, that right there is our Action with (key) type LOGOUT and (value) status as either true or false depending upon what the component sends us. All of this inside our action creator logoutOfApp. (PS: we are assuming synchronous actions for now, async is probably another article by itself)

SO…

We now have our Store and listeners set up. Now all we need to do is create components that listen to this state and dispatch changes to the reducer to change the state, from the components.

ParentComponent needs to read the login state to decide whether to show Header or the Text → “You are logged out!”. In order to read the state from the store, we need to map the store states to the props of this component. Hence we use mapStateToProps that gets the state from the store, and maps it to this.props.state local to that ParentComponent. To make sure we map it right, connect is introduced. (connect is redux protocol to connect mapstatetoprops and the ParentComponent, nothing fancy/specific to this component).

*If there is a change to this.props.state.login from another component that has absolutely no relation to this, ParentComponent will still re render to get latest changes since we are mapping the state to this component.*

HeaderComponent

Yeah, a regular standalone component. This one does not need to know about the states in store nor does it need to dispatch any changes. Absolutely no dependency since it does not need to take props from ParentComponent and send it to the ButtonComponent. Independence!

LogoutButtonComponent

The last piece! Phewww!! This one dispatches an action. That is, when the button is pressed, it logs you out! This component does not read the states, but updates the states.

mapDispatchToProps holds the onClick props that gets called onPress inside TouchableHighlight. We need to make sure we map the action that we want to dispatch to in the component by importing the action creator (logoutOfApp). That being said, onClick when called, dispatches the action creator we imported with the value we want. (in this case false, since we want to set login to false, which will log us out.)

With that, our react-native redux app is ready to go!

Hope you enjoyed reading this article!. Please feel free to post your questions/opinions/suggestions. :)