DEV Community: Markus Claus

Hooked on React hooks

Markus Claus — Sun, 17 Mar 2019 17:36:08 +0000

Whenever I read about a new feature in React, I'm all over it. I try to understand what's going on and how I could apply this new feature to my projects.

Hooks is one of the newest features of React. It was introduced in React 16.8 and it allows you to use state and lifecycle features in components which are not a class.

To use React Hooks you need to update React to version 16.8 or higher. Don't forget to also update react-dom and, if you use it, react-hot-loader. You will run into some strange errors if you don't update the hot loader.

The state hooks

As you may know in the pre 16.8 days, if you wanted to use state you needed to do something like this:


import React, {Component} from 'react';

class Something extends Component {

    constructor(props){
        super(props);

        this.state = {
            foo: 'bar'
        }

        this.setFoo = this.setFoo.bind(this);
    }

    setFoo(newFoo) {
        this.setState({...this.state, foo: newFoo});
    }

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

        return (
            <div>
                <span>{foo}</span>
                <button onClick={this.setFoo('theRealFoo')}>Set Foo</button>
            </div>
        );
    }

}

export default Something;

This example contains much code that is necessary to make the class in JavaScript work. To use this in the right context, you need to give the function some special attention. The same example would look like this with hooks:


import React, {useState} from 'react';

const Something = () => {

    const [foo, setFoo] = useState("bar");

    return (
        <div>
            <span>{foo}</span>
            <button onClick={setFoo('theRealFoo')}>Set Foo</button>
        </div>
    );
}

export default Something;

As you can see, the amount of code is significantly less. In this case useState is a hook provided by React. It is a function which returns a state value and a function which is used to update it.

So there is no need for setState anymore. React takes care of everything.

useState takes a parameter which is the initial value for the state field.

Now sometimes state can become complex and you might need more than one variable for it. To manage this, you can use multiple useState calls to create multiple state variables or you can use an object like you did with classes before.

I tried both ways and I think single variables are much easier to handle, because you don't need to do all the nested object merging as you might have done before.

Also React has another hook called userReducer, which comes in handy when you have complex state handling. As in Redux, you use a function which takes the state and an action to update the state.


import React, {useReducer} from 'react';

const csReducer = (state, action) => {
    switch(action.type) {
        case 'foo': {
            return 'foo';
        }
        case 'bar': {
            return 'bar';
        }
        default: {
            return state;
        }
    }
}

const ComplexSomething = (props) => {
    const [someState, dispatch] = useReducer(csReducer, props.someState);

    return (
        <div>
            <span>{someState}</span>
            <button onClick={dispatch({type: 'foo'})}>Say Foo!</button>
            <button onClick={dispatch({type: 'bar'})}>Say Bar!</button>
        </div>
    )
} 

export default ComplexSomething;

You can see that the whole state handling is in the csReducer. It takes the action and depending on the type, it returns another value for the state. You can also send a payload {type: 'someAction', payload: 'foobar!'} to put maybe a fetched information into the state. If you return the state as it was given, React does not change the state and no rerenders are triggered.

As you can see, the state handling is pretty awesome. Either you do some easy stuff with useState or you start to raise the stakes with useReducer.

Lifecycle with hooks

Now that we can handle our state, you probably remember that I also mentioned you could do the lifecycle stuff with hooks. Let's talk about this.

There is a hook called useEffect. It is called like this, because most things you do in the lifecycle methods, fetching data, adding events to the DOM or something like that, all this is called "side effects", hence useEffect.

Let's have an example:


import React, {useState, useEffect} from 'react';
import Spinner from './Spinner';

const EffectComponent = (props) => {

    const [pending, setPending] = useState(true);
    const [product, setProduct] = useState({});

    useEffect(() => {
        setPending(true);
        fetch(`https://myapi.api/product/${props.id}`).then((productData) => {
            setProduct(productData);

            setPending(false);
        })
    }, [props.id]);

    if(pending === true) return <Spinner />

    return (
        <div>{product.name}</div>
    )

}

export default EffectComponent;

At first we define our two state variables pending and product. Then we use useEffect to fetch data. The function sets pending to true and then loads data from an API. After the data arrived, it sets our product state and then pending to false, so our component will render.

The effect is called every single time the component renders. If you have used componentDidMount and componentWillUpdate before you know that it is a pain to manage when data should load and when not. With useEffect there is an easy solution to that. The second parameter is an array with variables. The effect will only fire if the variables in the array have changed. In the above example I do [props.id], so the effect will only fire every time props.id changes.

You can also return a function in useEffect which will be called when the component is unmounted. You can do some cleanup stuff there.

A new way to share stateful logic

In the last versions of React there were two ways to share stateful logic between components. Render props and higher order components. Both are fine and they work well, but getting the concept... Phuuu... I tried to explain both a hundred times to different people and maybe 50% got it.

