Forem: Balaganesh Damodaran

Beware of Chaining Javascript Array Methods

Balaganesh Damodaran — Tue, 26 Mar 2019 12:18:34 +0000

Javascript is a 'functional' language. What this means is that functions are first class objects in Javascript, and as such they can be passed on as parameters to other functions. There are quite a few built-in methods provided by the Javascript standard library, which makes use of this fact, to enable us to write, clean, understandable, and easy to read code.

Built-in Javascript Array Methods, and Chaining

One such built-in class which makes extensive use of Javascript's functional nature, is the Array class. Arrays in Javascript, expose a number of instance methods, which:

accept a function as an argument,
iterate upon the array,
and call the function, passing along the array item as a parameter to the function.

The most popular of these are of course forEach, filter, map and reduce. Since these methods also return the Array instance as the return value of the method, they are often chained together, like this:

const tripExpenses = [{
    amount: 12.07,
    currency: 'USD',
    paid: true
}, {
    amount: 1.12,
    currency: 'USD',
    paid: true
}, {
    amount: 112.00,
    currency: 'INR',
    paid: false
}, {
    amount: 54.17,
    currency: 'USD',
    paid: true
}, {
    amount: 16.50,
    currency: 'USD',
    paid: true
}, {
    amount: 189.50,
    currency: 'INR',
    paid: false
}];

const totalPaidExpensesInINR = tripExpenses
    .filter(expense => expense.paid)
    .map(expense => {
        if(expense.currency == 'USD')
            return expense.amount * 70;
        else
            return expense.amount;
    })
    .reduce((amountA, amountB) => amountA + amountB);

In this example, we are calculating the total paid expenses, after converting them from USD to INR. To do this, we are:

filtering tripExpenses to extract only the paid expenses,
mapping the expense amount from the specified currency and converting it to INR, and
reduceing the INR amounts, to get the sum.

Looks like a common, very typical, valid use-case for chaining array methods right? A lot of developers who've been taught to write functional Javascript would come out with something similar when asked to solve this issue.

The Problem with Array Method Chaining

Currently, our tripExpenses array only has 6 items, so this is relatively fast, but what happens when we have to analyze the trip expenses for say an entire companies worth of employees for the entire financial year, and our tripExpenses array starts to have hundreds of thousands of elements?

Thanks to JSPerf, we can visualize this cost quite easily. So let's run a comparison test for the same code with tripExpenses having 10 elements, 10,000 elements, and 100,000 elements. Here's the result of the JSPerf comparison:

The graph shows the number of operations per second, and higher is better. While I expected the 100,000 elements case to perform poorly, I really did not expect the 10,000 elements case to perform this poorly. Since it's not really visible on the chart, let's look at the numbers:

10 Elements - 6,142,739 ops per second
10,000 Elements - 2,199 ops per second
100,000 Elements - 223 ops per second

Yikes, thats really bad! And while processing an array of 100,000 elements might not happen often, 10,000 elements is a very plausible use case, that I've seen regularly in multiple applications I've developed (mostly on the server side).

This shows us, that when we write – even what seems to be quite simple code – we really should be watching out for any performance issues that might crop up because of the way we write our code. If instead of chaining the filter, map and reduce methods together, we rewrite our code such that, all the work gets done in a single loop, we can gain significantly better performance.

let totalPaidExpensesInINR = 0;

for(let expense of tripExpenses){
    if(expense.paid){
        if(expense.currency == 'USD')
            totalPaidExpensesInINR += (expense.amount * 70);
        else
            totalPaidExpensesInINR += expense.amount;
    }
}

Let's run another JSPerf comparison to see how this performs against it's functional counterpart, in a 10,000 element test:

As you can see, on Chrome (and by extension Node.JS), the functional example is a whopping 77% slower than the for-of example. On Firefox, the numbers are a lot closer, but the functional example is still 16% slower than the for-of example.

Why Such a Large Performance Delta?

So why is the functional example so much slower than the for-of example? Well it's a combination of factors, but the primary factors that as a developer, we can control, from user land are:

Looping over the same array elements multiple times.
Overhead of function calls for each iteration in the functional example.

If you see the for-of example, you'll see that we only ever iterate through the tripExpenses array once, and we call no functions from within, instead performing our calculations inline.

One of the big performance 'wins' that modern Javascript engines get is by inlining function calls. What this means is that the engine will actually compile your code into a version where the compiler replaces the function call, with the function itself (i.e. inline where you call the function). This eliminates the overhead of calling the function, and provides huge performance gains.

However, we cannot always say for sure whether a Javascript engine will choose to inline a function or not, so doing it ourselves ensures that we have the best possible performance.

So In Conclusion

Some developers may consider the for-of example to be less readable, and more difficult to understand than the functional example. For this particular example, I'd say both the examples are equally readable. However, in the case of the functional example the convenience of the method chaining, tends to hide the multiple iterations and function calls from the developer, thus making it easy for an inexperienced developer to write non-performant code.

I'm not saying that you should always avoid the functional way, I'm sure there are plenty of valid cases for which using the functional way and for chaining the methods, but a general rule of thumb to remember when it comes to performance, and iterating arrays in Javascript, is that if you're chaining methods which iterate through the entire array, you should probably stop and consider the performance impact, before going ahead.

I'd love to hear your opinion on what I've written in this article. Do chime in with your comments below.

