Writing Money Transfers in React — Conclusion
What did I learn?
Lets start with what was I trying to achieve when I decided to investigate using React and Flux to create this section of the site. I wanted to find out if using these technologies would allow me to create better structured, easier to maintain code and get away from complex DOM management which can lead to buggy pages.
So lets look at the first half of this goal. Does React and Redux lead to better structured, maintainable code? I think it does. Having defined roles such as component, action creator and reducer provides good structure, though there are times I wasn’t sure if something belonged in the action or the reducer and this was further complicated when I put this screen into production and had to handle errors and validation. Maybe this will become clearer with practice or maybe I need to read the documentation.
There is a benefit to using a standard tool and pattern so that any other developers that know React and Redux are able to easily pick up the code and support it. This is a double edged sword though as it requires a developer who has not used React and Redux to learn them and they can have a steep learning curve at times.
That all said, there is nothing to stop you creating well structured code of your own, this just lays down a good pattern and some very smart people out there have put a lot of thought into this for you.
Well this is a big one so I’ll break it down. Lets start with DOM manipulation
Managing the DOM
As previously stated, receiving data and then traversing the DOM and updating it can be messy. Having to keep track of things and making sure one thing doesn’t break another or remembering which event handlers may fire can be frustrating. The idea of having a state and then rendering it, changing the state and re-rendering vastly simplifies things. This small fact has made creating components more focussed, layout code is now less complex and concentrates on just creating the correct markup.
The new tricky thing to handle is managing actions and updating state. The code for managing these is more complex than it used to be but I think out of the two problems this is the one I’d rather have. There are times that something will act odd and it can be tricky to debug. One example of this is I had a problem where the amount field would keep reseting to nothing, tracking this down was took time and it ended up being caused by the wrong transfer being updated after a save. When you come across issues like this the React plugin for Chrome comes in handy, but the best way to debug is good old console.log.
Other stuff in the page
During development of the production version of this project I ran into a problem that was hard to track down and I’m still not totally sure the best way to guard against it. When I click on a card in a list, instead of triggering the account select event handler a completely unrelated event handler on the page was being triggered. I needed to capture an event that was outside of the React component so used a jQuery event handler and discovered that the jQuery event handler was being triggered and the event wasn’t making it to React. The problem, it turned out, was that React events work by letting all events bubble up to the document object and captures them there. On the way up from the element to the document the jQuery handler picked up the event and it never made it to react’s handler. I fixed this by putting in some code into the react event handler to tell it to not bubble and that worked (which makes no sense) until someone changed the code on the page to add a 2nd event as part of a library that was being pulled in. What this all demonstrates is that React works great when used on it’s own, but once you start to use it on a page with other code then things can get weird.
The downside is code produced is ES5 and Internet Explorer 8 doesn’t support some key parts of this. I now understand why so many services out there have dropped IE 8 support. For the site I’m creating this is an issue. UK Government sites have to be usable by everyone and even though the percentage of IE 8 users is low there are still people using it. I have chosen to create a none JS version of the page and only load the JS version on browsers that have the required level of JS support. I did try to get babel to produce ES3 code, and in theory this is possible, but I never got it to work in the limited time I had and for some people this may be a showstopper.
So bottom line, what do I think? Overall using React and Redux is a little restrictive you have to approach your development in an entirely different way and this means that initially there can be a steep learning curve. There are times you question using it and want to go back to the old way. I do, however, think that it is worth it and you should persevere. The resulting code is better structured than you may write on your own and arguably easier to maintain.
On a side note, I have started adopting ES6 syntax in my Node JS code now and it will be nice when it has spread support in the LTS build.
Will I use it for my next thing? That’s tricky. If I need to create a screen or component that has any level of complexity in its interaction then I will use React and Redux. The restriction is most the sites I’m working on at the moment are very simple form based layouts with little interaction beyond hiding and showing things, and for these sites React is overkill. There is also the limitation of IE 8 support. Whilst for many people IE 8 isn’t an issue, almost everything I am working on has to have some form of IE 8 support so I must to take that into consideration.
I really like React and Redux, and enjoyed ES6 syntax and hope to use it again.