When using React 16.8 you can use hooks to share stateful logic between components. This way is much simpler, because a hook is just a function... and everyone understands functions, right?

To share the logic, we can build our own custom hooks and call them, just like we call the prebuilt hooks.


import React, {useState} from 'react';

// This is the custom hook
function useFetchData(url, setData) {
    const [pending, setPending] = useState(true);
    const [error, setError] = useState(null);

    useEffect(() => {
        setPending(true);
        fetch(url).then((productData) => {
            setData(productData);

            setPending(false);
        }).catch(error =>{
            setError(error);
        })
    }, [url]);

    return {pending, error};
}

const EffectComponent = (props) => {
    const [product, setProduct] = useState({});

    // and here we call it.
    const {pending, error} = useFetchData(`https://myapi.api/product/${props.id}`, setProduct);

    if(pending === true) return <Spinner />

    return (
        <div>
            <span>{product.name}</span>
            {error && <span class="error">{error}</span>}
        </div>
    )

}

export default EffectComponent;

Look at the example above. What I did there is take away the logic for fetching data and put it into a function, this function is the custom hook. The convention is to start every hook with use and then your function name. Instead of rewriting the fetch logic, I now can simply use my useFetchData hook.

I think this concept is much easier to grasp. You just put everything in a function, you call it hookand you are done with it.

The rules of hooks

Now hooks have some specific things you need to know before you use them. The React people call them "Rules of Hooks".

In fact, there are only two:

1.) You can use hooks only in function components

There is one exception to this rule. You can use hooks in your custom hooks.

2.) You can't use hooks in any kind of loop, nested functions or within conditions.

The last one is because React remembers in which order you used the hooks and it uses this order to give you the correct data or do the correct stuff.

For example:


const [varA, setVarA] = useState(1);
const [varB, setVarB] = useState(2);
const [varC, setVarC] = useState(3);

This works fine. Whenever the component is called, the order of the hooks is the same. Whenever you use varC, it is the value 3.


const [varA, setVarA] = useState(1);
if(varA === 2) {
    const [varB, setVarB] = useState(2);
}
const [varC, setVarC] = useState(3);

This one is a problem. The moment varA is 2, the order of the hooks changes and therefore things will go wrong.

There are others

Yes, there are others... in fact, there are a whole bunch of other React Hooks. But I think they are more edge case hooks you probably don't need that often, if ever. useMemo could come in handy, if you want to do some heavy lifting within a function in the render process of your component. It takes a function and an array of values. The function only runs if the values in the array change. Otherwise it will return the memoized value. You can read up on memoization here.

One hook looks really interesting, though. useContext I have to do some more testing with this one, but I think it will make use of Reacts' Context API much easier than it is right now.

Well, that's it for this post. I hope you learned something, I hope you enjoyed it at least a little bit. If you got tips or comments, feel free to post them.

Thank you for reading!

Server-side rendering with React (and Redux)

Markus Claus — Fri, 15 Mar 2019 09:58:24 +0000

When I first started react, I was amazed by how powerful the library was. I was building component after component and when I came upon a share component for Facebook, I noticed "Oh, there is no content on the page at all!"

That's not good. Is it? So what's up with that?