[Feb 6th, 2019] Some caveats, and things to keep in mind, as pointed out by commenters

As pointed out by Paul B, there are is a performance hit when using for…of in a transpiled form in browsers, but you can always use a normal for loop with an iterator variable to get around this. However, like Paul says, there are quite a few advantages to sticking with an iterator function. Do go read his comment, it's worthy of being an article all by itself.

In addition, a lot of folks have also been saying that this would be premature optimization or a micro optimization, and I do partially agree with them. You should in general always optimize for readability and maintainability over performance, right up until the point where poor performance actually starts impacting you. Once you've reached that point, then you might want to reconsider your iterators.

Originally published at asleepysamurai.com on January 8, 2019.

Why I don't use React-Router

Balaganesh Damodaran — Tue, 12 Mar 2019 12:33:49 +0000

React-Router is arguably the most popular routing solution for writing React applications today. Most frontend developers these days automatically include Redux, React-Redux and React-Router as de-facto dependencies for pretty much any application. Including Redux, is something I can understand, as it provides quite a few tangible benefits, but what I don't understand is why anybody would settle for a routing solution that is both inferior and needlessly complicated.

For a bit of background, let me say that while I've been working across the stack for the past 12 years, my primary preference has always been to work on the backend, or on non-browser front ends. I used to absolutely loathe writing front-end code for browsers, because it was too messy, and inevitably devolved into a huge mess of spaghetti code. Thankfully, the last few years, tooling for the front-end has improved tremendously and most of my pain points have been resolved. I started actively writing browser front-end code, when I first started learning React, some three+ years ago.

So as a guy who has done a lot of backend work, on both APIs and web apps returning rendered HTML pages, using everything from php running on cgi-bin (with paths to files mapped as urls), to Express and Koa, with well-defined explicit routing. I've got a very specific idea of what a router is, what it should do, and how it should do it. To me, a Router is a piece of glue code that uses the requested url to identify a Controller, and execute that controller, providing it with a certain context, which usually contains information about the incoming request. That's it. Nothing more.

If you look into Express.JS's router, you'll see that is exactly what it does. It exposes an API, that allows you to register controllers to routes (and methods), and then when a request is received for any of the registered routes, it executes the registered controllers in the order they were registered in. It exposes a very simple API that nevertheless packs in a lot of flexibility and functionality into it. This is my gold standard for a router. It does one thing, it does it well, and it stays out of your way at all other times.

So let's jump into what I don't like about React-Router and why.

Everything is a component in React-Router.

My view of components has always been that they are part of the view layer, and when I write applications, I work to keep business logic like API calls, validation, etc. out of the actual component, and instead try to keep them at the controller level.

However, React-Router's 'everything is a component' approach to routing makes this impossible. Say I want to fetch some data from my backend before rendering a component, the solution to this in React-Router land is to create a new custom component which will 'block' the navigation until the data is made available.

According to React-Router docs, there are three types of components in React-Router, only one type of which (Link) is actually a view component. The rest are there to enable routing. Why is my router play acting as React components?

Different Routers for Different Environments

React-Router exposes two different routers, BrowserRouter and StaticRouter. If you need to make a few API requests to fetch data before rendering, then the way to achieve this differs significantly based on which router you're using. Pretty much all examples I've seen for server side rendering with React-Router, show significant differences in the server routing code, and in the browser routing code. This limits the amount of code that could possibly be reused between the server and the client.

On the server side, you actually have to use matchPath an internal method used by the router, to manually check if the path matches the path of the incoming request, and then call the associated helper function to make the API call and get the data. Hang on a minute! Isn't matching a path and calling the registered controller literally the definition of a router? So to perform server side rendering with async data fetching using React-Router, you have to write your own mini-router inside the StaticRouter?

Lock-in to Router Specific View Components

If you want React-Router to handle a route change, that is triggered by clicking on a link, in your application, you will have to use one of either Link or NavLink components exported by React-Router. If you don't use these components, React-Router will not catch the route change, and your browser will instead perform a full page redirect to the link url.

So you're going to end up with a lot of Links and NavLinks littered throughout your app. This means that, if you eventually decide to switch out of React-Router to something else, you'll have to rewrite every single component of yours that uses these components. I'm not a big fan of this lock in, and would prefer to do without it.

Integration with React-Redux

Under some very specific conditions, React-Router will actually not render updated components, when the url changes. Now to be fair, this is a very well known and documented situation, but the fact is that this is not really an edge case, and the probability that you'll encounter this in your app is quite large. And the way to fix it, is to add yet more boilerplate code.

And if you want to use Redux to manage your routes, that's against recommended practice. Instead you'll have to use a completely seperate Connected React Router module to 'synchronize your routes with your store'. I don't even know what that means, or why I should want to do it.

Major Breaking Changes

This is my final reason for not using React-Router. React-Router v4 completely removed the concept of centralized route configuration, and they did not provide a fully functional replacement. As of today (4th of January, 2019), the react-router-config package which was supposed to provide this functionality, is still in beta.

I understand that a project might want to make breaking changes, and in a lot of cases such breaking changes are completely justifiable, but when a large subset of your users are actively using a feature, and you decide to remove it, you should at the very least provide a stable replacement solution. I don't want to have to worry about a hypothetical future scenario when the developers decide to deprecate some feature that my app relies on heavily, and force me into a situation where I either have to rewrite a lot of things to remove dependency on that feature, or run an outdated version of the library.

