Let’s face it, forms can be extremely complicated. There are all sorts of issues you run into with forms to provide a nice user experience. That’s why it’s really handy to have a library to help you out. If using React/Redux, Redux Forms is a great library to help you manage that form state in your Store. Having Redux Forms work with the store also opens up the possibility to customize behavior via your own reducers. This will let you take advantage of all the built-in functionality of the library but also handle your potentially complicating scenarios. I’m going to show you how to leverage this concept to build a specialized form that reflects a requirement we had for a project, a derived but editable field.
Derived But Editable?
This is a field that we want to default for the user based on their current input but then let them change at will. Don’t worry I’ve got an example.
The above is a fork from a simple form example provided by the Redux Form creator @erikras with our more complex form. The basic gist is that we have 3 fields, an Amount, a Discount Percent and a Total Value but want the user to be able to edit all three. Each value affects the others in a defined way.
- When changing Amount, update Total (keeping Percent fixed)
- When changing Percent, update Total (keeping Amount fixed),
- When changing Total, update Amount (keeping Percent fixed).
Of course you can change these rules but they’ll serve for our purposes.
There are two basic ways to handle this in your redux form. The first is to send your own
onChange event handler down to the input component, then instead of doing the default action which is to just change the field in question, you would dispatch multiple actions. So something like this:
FYI this is also a way to prevent a redux form action from happening. Just override the
on* and don’t call the input’s
onChange function if some condition is met
However there are a lot of problems with this approach. First, how do I dispatch another event to update the other field? Well, to follow the convention you’d have to
connect some component and provide a custom dispatch event for what you’re doing. In our case, it’d be something like this:
There’s a lot to be desired in this solution.
- Overriding default behavior significantly complicates your views (as you can see above)
- Similarly, this is putting business logic in your views, making it more difficult to test
- In redux, we’re encouraged to have actions mutate your state to the next viable application state. Dispatching multiple actions to get where we want means that we temporarily have our state in an invalid… state.
A better way, use the reducers
If we think in the ‘redux’ way, we’d realize that what we really need is to hook into the reducers for redux form. When a change action is dispatched, we need to update two values (at least for our case), not just one. Redux Form recently introduced the concept of plugins that let us do just that.
The redux form examples list a case where you can use plugins to respond to your application’s custom actions, but it’s fairly easy to respond to the redux form actions themselves as well. The general gist will be:
- Listen for a
CHANGEaction for our form
- Check the field in the payload, if it’s one we need to update a derived field on then:
- Update the state to set the derived value as well.
First off, let’s get some simple pure functions defined for updating the amount and the total (we currently don’t need to update the percent).
Next, let’s create our reducer:
This is code from the above example. It’s all combined here in the single
combineReducers but obviously you’d want to extract this to a separate module.
One thing to remember about this method is that your plugin reducer is run after the default actions of the form. That means that when a
CHANGE action happens and
amount is updated, the
state we receive in our custom reducer already has the updated
amount. This is nice because now we just have to worry about updating our derived values.
To do that, we grab the field that was changed, the current values of those fields from the state, and then calculate the new values. Here I’m using dot-prop-immutable to make it look cleaner but you can easily use the spread operator if you like.
Advantages and Disadvantages
First and foremost, this pattern allows for easy testing of your application business logic via unit tests. It’s very easy to write a test that reads like a requirements specification.
When the Amount is 100 and the discount is 5 then the Total Amount should be 95.
It also simplifies your views to be just that, views of your data. They don’t know or care how things get updated, they just respond to the redux store. This makes a lot of sense. Similarly, having all business logic in a single place helps keep the entire project coherent.
Another advantage is that you’re not limited to the redux form actions, as the redux plugin example shows. This means you can have custom actions that update or remove (or reset) parts of your form. All you have to do is add them to the reducer.
There are some downsides to this approach. The first is that if you have a large, deep or complex form, to get the current state of the object you’re trying to modify you’ll have to use regexes to get to your data based on the
meta.field property. More on that in a possible later post.
Also, this applies to all reducers but with this approach comes the ability to shoot yourself in the foot. As mentioned in the docs, this is a powerful tool and with that power comes the ability to corrupt or completely destroy your form state.
We’ve been using this pattern on our project and find it really useful. I hope you do too!