Most automated site crawlers don't execute JavaScript before they read the website.
(Google might, but I couldn't confirm it). And with React there is no content on the page before your JavaScript is executed. That means that crawlers can't see anything on your website.

Also, React isn't the fastest way to get content to your visitors. If you look into the network tab in your browsers developer tools, you will notice that it requests the page, then the JavaScript bundle - it is executed, and in most cases after that, the real content is requested by your React app.

These are a lot of calls happening before your visitor can see any content.

So, with these two problems in mind, what can we do?

Server-side rendering in a nutshell

There is a super cool technique called server-side rendering. What it does is pretty simple: It executes your React app on the server and sends the HTML result to your visitor's client. The client renders the HTML and then requests your JavaScript. Rather than rendering the app again, it hydrates the HTML, already sent, with all the functions you got in your React app.

With this approach the content does not need any JavaScript execution by the client to show. Also, you dont need three requests for the content to arrive. Everything the visitor should see is sent with the initial call.

Getting ready

The above explanation sounds pretty simple. Unfortunately, it isn't. The implementation has some complex parts we need to understand, but I try to keep them as simple and well explained as I can.

Before we start, you need to install webpack, webpack-cli, webpack-merge, webpack-node-external, express, babel, babel-preset-env, babel-preset-react, babel-loader and of course react and react-dom. That should do it, for now.

Now we need to set up Webpack. Webpack is a module bundler. Most of you people use it, I suppose, or at least have heard of it. I don't want to go to deep into webpack, it's large enough for its own article (...or five).

For the purpose of server-side rendering, we will use a more complex setup for our webpack. We are going to split the webpack configuration into multiple files, so we do not need to repeat to much code.

In the end we'll need two webpack setups. One for our server-side code and one for the client. These two files have much in common, so we create one file called webpack.base.js which contains most of the configuration both setups share.



// webpack.base.js

module.exports = {
  stats: {
    colors: true,
    reasons: true,
    chunks: false
  },
  module: {
    rules: [
      {
        test: /\.jsx?$/,
        loader: 'babel-loader',
        exclude: /node_modules/
      },
    ]
  }
}

What you see here is a standard configuration for webpack. You export a JavaScript object which contains several configuration information for webpack. The stats part is for some fixes in the output of webpack, the module part tells webpack what type of loaders it should use when encountering a file which fulfills the "test" regex. A loader is a function which transforms the content of the file in some ways.

Okay, I was talking about more than one setup. Let's do the server-side first, because we start working on the server very soon.



// webpack.server.js

const path = require('path');
const merge = require('webpack-merge');
const baseConfig = require('./webpack.base.js');

const config = {
    target: 'node',
    entry:  ['./index.js'],
    output:  {
        filename: 'server.js',
        path: path.resolve(__dirname, 'build'),
    },
    resolve: {
        extensions: ['.js', '.json']
    },
}

module.exports = merge(baseConfig, config);

This is our server-side configuration, right at the end of the file you can see, that we merge the baseConfig object from our webpack.base.js file with the content in this file to get our final webpack config for the server side.

The entry key tells what the starting point webpack should look for code. And the output key tells it to where the bundled file should be saved to.

Before we are getting into our server app, let's set up Babel real fast:



// .babelrc

{
    "presets": [
        "react",
    ["env", {
        "targets": {
            "browsers": "last 2 versions"
        },
            "useBuiltIns": "usage",
        "loose": true,
        "modules": false
        }]
    ],

}

I can't go into details what this is doing. The article would grow far too big. In few words, it sets up Babel to understand common react stuff.

And let's tell npm about webpack and the setup we just created. In the script section of your package.json add:



// package.json add to scripts

{
    scripts: {
        ...
        "server": "webpack --watch --config webpack.server.js --mode development"
    }
}

Let's get coding

The next step is to set up some kind of server to respond to our visitor's requests. I will use Express for this article but you can use any server you want.

Let's install Express using npm install express.

After that we set up a server:



// index.js

import express from 'express';
const app = express();

app.use(express.static('public'));

app.get('*', (req, res) => {
    // Here we are going to handle that react rendering and stuff.
});

app.listen(3000, () => {
    console.log('Server is listenting to port 3000');
});

What we did - we set up an express server, which is listening on port 3000. We added public as a folder for static resources. We also created a GET route with a wildcard. In this case it means that every call made is matched with this route.

You may have noticed that I bring in Express via import rather than require. That's because we want to write Isomorphic JavaScript. That's JavaScript that can be run on the server and the client without changes.

Now we want to create something we can actually render on the server. Let's do some kind of Homepage view component the user should see when he visits our app.



// client/Homepage.js

import React from 'react';

class Homepage extends React.Component {

    render() {
        return (
            <div class="wrapper">
                <h1>Welcome, this is the homepage</h1>
                <button onClick={() => console.log("I', clicked!"}>
                    Click me!
                </button>
            </div>
        )
    }

}

export default Homepage;

Pretty simple, isn't it? The only thing I want to note here is that I put all the client code into a folder client. Always keep your code well sorted, people!

We got our server, we got our React component, let's bring those together.



// renderer.js

import { renderToString } from 'react-dom/server';
import Homepage from './client/Homepage';

function renderer() {

    const content = renderToString(
        <Homepage />
      );

    return content;
}

export default renderer;

To keep everything nice and clean, we put our rendering code into a function called renderer. As you can see, it imports a special function from react-dom/server called renderToString(). Render to string is similar to render() you propably know about. It renders the component a single time and converts it into a HTML string.

After that we call renderer() in our Express server and send the result back to the visitor.



// index.js

import express from 'express';
import renderer from './renderer';

const app = express();

app.get('*', (req, res) => {
    const result = renderer();
    res.send(result);
});

app.listen(3000, () => {
    console.log('Server is listenting to port 3000');
});

Voilá, the first rendered React component on the server. You will notice that no matter which route you call, the Homepage component is rendered every time. That's okay for now, we tackle this one in a minute. For now be happy, we got server-side rendering up and running.

Where has my JavaScript gone?!?

You probably tried to use the button on the homepage and you might have noticed "Oh, there is no console log... Where has my JavaScript gone!?!".

It's gone because of renderToString(). It renders a HTML string, but it removes every bit of JavaScript. To fix this, we need to create a client bundle for our app and request it from the visitors client as soon as it receives the HTML code.

To do this, let's go back to Webpack. We need the earlier mentioned client-side setup. We are doing this because some of the server code is not necessary on the client or maybe we have some super secret business logic in there we don't want to share or maybe API secrets... You get the point.



// webpack.client.js

const webpack = require('webpack');
const path = require('path');
const merge = require('webpack-merge');
const baseConfig = require('./webpack.base.js');

const config = {
    context: __dirname,
    entry: ['./client/index.js'],
    output: {
        path: path.join(__dirname, 'public'),
        filename: 'bundle.js',
    publicPath: '/',
    pathinfo: false,
    },
    resolve: {
        extensions: ['.js', '.json', '.scss']
    },
    optimization: {
        minimize: true
    },
};

module.exports = merge(baseConfig, config);

As with the server-side before, we build a client configuration and then merge it with our base configuration. Important to note is, that we use another entry point and we create another output file. So, after running webpack in both configurations we end up with two files: server.js and bundle.js

To start webpack we need to add a new script to npm:



// package.json add to scripts

{
    scripts: {
        ...
        "client": "webpack --watch --config webpack.client.js --mode development"
    }
}

For webpack to actually build our bundle.js we need to write it first. So here we go:



// client/index.js

import React from 'react';
import ReactDOM from 'react-dom';
import Homepage from './homepage';

const jsx = <Homepage />

ReactDOM.hydrate(jsx, document.getElementById('app'));

This is a pretty standard setup for a React app. We use our Homepage component and we are rendering it into a div with the ID "app". Because we are talking about the client-side here, when this code arrives, the page is already rendered. To make React understand, we don't want it to rerender the whole thing, we need to use hydrate instead of render to tell React to just put some life in our HTML code.

Now we have our JavaScript file to serve to the client, but the file is still not showing up when we refresh our page. That's because we need to tell the client to actually request the client.js file. To do this, we add a little bit of code to our renderer() function:



// renderer.js

import { renderToString } from 'react-dom/server';
import Homepage from './client/Homepage';

function renderer() {

    const content = renderToString(
        <Homepage />
      );

    const jsx = `
        <!DOCTYPE html>
        <html>
        <head>
            <meta charset="utf-8">
            <meta name="viewport" content="width=device-width, initial-scale=1">
        </head>

        <body>
            <div id="app">${content}</div>
            <script src="/bundle.js"></script>
        </body>
        </html>
    `;

    return jsx;
}

export default renderer;

Our renderer returns no simple React component anymore, but a complete website with the bundle.js included. As soon as the client renders the HTML code, it will request our JavaScript with the whole code and the button you wanted to create will start working. Or at least it should ;)

Routers, routers everywhere!

Now that we got a real React app in the frontend rendered by our server, we can talk about the routing problem. Do you remember? No matter what route we use, we always end up on our Homepage. To solve this we install a tool called react-router. I assume you people know how a BrowserRouter works. The thing is... We can't use a BrowserRouter because it's specifically used to render routes depending on the browser url. But we got no browser on the server. So we are in a bit of a pickle here.

What we are going to do is, we use a StaticRouter for the server part instead and good ol' browser router for the frontend.

But we don't want to write two seperate route declarations whenever we add a new route to our software, do we?

So let's put all our routes in one file and use this to configure both routers. To do this there is a little tool called react-router-config. It allows us to write an configuration array and provides a function to render the routes.



// routes.js

import Homepage from './client/Homepage';
import AboutUs from './client/AboutUs';

const routes = [
    {
        component: Homepage,
        path: "/",
        exact: true
    },
    {
        component: AboutUs,
        path: "/",
        exact: true
    }    
]

export default routes;

Each object in the array takes the same parameters as a Route component from react-router would do.

In our client code we now can do the following to get our BrowserRouter:



// client/index.js

import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter as Router } from 'react-router-dom';
import { renderRoutes } from 'react-router-config';