So these are the primary reasons I dislike, and do not use React-Router. If you're interested in finding out what my router of choice for React applications is, then I'm sorry to disappoint you, but I don't really have one. Instead I just use a homegrown router that I've been using for pretty much all of my SPAs (both React and non React). It mimics the ExpressJS router's API, with a few tweaks so it can be used for isomorphic routing and rendering React components. I'll talk about how I handle routing in my React applications using this homegrown router in a future post.

I'd love to hear your opinion on things I've written in this article, so do chime in below.

This article was originally published at asleepysamurai.com

Converting React Class Components to Function Components using Hooks

Balaganesh Damodaran — Mon, 11 Mar 2019 12:00:35 +0000

Over the course of the past month, I've spent a lot of time working with React hooks, and building function components using hooks, instead of the traditional class-based components. I'm not going to claim that hooks are definitely superior to class-based components, but there is a huge usability boost, while writing your components as function components, especially since these function components can now access state and lifecycle through the use of React hooks.

In this article, I'm going to be showing you how to convert a class-based React component to a function component, replacing the class based setState and lifecycle methods such as componentWillMount, componentWillReceiveProps with React hooks instead.

So let's first build a class-based React component, which makes use of state as well as lifecycle methods. For this, we shall of course build the traditional React Todo Application.

Our Todo app is going to look like this:

A text input, into which you can type new todo items.
An 'Add Todo' button, clicking which the new todo item in the text input, is added to the todo list.
A list displaying each individual todo item.
Each individual todo item has an associated checkbox which can be used to mark the item as completed.
The todos are persisted to local storage, and loaded again from local storage when the app is initiated.

Our components will use state, componentDidMount, componentDidUpdate and getDerivedStateFromProps lifecycle methods. A few of these methods (I'm looking at you getDerivedStateFromProps) are used in an extremely contrived manner, in order to be able to demonstrate how a hooks based replacement would look like.

Building the Class-Based Todo App

Our todo app will be implemented as three different components, like this:

The complete code for these examples can be found on Github. Use the tags to navigate between class components and function components.

Let's take a look at the TodoContainer component first. This component maintains the complete state of the application, at any time in it's state. It has two methods addTodoItem and toggleItemCompleted which are passed down as callbacks to the TodoInput and TodoItem components respectively, and are used to add a new todo item, and mark an item as completed or incomplete.

In addition, the TodoContainer component makes use of the componentDidMount lifecycle method to load saved todo items from the localStorage. If there are no saved todo items, then an empty list is instantiated as the state of the TodoContainer component. TodoContainer also uses the componentDidUpdate lifecycle method to save the state of the TodoContainer component, to the localStorage. This way, whenever there is a change to the state of TodoContainer it is persisted to localStorage and can be restored upon relaunching the app.

Putting all of that together, TodoContainer component looks like this:

/**
 * Todo Root Container Component
 */

import React, { Component } from 'react';
import TodoItem from './TodoItem';
import TodoInput from './TodoInput';

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

        this.state = {
            todoItems: [],
            completedItemIds: []
        };
    }

    generateID() {
        return Date.now().toString(36) + '-' + (Math.random() + 1).toString(36).substring(7);
    }

    addTodoItem = (text) => {
        const newTodoItem = {
            text,
            id: this.generateID()
        };

        const todoItems = this.state.todoItems.concat([newTodoItem]);
        this.setState({ todoItems });
    }

    toggleItemCompleted = (todoItemId) => {
        const todoItemIndexInCompletedItemIds = this.state.completedItemIds.indexOf(todoItemId);

        const completedItemIds = todoItemIndexInCompletedItemIds === -1 ?
            this.state.completedItemIds.concat([todoItemId]) :
            ([
                ...this.state.completedItemIds.slice(0, todoItemIndexInCompletedItemIds),
                ...this.state.completedItemIds.slice(todoItemIndexInCompletedItemIds + 1)
            ]);

        this.setState({ completedItemIds });
    }

    componentDidMount() {
        let savedTodos = localStorage.getItem('todos');

        try {
            savedTodos = JSON.parse(savedTodos);
            this.setState(Object.assign({}, this.state, savedTodos));
        } catch (err) {
            console.log('Saved todos non-existent or corrupt. Trashing saved todos.');
        }
    }

    componentDidUpdate() {
        localStorage.setItem('todos', JSON.stringify(this.state));
    }

    render() {
        const todoList = this.state.todoItems.map(todoItem => {
            return (
                <TodoItem
                    key={todoItem.id}
                    completedItemIds={this.state.completedItemIds}
                    toggleItemCompleted={this.toggleItemCompleted}
                    {...todoItem} />
            );
        });

        const todoInput = (
            <TodoInput
                onAdd={this.addTodoItem} />
        );

        return (
            <div
                className="todo-container">
                {todoList}
                {todoInput}
            </div>
        );
    }
};

export default Todo;

Next let's look at the TodoInput component. This is a very simple component, which consists of a single text input and a button. The component uses it's own state to keep track of the value of the text input, and upon button click, passes that text along to the addTodoItem method passed in as the onAdd prop by the TodoContainer component.

The TodoInput component looks like this:

/**
 * TodoInput Component
 */

