Building Dynamic Form the hard way with React-Redux

Javascript is getting so foreign to me these days, but mostly towards a better direction. So I recently got myself to learn react through work and the JSX extension makes web development bearable again. On the other hand, I picked up a little bit on Vue.js but really hated all the magic involved (No I don’t enjoy putting in code into quotes).

Building a dynamic form that has components appearing or not appearing depends on the other field value is a very annoying problem. While learning React I was told about redux and I am instantly sold on the idea (perhaps because my preferred programming paradigm is functional style). Then I started building my current project at work using these. While some parts are made easier, but it is still overall a confusing thing to do.

This post is intended to be a quick note on how I am approaching to the problem currently, and may not be the best way (part of it violates the jsx-no-bind lint rule for instance, also I still don’t do camelCase).

Problem statement

Suppose I want to build a form that generates a list of publications of any length. And depending on the type of the publication it would take one of the following two forms.

{
    "title": "Becoming Jeffrey04",
    "authors": [
        {
            "name": "Jeffrey",
            "website": "http://coolsilon.com/"
        }
    ],
    "type": "journal"
    "meta": {
        "volume": "0",
        "editors": [
            {
                "name": "John Doe",
                "website": "http://john.coolsilon.com/"
            }
        ]
    }
}

or

{
    "title": "Becoming Jeffrey04",
    "authors": [
        {
            "name": "Jeffrey",
            "website": "http://coolsilon.com/"
        }
    ],
    "type": "book"
    "meta": {
        "title": "I am the best!",
        "editors": [
            {
                "name": "John Doe",
                "website": "http://john.coolsilon.com/"
            }
        ],
        "is_published": false
    }
}

So the editors and authors are both to be of any length.

One of the thing I like about redux is that I don’t have to worry about UI update IN ADDITION to the state, which is usually stored elsewhere. Back then in my jQuery days (which you can probably see in my past work) I needed to remember to save the state, and then notify the widget to update accordingly.

Not anymore, now I just need to update the state and redux would trigger the UI rendering where needed. This is going to be very useful when we have a dynamic form because I don’t have to worry about whether the fields are properly updated after every click or keystrokes.

So we start from the base publication list. So while building the second dynamic form I start to find ways to do it better and clearer (and may or may not have time to fix the previous one to the new way).

Some boring convention talk

So in building dynamic form there are basically 2 different types of important functions/methods that one needs to write. First is to handle onChange or onClick events, and the other to compute current state of the form to be sent to redux.

Did I mention the programming style is very personal before this?

The first type of function, which handles the user input events, I am going to name them as handle_$event[_$name] where $event is the type of event, and the option $name is used when there are multiple events happening in the same component. They are also usually the one who calls the redux dispatcher.

Secondly the function that computes the state, to be passed down to child components to help generate complete snapshot of the form.These functions are going to be named as handle_update and get passed down as delegate_update property. Unless otherwise specified, the function signature is either one of the following two.

• handle_update(is_delete, changes)
• handle_update(idx, is_delete, changes)

The second form is usually the one that violates the jsx-no-bind rule, just for your information.

This posts assumes knowledge of react-redux.

There are also 3 different types of component.

• Component that talks about 1 entity
• Component that lists an array of entities
• Intermediate component mostly because of the fancy markups

We are also going to ignore the third type. The second type of component is usually where you see the declaring of second form of handle_update.

This post is getting long, I am going to split it into multiple pages.