import routes from '../routes.js';

const jsx = (
    <Router>
      <div class="wrapper">{renderRoutes(routes)}</div>
    </Router>
);


ReactDOM.hydrate(jsx, document.getElementById('app'));

We use
renderRoutes from react-router-config and pass it our routes array. The result will be a completly rendered pack of Route components.

The server-side is a little bit more complex. Here we use the StaticRouter. The static router has no browser url, so we need to pass it a request, where it can get the neccessary information which route we want to render.

The request is passed from our express app into our renderer function we wrote earlier to render the website.



// renderer.js

import { renderToString } from 'react-dom/server';
import { StaticRouter as Router } from 'react-router-dom';
import { renderRoutes } from 'react-router-config';

import routes from './routes.js';

function renderer(req) {

    const context = {};

    const content = renderToString(
        <Router context={context} location={req.path} query={req.query}>
            <div>{renderRoutes(routes)}</div>
        </Router>
    );

    const jsx = `
        <!DOCTYPE html>
        <html>
        <head>
            <meta charset="utf-8">
            <meta name="viewport" content="width=device-width, initial-scale=1">
        </head>

        <body>
            <div id="app">${content}</div>
            <script src="/bundle.js"></script>
        </body>
        </html>
    `;

    return {jsx, context};
}

export default renderer;

