After making our journey from Flux to Redux, we were happy with how clean and simple our state management had become so we kept ticking along.
Author’s note: this isn’t an argument against Futures, there’s nothing wrong with them as such! This article is about good abstraction and proper separation of concerns when using them.
The aims of functional programming are much the same as any other discipline of software engineering: modularity, abstraction, low coupling, high cohesion, and so on. While the techniques and terminology are often new to developers, the goals and benefits are expressible in very familiar language — because it’s all software, and we’re trying to achieve the same thing! (Read SICP for more background on software engineering fundamentals expressed with functional ideas).
REA recently released major revisions of both our iOS and Android realestate.com.au apps. We made great improvements from both a design and user experience perspective. For the development team these improvements required big changes under the hood.
It’s not news to anyone any more, so I’m sure everyone knows Amazon Web Services (our major cloud infrastructure provider) suffered an outage within one of their availability zones on Sunday June 5th. AWS is split up into various geographic regions, and within each region, a number of availability zones. I’m going to assume most readers know about this, but if you don’t, check out Amazon on how they describe these things. On Sunday one of these availability zones suffered a “power event”, owing to Sydney’s wild weather on the weekend, bringing it to its knees. Lots of Australian based websites had major problems.
A Little Bit of Background
During this project, we came across a few different use cases for some cross-cutting concerns, such as page load tracking, toggling new features on and off, and desktop/mobile toggling. We wanted to implement these in a generic and reusable way to avoid code duplication. For example, we had different pages (routes) in our application, and wanted to track user visits to those pages, but didn't want to duplicate this tracking code for every route.
We initially used React mixins for some of these problem, but ended up replacing it with higher-order components. In this blog post, I'll first provide a brief introduction to higher-order components (HOCs), and will then go through our journey for each use case and will explain each of the aforementioned techniques (mixins and higher-order component) in more details.