import React, { Component } from 'react';

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

        this.state = {
            text: ''
        };
    }

    onTextChange = (ev) => {
        this.setState({ text: ev.currentTarget.value });
    }

    addTodoItem = () => {
        this.props.onAdd(this.state.text);
        this.setState({ text: '' });
    }

    render() {
        return (
            <div
                className="todo-input">
                <input
                    type="text"
                    onChange={this.onTextChange}
                    value={this.state.text}
                    placeholder="Enter Todo Here" />
                <button
                    onClick={this.addTodoItem}>
                    Add Todo
                </button>
            </div>
        );
    }
};

export default TodoInput;

Finally, the TodoItem component. This is another simple component, which basically consists of a checkbox, indicating whether the todo item is completed, and a label for that checkbox, specifying the text of the todo item. In order to demonstrate the use of getDerivedStateFromProps, the TodoItem component takes in the entire completedItemIds from the TodoContainer component as a prop, and uses it to calculate if this particular TodoItem is complete or not.

The TodoItem component looks like this:

/**
 * TodoItem Component
 */

import React, { Component } from 'react';

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

        this.state = {
            completed: false
        };
    }

    toggleItemCompleted = () => {
        this.props.toggleItemCompleted(this.props.id);
    }

    static getDerivedStateFromProps(props, state) {
        const todoItemIndexInCompletedItemIds = props.completedItemIds.indexOf(props.id);

        return { completed: todoItemIndexInCompletedItemIds > -1 };
    }

    render() {
        return (
            <div
                className="todo-item">
                <input
                    id={`completed-${this.props.id}`}
                    type="checkbox"
                    onChange={this.toggleItemCompleted}
                    checked={this.state.completed} />
                <label>{this.props.text}</label>
            </div>
        );
    }
};

export default TodoItem;

Rules to Remember While Getting Hooked

In order to demonstrate the various React hooks we are going to be using to convert our Todo app to use React function components, I'm going to be starting with the simple hooks, and moving on to the more complicated ones. But before we do that, let's take a quick look at the most important rules to keep in mind while using hooks.

Hooks should only be called from within a React function component, or another hook.
The same hooks should be called in the same order, the same number of times, during the render of a single component. This means that hooks cannot be called within loop or conditional blocks, and must instead always be called at the top level of the function.

The reasoning behind these rules for using hooks are a topic that can be an article by itself, and if you are interested in reading more about this, you should check out the Rules of Hooks article on the official React documentation site.

Now, that we know the basic rules to be followed while using hooks, let's go ahead and start converting our Todo app to use function components.

Function Components for our Todo App

The simplest, and probably the one hook that you are going to end up using the most is the useState hook. The useState hook basically provides you with a setter and a getter to manipulate a single state property on the component. The useState hook has the following signature:

const [value, setValue] = useState(initialValue);

The first time the hook is called, the state item is initialized with the initialValue. Upon subsequent calls to useState, the previously set value will be returned, along with a setter method, which can be used to set a new value for that particular state property.

So let's convert the TodoInput component to a function component, using the useState hook.

/**
 * TodoInput Component
 */

import React, { useState } from 'react';

function TodoInput({
    onAdd
}) {
    const [text, setText] = useState('');

    const onTextChange = (ev) => setText(ev.currentTarget.value);

    const addTodoItem = () => {
        onAdd(text);
        setText('');
    };

    return (
        <div
            className="todo-input">
            <input
                type="text"
                onChange={onTextChange}
                value={text}
                placeholder="Enter Todo Here" />
            <button
                onClick={addTodoItem}>
                Add Todo
            </button>
        </div>
    );
};

export default TodoInput;

As you can see, we are using useState to get the text state property value and setText setter, obtained from the useState method. The onTextChange and addTodoItem methods have both been changed to use the setText setter method, instead of setState.

You might have noticed that the onChange event handler for the input, as well as the Add Todo button onClick event handlers are both anonymous functions, created during the render, and as you might know, this is not really good for performance, since the reference to the functions changes between renders, thus forcing React to re-render both the input and the button.

In order to avoid these unnecessary re-renders, we need to keep the reference to these functions the same. This is where the next hook we are going to use useCallback comes into the picture. useCallback has the following signature:

const memoizedFunction = useCallback(inlineFunctionDefinition, memoizationArguments);

where:

inlineFunctionDefinition - is the function that you wish to maintain the reference to between renders. This can be an inline anonymous function, or a function that get's imported from somewhere else. However, since in most cases we would want to refer to state variables of the component, we will be defining this as an inline function, which will allow us to access the state variables using closures.
memoizationArguments - is an array of arguments that the inlineFunctionDefinition function references. The first time the useCallback hook is called, the memoizationArguments are saved along with the inlineFunctionDefinition. Upon subsequent calls, each element in the new memoizationArguments array is compared to the value of the element at the same index in the previously saved memoizationArguments array, and if there is no change, then the previously saved inlineFunctionDefinition is returned, thus preserving the reference, and preventing an unnecessary re-render. If any of the parameters have changed, then the inlineFunctionDefinition and the new memoizationArguments are saved and used, thus changing the reference to the function, and ensuring a re-render.

So adapting TodoInput to use useCallback:

/**
 * TodoInput Component
 */

import React, { useState, useCallback } from 'react';