As you can see, we do pretty much the same as on the client side but we use the StaticRouter instead. We pass it the location from the request so it can determine what to do. Also we give it a query so we can react on paramters in the request. The last thing is the context. The context is accessible in the component the router renders. You can use it for error handling or to set a status for the page rendered.

For example, let's say you want to load a product from an API and the requested product is not there. You want the initial call from the server answer with a 404 status code instead of a 200. That's where you can use the context. In the component just set the context.status = 404 and after the rendering set res.status(context.status) like this:



// index.js

import express from 'express';
import renderer from './renderer';

const app = express();

app.get('*', (req, res) => {
    const result = renderer(req);
    const context = result.context;
    if(context && context.status !== undefined) {
        res.status(context.status);
    }
    res.send(result.jsx);
});

app.listen(3000, () => {
    console.log('Server is listenting to port 3000');
});

And here we go. The routing in your app works. Client-side as well as server-side. When new routes are created, all you need to do is to add them into the routes array and both routers know what to do.

Getting the Redux on

Do your brains hurt right now? No? Good. Because I saved the most annoying (yes, annoying!) part for last: Redux.

In fact, it's not just Redux I want to talk about last, I want to talk about all sorts of async data fetching when rendering a React app server-side. The problem is, as you remember, we use renderToString to prerender our page and then send it to the client. But renderToString does render everything just once and therefore does not care about data we might need to fetch from an API before it renders. But we want search engines and possibly other tools to have those juicy data parts we are missing.

So what we need to do is in fact get all the data we need to render a complete view before we actually call renderToString. So, for every view we need to put together, some kind of "content fetch" function which loads every single piece of content the requested view needs.

Then, after the content is available, we need to pass the data to our React app and then, with everything available, call renderToString.

First we put Redux in the mix: npm install redux react-redux redux-thunk

Now that we have installed Redux, let's first do the easy part, the frontend.

We are going to use a somehow non-standard approach here, but you will understand why we do it like this in the end.




// createStore.js

import { applyMiddleware, createStore } from 'redux';
import thunk from 'redux-thunk';

import rootReducer from './rootReducer';

const middleware = applyMiddleware(thunk);

export default initialState => createStore(rootReducer, initialState, middleware);

We wrote a function that takes an initialState and returns the created store. We will use this on the client- and server-side as well.



// client/index.js

import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter as Router } from 'react-router-dom';
import { renderRoutes } from 'react-router-config';

import {Provider} from 'react-redux';

import createStore from '../createStore';
import routes from '../routes';
import rootReducer from '../rootReducer';

const store = createStore({});

const jsx = (
    <Provider store={store}>
        <Router>
          <div class="wrapper">{renderRoutes(routes)}</div>
        </Router>
    </Provider>
);


ReactDOM.hydrate(jsx, document.getElementById('app'));

We created a store with our new createStore() function and wrapped the app in a Provider.

To have everything go as we plan, we need to have all the data we need for the view to render after we are finished with our data loading process. As long as you have a view component, where all the data is loaded and then passed down to child components, it's pretty easy to spot what we need to load. If you have many components in your view that load data by themselves, it can get hard not to forget some fetches here and there.

To give us an opportunity to load data, we need a function that is loading the data so we can call that before we render. To achieve this, we need to rewrite our view component a little bit.

I added a connection to the Redux store. I don't want to talk about how to do this and what this all means, I wrote an article about it a week ago.

Fetching data from an api using React/Redux

Markus Claus ・ Mar 5 '19

#react #javascript #beginners #webdev

Feel free to read it!



// client/Homepage.js

import React from 'react';
import {bindActionCreators} from 'redux';
import {connect} from 'react-redux';

import fetchSomeData from './somewhere';

class Homepage extends React.Component {
    componentDidMount() {
        const {fetchSomeData: doFetch} = this.props;
        doFetch();
    }

