Yesterday we looked at some important libraries we're using. I'm glad you took time to study them! Some of these libraries are very interesting – especially Redux. It works well for the web and with React Native.

To better understand DailyDrip’s app, let's check our data. First, let's execute our app. So far, our app is working pretty well on Android.

react-native run-android

Let's log in. Our app has a type of tutorial at the beginning. Let's read the tutorial and then go to our main screen. Our main screen lists all the topics we have and has a drawer menu of each topic. If we click on a topic, we will see all its episodes and if we click on an episode we can see its content. We should have react native debugger installed.

brew update && brew cask install react-native-debugger

Open a the react-native-debugger, but take note that this is not the one which comes with Chrome. Once the React Native debugger is open, we just need to run it on our app. When we debug it remotely the debug section will be in our React Native debugger. With this, we can see completely our state.

At the beginning we have:

@@INIT
REDUX_STORAGE_LOAD
FETCH_TOPICS
REDUX_STORAGE_SAVE

We're using Redux Storage and it stores our redux state using AsyncStorage. So, because of that in the inspector we can see REDUX_STORAGE_LOAD and REDUX_STORAGE_SAVE.

If we call the API, we have some actions in our app: such as "get topics" and "get drips". These actions are inside our actions file. The actions are: setTopics, setDrips and selectTopic. The reducer job specify how the application's state changes.

FETCH_TOPICS is the type of our action setTopics. As we can see our setTopics has a type and the topics.

const setTopics = (topics) => {
  return {
    type: FETCH_TOPICS,
    topics,
  }
}

Checking the raw data from this action, we can see:

{
  topics: {
    '1': {
      id: 1,
      title: 'Elixir',
      description: 'Learn the Elixir Programming Language, built atop the highly-scalable Erlang Virtual Machine.',
      drip_count: 286
    },
    '2': {
      id: 2,
      title: 'Elm',
      description: 'Learn Elm, a strongly-typed functional programming language that is used for building frontend applications.',
      drip_count: 181
    },
    ...

This is the topics content.

If we click on a topic, we can see the action is SELECT_TOPIC. Let's check our action, it's very similar to what we have for setTopics, but now we're passing the topicId:

const selectTopic = (topicId) => {
  return {
    type: SELECT_TOPIC,
    topicId,
  }
}

The raw data is quite simple:

{
  type: 'SELECT_TOPIC',
  topicId: 5
}

The FETCH_DRIPS is another example. When we click on a topic, we can see the list of drips. If we check the raw data, we will see this is exactly our drips’ content:

{
  type: 'FETCH_DRIPS',
  topicId: 5,
  drips: {
    '18': {
      screenshot: {
        url: null
      },
      identifier: '001.1',
      topic_id: 5,
      description_html: '<p><a href="http://sidekiq.org">Sidekiq</a> is a gem that provides simple, efficient\nbackground processing for Ruby.  It can be used in any Ruby project, and also\nintegrates tightly with Rails for easy background processing.</p>\n\n<p>You can write and schedule jobs easily, and you also can mount a great\nlooking dashboard for tracking your jobs.  Here&#39;s what it looks like:\n<img src="https://raw.githubusercontent.com/mperham/sidekiq/master/examples/web-ui.png" alt="Sidekiq Web UI"></p>\n\n<p>In addition to being a fantastically useful open source library in general,\nSidekiq has 2 commercial upgrades - Sidekiq Pro and Sidekiq Enterprise.\nThey both come with email support, a commercial license and additional features.\nIn later episodes we&#39;ll cover some of those features.</p>\n\n<p>Up next, we&#39;ll go over installation and write a basic worker.  See you soon!</p>\n',
      teaser: 'A basic introduction and overview of the Sidekiq background processing system.',
      title: 'Introduction to Sidekiq',
      video: {
        url: null
      },
      id: 18,
      description: '[Sidekiq](http://sidekiq.org) is a gem that provides simple, efficient\r\nbackground processing for Ruby.  It can be used in any Ruby project, and also\r\nintegrates tightly with Rails for easy background processing.\r\n\r\nYou can write and schedule jobs easily, and you also can mount a great\r\nlooking dashboard for tracking your jobs.  Here\'s what it looks like:\r\n![Sidekiq Web UI](https://raw.githubusercontent.com/mperham/sidekiq/master/examples/web-ui.png)\r\n\r\nIn addition to being a fantastically useful open source library in general,\r\nSidekiq has 2 commercial upgrades - Sidekiq Pro and Sidekiq Enterprise.\r\nThey both come with email support, a commercial license and additional features.\r\nIn later episodes we\'ll cover some of those features.\r\n\r\nUp next, we\'ll go over installation and write a basic worker.  See you soon!\r\n'
    },
    '19': {
      screenshot: {

Isn’t this awesome?

In our Reducers we're using ImmutableJS. Why?

ImmutableJS is a library from Facebook that provides us with some data structures. According to them, the Data structures are highly efficient, and they provide immutability. When we use immutability in our code we do not have side-effects and it's normally easier to think about the data structure – they are totally immutable! The reducers cannot have side-effects, so using ImmutableJS it's a good thing here, it helps our reducers do what they should do. Before finishing this episode, let's just have a quick look on how we're using redux.

We're using redux to help us handle our data requests, e.g., everything coming from our API and being shown on the screen. If we check every screen we have, you can see we're following the standard we saw in some episodes before: Smart/dumb containers. Our containers are connecting with redux and passing the content itself to a presentational component. We can see this standard in our login screen, for example:

import Login from './index'
import { connect } from 'react-redux'
import API from '../../api'
import Actions from '../../actions'
const mapStateToProps = () => {
  return {}
}
const mapDispatchToProps = (dispatch) => {
  return {
    fetchTopics: () => {
      API.getTopics().then((response) => {
        dispatch(Actions.setTopics(response.data.topics))
      }).catch((err) => console.log(err))
    },
  }
}
const ConnectedLogin = connect(mapStateToProps, mapDispatchToProps)(Login)
export default ConnectedLogin

And our Login Screen has all the components. We are following this standard for the other screens and this is how we're working with Redux.

There are a lot of interesting elements in redux, but we will talk about that later. Hope you enjoyed it! See you soon!

Resources