DEV Community: Patrick

React, Redux, and API's Part Four: Redux (DRY)

Patrick — Wed, 09 Jan 2019 20:36:48 +0000

original post can be found on my blog

In the last post we looked at how we could use redux to interface with our API. In this post we're going to take a look at how we can make that code more re-usable so we don't have to repeat ourselves.

Here's the example from the previous post. It uses thunks to allow us to dispatch three distinct actions and it calls the API using fetch.

// postsActions.js

const loadPosts = () => async (dispatch, getState) => {
    dispatch({
        type: "Posts.LOAD_POSTS_REQUEST"
    });

    const fetchConfig = {
        method: "GET",
        headers: new Headers({ "Content-Type": "application/json" }),
        mode: "cors"
    }

    const response = await fetch(`https://jsonplaceholder.typicode.com/posts/`, fetchConfig);

    if (response.ok) {
        try { 
            const data = await response.json();
            dispatch({
                type: "Posts.LOAD_POSTS_SUCCESS",
                payload: {
                    data
                }
            });
            return;
        } catch (error) {
            dispatch({
                type: "Posts.LOAD_POSTS_FAILURE"
            });
        }
    }

    dispatch({
        type: "Posts.LOAD_POSTS_FAILURE"
    });
}

Let's instead abstract away the calling of the API to a new file called apiHelpers.js. This function will take an object as its only argument which contains the following args:

config - the overrides to the fetchConfig such as which REST method to use
dispatch - the dispatch which the thunk has access to
endpoint - the endpoint for the API that you want to query
types - the three strings to use for each of the redux actions put into a tuple. They are in an array so sequence is very important - it goes request, success, failure.

// apiHelper.js
const callAPI = async (args) => {
    const { 
        config, 
        dispatch,
        endpoint, 
        types 
    } = args;

    const [request, success, failure] = types;
    const url = `https://jsonplaceholder.typicode.com/${endpoint}`;

    const fetchConfig = {
        headers: new Headers({ "Content-Type": "application/json" }),
        mode: "cors",
        ...config
    }

    dispatch({
        type: request
    });

    const response = await fetch(url, fetchConfig);

    if (response.ok) {
        try { 
            const data = await response.json();
            dispatch({
                type: success,
                payload: {
                    data
                }
            });
            return;
        } catch (error) {
            dispatch({
                type: failure
            });
        }
    }

    dispatch({
        type: failure
    });
}

export callAPI;

By introducing the tuple for types, we're able to very easily re-use this for other actions. Here's the updated posts actions:

// postsActions.js
const loadPosts = () => async dispatch => {
    callAPI({ 
        config: { method: "GET" },
        dispatch,
        endpoint: "posts",
        types: ["Posts.LOAD_POSTS_REQUEST", "Posts.LOAD_POSTS_SUCCESS", "Posts.LOAD_POSTS_FAILURE"]
    });
}

And the newly added comments actions:

// commentsActions.js

const loadComments = () => async dispatch => {
    callAPI({ 
        config: { method: "GET" },
        dispatch,
        endpoint: "comments",
        types: ["Comments.LOAD_COMMENTS_REQUEST", "Comments.LOAD_COMMENTS_SUCCESS", "Comments.LOAD_COMMENTS_FAILURE"]
    });
}

Up Next:

In the next post we're going to go deeper with Redux and introduce a middleware to handle calling our API and discuss some of the benefits of this approach.

React, Redux, and API's Part Three: Redux

Patrick — Mon, 05 Nov 2018 07:38:10 +0000

original post can be found on my blog

In the last post we looked a bit deeper in to using React to talk to APIs in a DRY manner. In this post, we will look to introduce Redux to manage our application state and talk to our API.

We won’t look at why you might want to redux, but instead we will look at how you can use thunks as interfaces to talk to APIs and move all your logic out of your components that we had in part one and part two.

There’s a bit of assumed knowledge of redux in this post. At the minimum you should understand:

Why you would want to use redux in your application
What an “action” is and does
What a “reducer” is and does
What a “middleware” is and does

It would also help if you have an understanding of thunks.

The Redux docs are fantastic and you should definitely read through those if you are unsure on the above.

Fair warning: this post is a bit long!

Thunks

Thunks are very useful in redux applications as they give you access to state, via a function called getState, and dispatch. It means you can change your action creators from being simple functions that return an object, to a function which returns an inner function that will allow you to check your state or dispatch multiple actions.

Redux-thunk summarises the above as:

Redux Thunk middleware allows you to write action creators that return a function instead of an action. The thunk can be used to delay the dispatch of an action, or to dispatch only if a certain condition is met. The inner function receives the store methods dispatch and getState as parameters.

Cool, so that’s a lot of information so let’s look at what that translates to in terms of code.

Example of traditional Redux action vs. thunk

Let’s take the example of an action to update a customer ID.

// customerActions.js

const updateCustomerID = customerID => {
    type: "Customer.UPDATE_CUSTOMER_ID",
    payload: {
        customerID
    }
}

In this action creator it receives a customerID and then will return an action to update it. But what if the magic business rules said that we only wanted to only update the customerID if there wasn’t one already set in the store?

One way would be to connect your component that was updating the customerID and check there before firing the action off. But what if you had another component that needed to the same thing? Or two? Or three? It would be heavy duplication everywhere.

Thunks allow us to avoid that:

// customerActions.js

const updateCustomerID = customerID => (dispatch, getState) => {
    const state = getState();
    const { customerID } = state.customer;

    if (customerID === null) {
        dispatch({
            type: "Customer.UPDATE_CUSTOMER_ID",
            payload: {
                customerID
            }
        });
    }
}

Here we can use the thunk to check that the customerID is not already set and if it’s not we can update it. This way, we can avoid having to duplicate tonnes of code all over our application.

Talking to APIs with thunks

OK, so that was a lot of background on using thunks, but it was kind of necessary before we talk about how you can use this to talk to APIs.

One particular pattern I like when dealing with APIs in redux is to fire of actions when the request starts, the request successfully completes, and the request fails. This allows you to set up your reducers to handle various different outcomes and in turn you can update your UI. For example, you could show a loading spinner when posts are being fetched from an API.

Here’s how we might talk to the posts API using a thunk:

// postsActions.js

const loadPosts = () => async (dispatch, getState) => {
    dispatch({
        type: "Posts.LOAD_POSTS_REQUEST"
    });

    const fetchConfig = {
        method,
        headers: new Headers({ "Content-Type": "application/json" }),
        mode: "cors"
    }

    const response = await fetch(`https://jsonplaceholder.typicode.com/${endpoint}/`, fetchConfig);

    if (response.ok) {
        try { 
            const data = await response.json();
            dispatch({
                type: "Posts.LOAD_POSTS_SUCCESS",
                payload: {
                    data
                }
            });
            return;
        } catch (error) {
            dispatch({
                type: "Posts.LOAD_POSTS_FAILURE"
            });
        }
    }

    dispatch({
        type: "Posts.LOAD_POSTS_FAILURE"
    });
}

In this sample we fire an action to note that we’re fetching posts, then we fire an action when it successfully completes, and then we also can fire an action if it fails.

Here’s how this translates to our component:

// Posts.js
import React, { Component } from "react";
import { bindActionCreators } from "redux";
import { connect } from "react-redux";

import PostList from "./PostList";
import { loadPosts as loadPostsAction } from "./postsActions";

class Posts extends Component {
    componentDidMount() {
        const { actions: { loadPosts } } = this.props;
                loadPosts();
    }

    render() {
        const { posts } = this.props;

        return (
            <PostList posts={posts} />
        )
    }
}

const mapStateToProps = state => ({
    posts: state.posts
});

const mapDispatchToProps = dispatch => ({
    actions: bindActionCreators({
        loadPosts: loadPostsActions
    })
});