    render() {
        return (
            <div class="wrapper">
                <h1>Welcome, this is the homepage</h1>
                <button onClick={() => console.log("I', clicked!"}>
                    Click me!
                </button>
            </div>
        )
    }

}

const mapStateToProps = state => ({
    someData: getSomeData(state);
})

const mapDispatchToProps = dispatch => bindActionCreators({
    fetchSomeData,
}, dispatch);


function loadData(store, match, cookie) {
    const actionToBeDispatched = [];
    actionToBeDispatched.push(store.dispatch(fetchSomeData()));

    return Promise.all(actionsToBeDispatched);
}

export default {
  loadData,
  component: connect(mapStateToProps, mapDispatchToProps)(Homepage),
};

In this code example there are two things that are really important. First we got the loadData() function. Its purpose is to load every single bit of data we need. loadData() returns a Promise which lets us know when everything is done.

Also, we don't export our component like we did before, but we export an object with the loadData() and the component itself. This object will be split in our routes so every route still has a component but also got a loadData key.



// routes.js

import Homepage from './client/Homepage';
import AboutUs from './client/AboutUs';

const routes = [
    {
        ...Homepage,
        path: "/",
        exact: true
    },
    {
        ...AboutUs,
        path: "/",
        exact: true
    }    
]

export default routes;

Okay, let's bring everything together!



// index.js

import express from 'express';
import { matchRoutes } from 'react-router-config';
import renderer from './renderer';
import createStore from './createStore';

const app = express();

app.get('*', (req, res) => {
    const store = createStore({});
    const promises = matchRoutes(routes, req.path).map(
        ({ route, match }) => (route.loadData ? route.loadData(store, match,             req.get('cookie') || {}, req.query) : null)
    );

    Promise.all(promises).then(() => {
        const result = renderer(req, store);
        const context = result.context;
        if(context && context.status !== undefined) {
            res.status(context.status);
        }
        res.send(result.jsx);
    });
});

app.listen(3000, () => {
    console.log('Server is listenting to port 3000');
});

In our route we create a store using createStore we wrote earlier. Then we use a function called matchRoutes() which takes our routes array and the requests path. It returns an array of matched routes. Every item contains the route and the match data from react-router.

With this we can call our loadData() function which is part of the routes object and wait for it to finish loading data. After that we pass the store to our renderer() function to redner everything properly.

loadData() in this example takes a cookie and a query parameter. They are not neccessary, but I decided to leave them in there so you poeple can see how you would add a cookie or query parameters to your loadData() function.

We are nearly done. Last thing to do is to make sure that the client is in the same state as the server when it loads up. Right now the server would set up everything correctly, then send it to the client. But the client would mess things up, because it has no idea what the server-side store contains. So we need to send the store to the client.

Let's update our renderer()



// renderer.js

import { renderToString } from 'react-dom/server';
import { StaticRouter as Router } from 'react-router-dom';
import { renderRoutes } from 'react-router-config';

import routes from './routes.js';

function renderer(req, store) {

    const context = {};
    const state = store.getState();

    const content = renderToString(
        <Router context={context} location={req.path} query={req.query}>
            <div>{renderRoutes(routes)}</div>
        </Router>
    );

    const jsx = `
        <!DOCTYPE html>
        <html>
        <head>
            <meta charset="utf-8">
            <meta name="viewport" content="width=device-width, initial-scale=1">
        </head>

        <body>
            <div id="app">${content}</div>
            <script>
                window.STORE_DATA = ${JSON.stringify(state).replace('<script>', '')}
            </script>
            <script src="/bundle.js"></script>
        </body>
        </html>
    `;

    return {jsx, context};
}

export default renderer;

We use JSON.stringify() to put the whole store into one variable.
We remove any script tags, because they would mess up things and are potential security issues.

Do you remember that we wrote a function called createStore() which didn't make that much sense back there because...duhh... redundant? Now that our state is in a variable, we can take that state and put it into our createStore() function to create a store from this state. And the penny drops ;)



// client/index.js

import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter as Router } from 'react-router-dom';
import { renderRoutes } from 'react-router-config';

import {Provider} from 'react-redux';

import createStore from '../createStore';
import routes from '../routes';
import rootReducer from '../rootReducer';

const store = createStore(window.STORE_DATA);

const jsx = (
    <Provider store={store}>
        <Router>
          <div class="wrapper">{renderRoutes(routes)}</div>
        </Router>
    </Provider>
);


ReactDOM.hydrate(jsx, document.getElementById('app'));

Okay. That's it. It was a long road, but we are finally at the end. Our React app is working, the routing is set up, the Redux store is there and we have a server-side rendered app that is hydrated on the client. You can test this by deactivating JavaScript in your browser. The page should show just as you want it to be, but without any JavaScript functions.

There are a few things I didn't tackle here. What about authentication at the frontend. You can make this work using cookies, but it's still a little bit tricky. The article is long enough, maybe I will talk about this another time.

As always, I hope you learned something, I hope you enjoyed reading the article and if you did, feel free to like it or leave a comment. I always appreciate hints, tips or just a friendly "hello".

Thanks for reading!

Fetching data from an api using React/Redux

Markus Claus — Tue, 05 Mar 2019 16:21:25 +0000

Starting simple

This is my first post here. I decided to share some of the knowledge I earned through making every mistake you can possibly make -.- Everything I write here I have learned by reading blog posts, trying to understand what was done and trial and error. If there are mistakes or if you think of a better way to do things, please let me know in the comments. I always appreciate helpful tips!