function TodoInput({
    onAdd
}) {
    const [text, setText] = useState('');

    const onTextChange = useCallback((ev) => setText(ev.currentTarget.value), [setText]);

    const addTodoItem = useCallback(() => {
        onAdd(text);
        setText('');
    }, [onAdd, text, setText]);

    return (
        <div
            className="todo-input">
            <input
                type="text"
                onChange={onTextChange}
                value={text}
                placeholder="Enter Todo Here" />
            <button
                onClick={addTodoItem}>
                Add Todo
            </button>
        </div>
    );
};

export default TodoInput;

Now that we have converted TodoInput to a function component, let's do the same with TodoItem. Rewriting using useState and useCallback, TodoItem becomes:

/**
 * TodoItem Component
 */

import React, { useState, useCallback } from 'react';

function TodoItem({
    id,
    text,
    toggleItemCompleted,
    completedItemIds
}) {
    const [completed, setCompleted] = useState(false);

    const onToggle = useCallback(() => {
        toggleItemCompleted(id);
    }, [toggleItemCompleted, id]);

    return (
        <div
            className="todo-item">
            <input
                id={`completed-${id}`}
                type="checkbox"
                onChange={onToggle}
                checked={completed} />
            <label>{text}</label>
        </div>
    );
};

export default TodoItem;

If you compare this with the class component version of TodoItem, you'll notice that the getDerivedStateFromProps which we used to determine if this particular TodoItem was completed or not, is missing in the function component version. So which hook would we use to implement that?

Well there exists no specific hook to implement this. Instead, we will have to implement this as part of the render function itself. So once we implement it, TodoItem looks like this:

/**
 * TodoItem Component
 */

import React, { useState, useCallback } from 'react';

function TodoItem({
    id,
    text,
    toggleItemCompleted,
    completedItemIds
}) {
    const [completed, setCompleted] = useState(false);

    const todoItemIndexInCompletedItemIds = completedItemIds.indexOf(id);
    const isCompleted = todoItemIndexInCompletedItemIds > -1;

    if (isCompleted !== completed) {
        setCompleted(isCompleted);
    }

    const onToggle = useCallback(() => {
        toggleItemCompleted(id);
    }, [toggleItemCompleted, id]);

    return (
        <div
            className="todo-item">
            <input
                id={`completed-${id}`}
                type="checkbox"
                onChange={onToggle}
                checked={completed} />
            <label>{text}</label>
        </div>
    );
};

export default TodoItem;

You might notice that we are calling the setCompleted state setter method during the rendering of the component. While writing class components, we never call setState in the render method, so why is this acceptible in function components?

This is allowed in function components specifically to allow us to perform getDerivedStateFromProps-esque actions. An important thing to keep in mind, is to ensure that, inside a function component, we always call state setter methods inside a conditional block. Otherwise, we are going to end up in an infinite loop.

Please note, the way I've implemented the isCompleted check here is a bit contrived, in order to demonstrate setting the state from within the function component. Ideally, the completed state simply would not be used, and the calculated isCompleted value would be used to set the checked state of the checkbox.

Finally, we've only got TodoContainer component to be converted. We'll need to implement state as well as the componentDidMount and componentDidUpdate lifecycle methods.

Since we've already seen about useState and I don't really have a good excuse to demonstrate useReducer, I'm going to pretend that TodoContainer component's state is too complicated to manage each state property individually using useState, and that the better option is to use useReducer.

The signature of the useReducer hook, looks like this:

const [state, dispatch] = useReducer(reducerFunction, initialState, stateInitializerFunction);

where:

reducerFunction - is the function that takes existing state and an action as an input and returns a new state as the output. This should be familiar to anybody who has used Redux and it's reducers.
initialState - If there is no stateInitializerFunction provided, then this is the initial state object for the component. If a stateInitializerFunction is provided, this is passed in as an argument to that function.
stateInitializerFunction - A function which allows you to perform lazy initialization of the component's state. The initialState parameter will be passed in as an argument to this function.

So converting TodoContainer component to use useReducer:

/**
 * Todo Root Container Component
 */

import React, { useReducer, useCallback } from 'react';
import TodoItem from './TodoItem';
import TodoInput from './TodoInput';

const generateID = () => {
    return Date.now().toString(36) + '-' + (Math.random() + 1).toString(36).substring(7);
};

const reducer = (state, action) => {
    if (action.type === 'toggleItemCompleted') {
        const { todoItemId } = action;
        const todoItemIndexInCompletedItemIds = state.completedItemIds.indexOf(todoItemId);

        const completedItemIds = todoItemIndexInCompletedItemIds === -1 ?
            state.completedItemIds.concat([todoItemId]) :
            ([
                ...state.completedItemIds.slice(0, todoItemIndexInCompletedItemIds),
                ...state.completedItemIds.slice(todoItemIndexInCompletedItemIds + 1)
            ]);

        return { ...state, completedItemIds };
    }

    if (action.type === 'addTodoItem') {
        const newTodoItem = {
            text: action.text,
            id: generateID()
        };

        const todoItems = state.todoItems.concat([newTodoItem]);
        return { ...state, todoItems };
    }

    return state;
};

const initialState = {
    todoItems: [],
    completedItemIds: []
};

function Todo() {
    const [state, dispatch] = useReducer(reducer, initialState);

    const toggleItemCompleted = useCallback((todoItemId) => {
        dispatch({ type: 'toggleItemCompleted', todoItemId });
    }, [dispatch]);

    const todoList = state.todoItems.map(todoItem => {
        return (
            <TodoItem
                key={todoItem.id}
                completedItemIds={state.completedItemIds}
                toggleItemCompleted={toggleItemCompleted}
                {...todoItem} />
        );
    });

    const addTodoItem = useCallback((text) => {
        dispatch({ type: 'addTodoItem', text });
    }, [dispatch]);

    const todoInput = (
        <TodoInput
            onAdd={addTodoItem} />
    );

    return (
        <div
            className="todo-container">
            {todoList}
            {todoInput}
        </div>
    );
};