export default connect(mapStateToProps, mapDispatchToProps)(Posts);

You can see we’re no longer coupling our container component to fetching the data, or having to have internal state for the component. This will give us greater flexibility as our application grows in size and complexity.

I’ve deliberately left out the reducers, but essentially it would just need to handle those three actions and update the store accordingly.

Up Next:

In the next post we will look at how we can make this Redux code more DRY as we expand our application to also include actions for comments.

React, Redux, and API's Part Two: React Only (DRY)

Patrick — Sat, 27 Oct 2018 23:52:58 +0000

In the first post of the series, I showed how you can interface with an API in React. One of the main problems with this approach is that if you have multiple containers that need to talk to an API then you will be duplicating a lot of the same code.

In this post, we will take a look at how you can still talk to APIs with React, but in a DRY manner.

Abstract Common Code

Let's look back at the example from the first post:

// Posts.js
import React, { Component } from "react";

import PostList from "./PostList";

class Posts extends Component {
    state = {
        posts: []
    }

    async componentDidMount() {
        const fetchConfig = {
            method: "GET",
            headers: new Headers({ "Content-Type": "application/json" }),
            mode: "cors"
        }

        const response = await fetch("https://jsonplaceholder.typicode.com/posts/", fetchConfig);

        if (response.ok) {
            const posts = await response.json();
            this.setState({ posts });
        } else {
            console.log("error!", error);
        }
    }

    render() {
        const { posts } = this.state;

        return (
            <PostList posts={posts} />
        )
    }
}

Now, imagine we also want to fetch comments from the same API. We would have to copy all the code for handling the config, and responses to a Comments container. You could play that scenario out for however many other different endpoints you need to call for.

An alternative is to abstract the common code. For example let’s create a new file apiHelper.js:

// apiHelper.js
export const SUCCESSFUL_STATUS = "success";
export const FAILED_STATUS = "failed";

const apiHelper = async ({ method, endpoint }) => {
    const fetchConfig = {
        method,
        headers: new Headers({ "Content-Type": "application/json" }),
        mode: "cors"
    }

    const response = await fetch(`https://jsonplaceholder.typicode.com/${endpoint}/`, fetchConfig);

    if (response.ok) {

        try {
            const data = await response.json();

            return {
                status: SUCCESSFUL_STATUS,
                data
            }
        } catch (error) {
            return {
                status: FAILED_STATUS,
                error
            }
        }

    } else {
        return {
            status: FAILED_STATUS
        }
    }
}

export default apiHelper;

Here we’ve moved all the handling from PostList to the helper and made it take some parameters.

Now see how Posts and Comments would look:

// Posts.js
import React, { Component } from "react";

import apiHelper, { SUCCESSFUL_STATUS } from "../utils/apiHelper";
import PostList from "./PostList";

class Posts extends Component {
    state = {
        posts: []
    }

    componentDidMount() {
        const { status, data } = apiHelper({ method: "GET", endpoint: "posts" });

        if (status === SUCCESSFUL_STATUS) {
            this.setState(() => ({ posts: data }));
        }
    }

    render() {
        const { posts } = this.state;

        return (
            <PostList posts={posts} />
        )
    }
}

// Comments.js
import React, { Component } from "react";

import apiHelper, { SUCCESSFUL_STATUS } from "../utils/apiHelper";
import CommentList from "./CommentList";

class Comments extends Component {
    state = {
        comments: []
    }

    componentDidMount() {
        const { status, data } = apiHelper({ method: "GET", endpoint: "comments" });

        if (status === SUCCESSFUL_STATUS) {
            this.setState(() => ({ comments: data }));
        }
    }

    render() {
        const { comments } = this.state;

        return (
            <CommentList comments={comments} />
        )
    }
}

As you can see there is minimal work required to make this much more flexible without repeating ourselves.

Bonus

What if you wanted to interface with multiple APIs but keep the duplication minimal? Here’s an example of how you might refactor apiHelper.js to do just that:

// apiHelper.js
export const SUCCESSFUL_STATUS = "success";
export const FAILED_STATUS = "failed";

const buildAPIHelper = (args) =>  async ({ method, endpoint }) => {
    const {
        baseURL,
        headers = new Headers({ "Content-Type": "application/json" }) // some sane defaults
    } = args;

    const fetchConfig = {
        method,
        headers,
        mode: "cors"
    }

    const response = await fetch(`${baseURL}${endpoint}`, fetchConfig);

    if (response.ok) {

        try {
            const data = await response.json();

            return {
                status: SUCCESSFUL_STATUS,
                data
            }
        } catch (error) {
            return {
                status: FAILED_STATUS,
                error
            }
        }

    } else {
        return {
            status: FAILED_STATUS
        }
    }
}

export const firstAPIHelper = buildAPIHelper({ 
    baseURL: "https://jsonplaceholder.typicode.com/",
});

export const secondAPIHelper = buildAPIHelper({
    baseURL: "https://api.patrick-gordon.com/" 
    headers: new Headers({ "Content-Type": "application/json", "Authorization": "bearer someKey" })
});

Up Next

In the next part of the series we will introduce Redux into the mix and look at how we can talk to an API using Redux.

Until then, cheers,

-- Patrick.

React, Redux, and API's Part One: React Only

Patrick — Thu, 25 Oct 2018 20:26:10 +0000

When building a web application using React, there's a very strong likelihood you will need to interface with an API. It may be one that you or your company have built, or it might be one provided by a 3rd party. Regardless, you're going to want to retrieve data from it and display that data to your users.

This series will cover the different ways for your React and, later, React/Redux app to talk to an API, as well as the and the pros and cons of each approach.

This first post will be very simple and cover using only React.

Fetching in a Container

The first way you might try to retrieve data is to make your fetch call directly inside your container component. Suppose you want to display a list of Posts and your container renders a PostList component which takes a prop of posts.

This might look something like this:

import React, { Component } from "react";

import PostList from "./PostList";

class Posts extends Component {
    state = {
        posts: []
    }

    async componentDidMount() {
        const fetchConfig = {
            method: "GET",
            headers: new Headers({ "Content-Type": "application/json" }),
            mode: "cors"
        }

        const response = await fetch("https://jsonplaceholder.typicode.com/posts/", fetchConfig);

        if (response.ok) {
            const posts = await response.json();
            this.setState({ posts });
        } else {
            console.log("error!", error);
        }
    }

    render() {
        const { posts } = this.state;

        return (
            <PostList posts={posts} />
        )
    }
}

Here's a working jsFiddle of this example: https://jsfiddle.net/patrickgordon/69z2wepo/142592/

In the above example we are first defining our components local state with an empty array for posts. This is what we will use to pass to our PostList component. We're then using the lifecycle method componentDidMount to fire off a fetch with some standard configuration. If you're unfamiliar with promises and async/await, this part may look confusing but essentially we are waiting to get a response from the API and then using this.setState to update the component state with the JSON response from the API. This triggers a re-render and the data is then displayed in the list to the user.

Pros and Cons

This approach is great if you are only in need of a quick and easy way to access data in a small React app. However, it will start to get pretty frustrating as your app grows. For example, suppose you want to add multiple routes to your app using something like react-router. When you navigate away from this page, and then navigate back, every time you hit the page it will fire the fetch inside of componentDidMount. This would be undesirable for many reasons, but not limited to:

Unncessary network requests
Causing multiple re-renders of your app
Lots of duplicate code

Additionally, the data retrieved from this API is only good for this component heirarchy. What if you wanted to have a Navigation bar which had a number which counted how many posts you have? You would also need to make it fetch and retrieve all your posts too. Which means lots of wasted network requests and lots of duplicated code.

Up Next

In the next part of this series I will explain how to use utility functions to ensure code-reuse when dealing with APIs in React only.