Now, first things first. You need to install React and Redux. I assume you know how to do that. After you've set up your React application you need to install a tool called redux-thunk by using the command npm install redux-thunk

With all those installed, we can now look at the components we're going to need to make the magic happen!

What is this thunk thing?

Basically a thunk is a function called by another function. Wait... What? Yeah, that's how I reacted the first time I heard this statement. Let me show you an example:

function some_function() {
    // do something
    return function thunk() {
        // do something thunky later
    }
}

So, some_function is called, it does something and then it returns a new function with commands and possibly data for later execution.

Now what about Redux?

I don't want to go into the deepest depths of redux (most likely I couldn't anyway), so just a short explanation: It's a state container for javascript applications. It holds all the data you need for your application in one place. Every component within your application has its space in the state container where it looks for data. When the data changes, the component will change, too.

Actions

The idea is that you dispatch actions onto redux, and based on those actions the state is modified.

The funny thing is: An action doesn't do anything. It sounds like there is stuff going on, but there isn't. An action is just a plain object with a type key. Like this one:

// this is an action
{
    type: "SOME_ACTION",
    payload: {}
}

Most of the time you don't want to write the same object over and over, so there is a concept called Action Creators.

Action Creators

Action Creators do exactly what they sound like, they create the action objects for you.

const SOME_ACTION = "SOME_ACTION";

function create_action(data) {
    return {
        type: SOME_ACTION,
        payload: data
    }
}

So with those action creators you can now easily use the SOME_ACTION by calling create_action(data). Those action creators can be dispatched to redux by using dispatch(create_action(data)).

Reducers

After an action is dispatched, it will be passed onto a so called reducer. A reducer is a function which is given a state and an action. Depending on the action it will transform the state and then return the new state.

function someReducer(state, action) {
    switch(action.type) {
        case SOME_ACTION:
            return {
                ...state,
                data: action.payload
            }
        break;

        default:
            // the dispatched action is not in this reducer, return the state unchanged
            return state;
    }
}

More complex applications most likely have multiple reducers, each one responsible for a single part of the state. So it is important to never forget the default case where the reducer returns the state unchanged.

Important to notice that reducers are pure functions. They never call something like an API or dispatch another action to redux.

You talked about thunks!?

You remembered that. Okay, thunks again. I just mentioned that reducers are pure. But often we want to have some kind of API call or dispatch something depending on data or whatever... But we can't... reducers are pure... Redux-Thunk to the rescue!

Redux-Thunk is pretty easy to understand. It is a so-called middleware for the redux store. It looks at every single action being dispatched and if it is a function, it calls the function. There is nothing more to it. But this opens up a whole new world of fancy "actions" which are dispatched to redux.

You might ask, how do I get this little wonder into my store?

import { applyMiddleware, createStore } from 'redux';
import thunk from 'redux-thunk';

import rootReducer from './rootReducer';
import initialState from './initialState';

const middlewares = [thunk];

createStore(rootReducer, initialState, applyMiddleware(...middlewares));

Let's get some products

We want to load some products from our API. To do this, we first set our component in some kind of pending state, we show a loading spinner or something like that. Then we load the data and we decide whether or not we can just show the product list or display some kind of error message-

We start with setting up our action creators.


// action.js

export const FETCH_PRODUCTS_PENDING = 'FETCH_PRODUCTS_PENDING';
export const FETCH_PRODUCTS_SUCCESS = 'FETCH_PRODUCTS_SUCCESS';
export const FETCH_PRODUCTS_ERROR = 'FETCH_PRODUCTS_ERROR';

function fetchProductsPending() {
    return {
        type: FETCH_PRODUCTS_PENDING
    }
}

function fetchProductsSuccess(products) {
    return {
        type: FETCH_PRODUCTS_SUCCESS
        products: products
    }
}

function fetchProductsError(error) {
    return {
        type: FETCH_PRODUCTS_ERROR
        error: error
    }
}

Now that we have our action creators, let's set up our reducer for the whole thing.


// reducer.js

import {FETCH_PRODUCTS_PENDING, FETCH_PRODUCTS_SUCCESS, FETCH_PRODUCTS_ERROR} from './actions';

const initialState = {
    pending: false,
    products: [],
    error: null
}

export function productsReducer(state = initialState, action) {
    switch(action.type) {
        case FETCH_PRODUCTS_PENDING: 
            return {
                ...state,
                pending: true
            }
        case FETCH_PRODUCTS_SUCCESS:
            return {
                ...state,
                pending: false,
                products: action.payload
            }
        case FETCH_PRODUCTS_ERROR:
            return {
                ...state,
                pending: false,
                error: action.error
            }
        default: 
            return state;
    }
}

export const getProducts = state => state.products;
export const getProductsPending = state => state.pending;
export const getProductsError = state => state.error;