export default Todo;

Next we need to write the state of the TodoContainer component to localStorage, whenever the component is updated, similar to what we were doing in componentDidUpdate. To do this, we will make use of the useEffect hook. The useEffect hook allows us to enqueue a certain action to be done, after each render of the component is completed. It's signature is:

useEffect(enqueuedActionFunction);

As long as you adhere to the rules of hooks, we talked about earlier, you can insert a useEffect block anywhere in your function component. If you have multiple useEffect blocks, they will be executed in sequence. The general idea of useEffect is to perform any actions that do not directly impact the component in the useEffect block (ex: API calls, DOM manipulations etc.).

We can use useEffect to ensure that after every single render of our TodoContainer, the state of the component is written to localStorage.

/**
 * Todo Root Container Component
 */

import React, { useReducer, useCallback, useEffect } from 'react';
import TodoItem from './TodoItem';
import TodoInput from './TodoInput';

const generateID = () => {
    return Date.now().toString(36) + '-' + (Math.random() + 1).toString(36).substring(7);
};

const reducer = (state, action) => {
    if (action.type === 'toggleItemCompleted') {
        const { todoItemId } = action;
        const todoItemIndexInCompletedItemIds = state.completedItemIds.indexOf(todoItemId);

        const completedItemIds = todoItemIndexInCompletedItemIds === -1 ?
            state.completedItemIds.concat([todoItemId]) :
            ([
                ...state.completedItemIds.slice(0, todoItemIndexInCompletedItemIds),
                ...state.completedItemIds.slice(todoItemIndexInCompletedItemIds + 1)
            ]);

        return { ...state, completedItemIds };
    }

    if (action.type === 'addTodoItem') {
        const newTodoItem = {
            text: action.text,
            id: generateID()
        };

        const todoItems = state.todoItems.concat([newTodoItem]);
        return { ...state, todoItems };
    }

    return state;
};

const initialState = {
    todoItems: [],
    completedItemIds: []
};

function Todo() {
    const [state, dispatch] = useReducer(reducer, initialState);

    useEffect(() => {
        localStorage.setItem('todos', JSON.stringify(state));
    });

    const toggleItemCompleted = useCallback((todoItemId) => {
        dispatch({ type: 'toggleItemCompleted', todoItemId });
    }, [dispatch]);

    const todoList = state.todoItems.map(todoItem => {
        return (
            <TodoItem
                key={todoItem.id}
                completedItemIds={state.completedItemIds}
                toggleItemCompleted={toggleItemCompleted}
                {...todoItem} />
        );
    });

    const addTodoItem = useCallback((text) => {
        dispatch({ type: 'addTodoItem', text });
    }, [dispatch]);

    const todoInput = (
        <TodoInput
            onAdd={addTodoItem} />
    );

    return (
        <div
            className="todo-container">
            {todoList}
            {todoInput}
        </div>
    );
};

export default Todo;

Next we need to restore the state from the localStorage whenever the component is mounted, similar to what we do in componentDidMount. Now there are no specific hooks to perform this, but we can use the useReducer hooks lazy initialization function (which will be called only on the first render), to achieve this.

/**
 * Todo Root Container Component
 */

import React, { useReducer, useCallback, useEffect } from 'react';
import TodoItem from './TodoItem';
import TodoInput from './TodoInput';

const generateID = () => {
    return Date.now().toString(36) + '-' + (Math.random() + 1).toString(36).substring(7);
};

const reducer = (state, action) => {
    if (action.type === 'toggleItemCompleted') {
        const { todoItemId } = action;
        const todoItemIndexInCompletedItemIds = state.completedItemIds.indexOf(todoItemId);

        const completedItemIds = todoItemIndexInCompletedItemIds === -1 ?
            state.completedItemIds.concat([todoItemId]) :
            ([
                ...state.completedItemIds.slice(0, todoItemIndexInCompletedItemIds),
                ...state.completedItemIds.slice(todoItemIndexInCompletedItemIds + 1)
            ]);

        return { ...state, completedItemIds };
    }

    if (action.type === 'addTodoItem') {
        const newTodoItem = {
            text: action.text,
            id: generateID()
        };

        const todoItems = state.todoItems.concat([newTodoItem]);
        return { ...state, todoItems };
    }

    return state;
};

const initialState = {
    todoItems: [],
    completedItemIds: []
};

const initState = (state) => {
    let savedTodos = localStorage.getItem('todos');

    try {
        savedTodos = JSON.parse(savedTodos);
        return Object.assign({}, state, savedTodos);
    } catch (err) {
        console.log('Saved todos non-existent or corrupt. Trashing saved todos.');
        return state;
    }
};