Okay, now we have a big part of the work done.

What's to note in the code above, are the three functions at the end of the reducer. Those are called selectors. Selectors are used to get defined parts of the state. In small applications they are overkill. But if you scale your app and it gets more and more complex, it gets really messy if you change something within your state. With selectors you need to change the selector and everything works fine.

I'll propably do a blog post about selectors, because I think they are really important to set up a scalable react/redux application.

Now where were we... Ah yes, big part of the work is done. The only thing left for us to do on the redux side is to write one of our fancy new actions.


// fetchProducts.js

import {fetchProductsPending, fetchProductsSuccess, fetchProductsError} from 'actions';

function fetchProducts() {
    return dispatch => {
        dispatch(fetchProductsPending());
        fetch('https://exampleapi.com/products')
        .then(res => res.json())
        .then(res => {
            if(res.error) {
                throw(res.error);
            }
            dispatch(fetchProductsSuccess(res.products);
            return res.products;
        })
        .catch(error => {
            dispatch(fetchProductsError(error));
        })
    }
}

export default fetchProducts;

The action above is pretty simple. First we dispatch our pending action. Then we fetch the data from our API. We decode the json coming in into an object. Then we check for an error. If an error happend we throw it and call our error function. If everything went okay, we call the success action. The reducer handles the rest.

This is all about fetching data from a server...Nah, just kidding, it isn't. But this is how most posts about fetching data from an api end, right? But...

What about our application?

Oh, you want the products from your store to actually show in your react app? Okay okay, let's do this.

I assume you know how to connect your react app to your redux store using a provider. There are plenty of posts about this topic out there. After you've done that, you'll need a few components.

For me everything starts in a view. A view, for me, is a component which wraps up everything a user gets served into one parent component. This parent component has most of the connection to the redux store and shares the data with the components it encapsulates.


import React, { Component } from 'react';
import PropTypes from 'prop-types';
import { connect } from 'react-redux';
import { bindActionCreators } from 'redux';

import fetchProductsAction from 'fetchProducts';
import {getProductsError, getProducts, getProductsPending} from 'reducer';

import LoadingSpinner from './SomeLoadingSpinner';
import ProductList from './ProductList';

class ProductView extends Component {
    constructor(props) {
        super(props);

        this.shouldComponentRender = this.shouldComponentRender.bind(this);
    }

    componentWillMount() {
        const {fetchProducts} = this.props;
        fetchProducts();
    }

    shouldComponentRender() {
        const {pending} = this.props;
        if(this.pending === false) return false;
        // more tests
        return true;
    }

    render() {
        const {products, error, pending} = this.props;

        if(!this.shouldComponentRender()) return <LoadingSpinner />

        return (
            <div className='product-list-wrapper'>
                {error && <span className='product-list-error'>{error}</span>}
                <ProductList products={products} />
            </div>
        )
    }
}


const mapStateToProps = state => ({
    error: getProductsError(state),
    products: getProducts(state),
    pending: getProductsPending(state)
})

const mapDispatchToProps = dispatch => bindActionCreators({
    fetchProducts: fetchProductsAction
}, dispatch)

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

So, a lot is going on here. We write a standard React component. Then we use connect to connect it to our redux store. Connect takes two parameters: One function mapStateToProps which maps parts of the state into your components props and one function mapDispatchToProps which maps functions into your props which are, when called, dispatched to redux.

Right at the end we put all those things together and voilá, we have a connection to our store.

In the mapStateToProps function we make use of our selectors we wrote earlier.

I like to add a function called shouldComponentRender to my view components and most of my components for that matter. I named it like this, because it's close to react's shouldComponentUpdate lifecycle method. It checks whether or not the component should render. If not, it renders a LoadingSpinner component.

I find it very beneficial to work like this, because the components are always reinitialized and all subcomponents are mounted again after the pending flag, which controls the rendering in this case, toggles. Therefore you can add redux state to a component's state in the constructor. (I don't want to talk about what goes into redux and what goes into component state, this is a topic for another post).

In most of my projects I found this one of the most annoying problems. Think of a component which renders a product. It is initialized by the data and then some subcomponents like a price calculator, which has a component state, is initialized in its constructor. When new data comes in, you need to do a check whether or not the calculator needs to reinitialize. With the shouldComponentRender function it's super easy to do so. Everytime the pending flag toggles (maybe because a new product is selected), everything reinitializes and is good to go.

Of course there are some reasons why you might have components within your view to not to rerender. If that's the case, just remove the shouldComponentRender function from your view and work with it within the subcomponents.

You can use some kind of fadeout/-in effect to improve the user experience.

Well, that's it. For real this time.

Thank you for reading my first blog post ever. I hope you enjoyed it, I hope you learned something and if you have any suggestions or tips for me to improve my react/redux skills or just want to say "hi", leave me some comments, I'd really like that.