function Todo() {
    const [state, dispatch] = useReducer(reducer, initialState, initState);

    useEffect(() => {
        localStorage.setItem('todos', JSON.stringify(state));
    });

    const toggleItemCompleted = useCallback((todoItemId) => {
        dispatch({ type: 'toggleItemCompleted', todoItemId });
    }, [dispatch]);

    const todoList = state.todoItems.map(todoItem => {
        return (
            <TodoItem
                key={todoItem.id}
                completedItemIds={state.completedItemIds}
                toggleItemCompleted={toggleItemCompleted}
                {...todoItem} />
        );
    });

    const addTodoItem = useCallback((text) => {
        dispatch({ type: 'addTodoItem', text });
    }, [dispatch]);

    const todoInput = (
        <TodoInput
            onAdd={addTodoItem} />
    );

    return (
        <div
            className="todo-container">
            {todoList}
            {todoInput}
        </div>
    );
};

export default Todo;

As you can see, we read the saved previous state from localStorage, and use that to initilize the state of the TodoContainer component, thus mimicking what we were doing in componentDidMount. And with that, we have converted our entire todo app, to function components.

In conclusion...

In this article, I've only covered a few of the hooks that are available out of the box in React. Apart from these out of the box hooks, we can also write our own custom hooks to perform more specific tasks.

One of the key takeaways from this little exercise in converting class components to function components, is that there is no one to one mapping between lifecycle methods and React hooks. While useState and useReducer usage is quite similar to setState, you might have to change the way you are doing certain tasks in order to get them working in a function component (like getDerivedStateFromProps in our Todo app).

As such converting a React class component to a function component is something that may be trivial, or quite complicated depending on the component. Unless you're writing a new component, there really is no hard need to convert a class component to a function component, especially since React is going to continue supporting both forms for the foreseeable future.

That said, if you do find yourself needing to convert an existing class component to a function component, I hope this article provided you with a good starting point. I'd love to hear your opinion on things I've written in this article, so do chime in below.

This article was originally published at asleepysamurai.com

Organizing Your React + Redux Application's Codebase for Future Maintainability and Extensibility

Balaganesh Damodaran — Wed, 06 Mar 2019 09:32:37 +0000

When you first start writing a new React application, the feature set is small, and the React API is simple, yet flexible and powerful enough to handle state management. Eventually however, your application grows bigger, and the shortcomings of React's setState at handling state management for larger applications become obvious, in a painful manner.

So you do a bit of research and figure out Redux is your best bet at handling the growing state management needs of your application. Redux introduces actions, actionCreators, reducers, middleware and stores. And since this is a React application, you'll need to wire Redux to your React components, so you'll also want to use React-Redux. Add all these up, and your application can quickly become a huge mess of spaghetti code, unless you organize your application properly.

Ensuring that your application is organized properly, in a manner that is easy to understand for your entire team, can save you a lot of time, and resources while maintaining and extending the application. I have been writing React applications for the past three+ years, with these applications ranging in complexity from trivial to ultra-complex.

Over the course of developing these applications, I have experimented with multiple ways of organizing my React applications, and I think I've finally settled on the pattern that provides the best balance of ease-of-use and maintainability. I call this pattern of organizing my application, the State-View pattern. But before, we look at the State-View pattern, let's first look at the other patterns that I went through, and why I found them lacking.

Grouping by Function/Type of File

In a React + Redux application, we can have multiple different types of files, each of which perform a specific function. For example, we have reducers which derive a new state from the given state and an action, actionCreators which create the action to pass on to the reducers, the store which holds the state of the application, and allows components to subscribe to changes to the store, the presentational components which create the views that are rendered on the screen, the container components which do the bulk of the heavy lifting and provide the business logic, persistence etc.

The most common way to organize a React + Redux application, is to simply group your files by the type/function of that file. This is how a vast majority of React + Redux applications are organized. If you look at the Real-World example, from the Redux Github repository, you'll see that this is how it is organized.

In the real-world example project:

configureStore.dev.js, configureStore.prod.js are two stores (only one of which is used based on the running environment of the application), and these are grouped under the store directory.
index.js and paginate.js both export multiple reducers, and these are grouped together under the reducers directory.
api.js provides a Redux middleware, which is used to make API calls to Github's API, and normalize the results. This is located under the middleware directory.
The various container components are grouped together under the containers directory.
The various presentational components are grouped together under the components directory.
The actions are all defined in a single index.js which is placed under the actions directory.
The entry point of the application index.js is placed directly at the root.

The advantage of organizing your application by grouping files with the same function together, is that you always know exactly where a specific type of file is going to be. For example: If you are debugging an issue with state transitions not happening correctly, you know that the only place where a state transition can happen is within a reducer, and all reducers are located in the reducers directory.

This works well as long as your application is small and has only a few components and associated actions, reducers and middleware. As your application becomes bigger, you will find yourself dumping more and more files which are only tangentially related to each other in the same directory, and going through these files to isolate specific issues will start consuming more of your time and resources. This is only exacerbated, when multiple developers are working on the same codebase, and are all touching the same files in the same directory to get their own individual features working.

Grouping by Application Feature

The main problem with the 'Function/Type based grouping' approach to organizing your codebase, is that to work on a single feature, you will have to work on files which are distributed across your entire project, in multiple unrelated directories. In order to alleviate this problem, you can instead organize your React + Redux application by grouping files related to a specific feature of your application together.

Modifying the same Redux Real-World example to group by application feature would make it look like this:

Here we have split up our code into different 'features':

Root - The root container component which performs routing and renders other components. Since this does not maintain or manage state, it does not have any actions or reducers in the directory. We have also renamed the container component and suffixed the file with Container to indicate it as a container component.
App - The main application component. Since this does maintain a state to indicate whether or not the API call errored out, it has actions.js and reducers.js in the directory. You may notice we have renamed the Explore component to ExploreComponent. This is to indicate this as a presentational component.
DevTools - Is responsible for the DevTools which log the state as it transitions with each action. Does not manage any state of it's own, so this directory only has the components.
RepoPage and UserPage - These directories correspond to the RepoPage feature which lists the starred watchers of a repo, and a UserPage feature which lists the repos a user has. These components manage their own state, specifically they manage the properties entities and pagination of the applicate state object. Remember, this as it will become important shortly.
common - Any component, middleware, reducer or action that is shared across multiple features goes here.

This is already looking so much better than 'Function/Type based grouping'. If we want to work on a particular feature, all the files related to that feature are in the same directory. This includes the actions, reducers, presentational components and container components. Both view and state related code is sitting in the same directory, thus making it quite easy for us to make changes for a specific feature, without having to go and modify five different files in five different directories.

This approach usually works well for those applications where there is a one-to-one mapping between state items and view. For example, in a todo list, each todo item is only ever displayed in one location on the screen, via a single presentational component. Thus we are able to segregate the state of the application cleanly based on the feature that makes use of that state, and we can group the related actions and reducers together with the view components for that feature.

But what happens when the mapping between state items and view components is not one-to-one. This is exactly what happens in the case of the 'real-world redux example' application we are analyzing. In this application, both RepoPage and UserPage functionality, independently make use of the entities and pagination properties on the state object. Both the features read and write to these properties, by sharing the same actions and reducers between them.

In such a case how do we group the state and the view together? Which actions and reducers should be grouped with RepoPage and which should be grouped with UserPage? Grouping the state related code, mainly the actions and reducers with either one feature, breaks our grouping model, and it is no longer true that we always have all the code related to a specific functionality in a single directory. Putting the actions and reducers in common also results in the exact same issue.

The State-View Pattern

Recently, I've been working on a pretty complex React + Redux application, for which I experimented with a new pattern of organizing my application's codebase. This is an evolution of the 'feature-based grouping' approach to organizing your code.
Pretty much the only issue (albeit a major one), of the feature-based grouping approach, is unpredictability with regards to state, when the state does not map one-to-one with views.

In order to eliminate this unpredictability, we split the codebase into two seperate main directories, and files are grouped based on different factors in each directory. As you may have guessed, these two directories are the state and the view directories.

All state management related code, including all actions, reducers, middleware and stores are put into the state directory. All other code is put into the view directory. So how are these directories further organized?

Let's first look at how the overall application structure looks when the real-world Redux example is rewritten to use the State-View pattern:

There are the two main directories state and view. Let's explore the view directory first.

Root - The root container component which performs routing and renders other components. All state management related code is removed from here, and only view specific code is retained. We have also renamed the container component and suffixed the file with Container to indicate it as a container component.
App - The main application component. You may notice we have renamed the Explore component to ExploreComponent. This is to indicate this as a presentational component.
DevTools - Is responsible for the DevTools which log the state as it transitions with each action.
RepoPage and UserPage - These directories correspond to the RepoPage feature which lists the starred watchers of a repo, and a UserPage feature which lists the repos a user has. As you can see, these directories only contain the view components and all actions and reducers have been removed.
_shared - All the view components which are shared between multiple features, are grouped together here.

As you can see the view directory is organized extremely similarly to how the application is organized in the feature-based grouping pattern. The reason for this is pretty simple. There was no real issue with the way the view components were organized in the feature-based grouping pattern, so we just left it as is.

Now let's look at the state directory. This is where the majority of the changes from the feature-based grouping pattern occur. First off, you will notice that the names of the subdirectories inside the view directory do not at all correspond with those of the subdirectories inside the state directory. This is completely intentional, and is done to enforce the idea that the state does not have a one-to-one mapping with the view.

Instead of organizing the state directories contents by application feature, we organize them by the properties of the store that they are responsible for. In the real-world redux example, the state of the application looks something like this:

const state = {
    errorMessage: null,
    entities: {},
    pagination: {}
};

If we go back to the state directory, the subdirectories correspond to the properties of the state. Each subdirectory contains the actions and reducers required for manipulating that particular portion of the state. Any commonly shared items, are placed in the _shared directory. These actions and reducers are then rolled up and combined, by using the actions.js and reducers.js files in the state directory, and they are then exported by the index.js. So now, if we need to use a specific action in any of our view components, we can require it like this:

import { actions } from '../../state';

const { loadRepo, loadStargazers } = actions;

If you want to have a look at the code for the state-view pattern for the real-world redux example application, the source for that is available on Github.

Thus we have effectively decoupled the way our state related code is organized from the way our view related code is organized. Since state is now no longer grouped together with views, we again have a very predictable pattern for our code. Any view related code will always be in the corresponding feature subdirectory in the view directory. Any state manipulation performed by those views will be in the subdirectory with the corresponding state property name in the state directory. Thus so long as you know where your view is (which should be easy to figure out based on the feature it is part of), you can easily figure out what state it impacts and where the corresponding state manipulation code resides.

Hoorah! We have restored predictability to our React + Redux application's structure, and this should enable us to maintain and extend our application, a lot easier than we could have done it before.

I'd love to hear your opinion on things I've written in this article, so do chime in below.

This article was originally published on asleepysamurai.com.