React’ing: Creating User Interfaces with Facebook’s Framework
Why choose the React framework for building user interfaces?
Well, there are multiple reasons: 1) it will save you time, 2) it will provide you with more flexibility, and 3) it will reduce your development risk. And that’s just the beginning. At Hyperwallet, our decision to use React wasn’t just about choosing a framework; it was about shifting the way we implement user interfaces. Five years ago, when we last revisited our user interface strategy, we were faced with a similar framework dilemma: continue with server-side rendering, or move the user interaction logic off to the browser. Back then, we made the safe choice. This time, we made the right choice, and we are now seeing the many benefits of client-side rendering with React.
Hyperwallet is in the process of publically releasing our global payout APIs. Through these APIs, we will be allowing companies to execute payouts to individuals all over the world. Additionally, individual payees will be given the option of how to accept their payments: for example depositing their funds to a bank account, via a wire transfer, or onto a prepaid card.
An integral piece of exposing our APIs is to allow integrators the ability to self manage their accounts or programs, view call log histories, and track payment data. Don’t worry, we’ll be releasing this supporting functionality through a program portal that will be developed using—you guessed it—React JS, redux, and our own APIs (we love eating our own dog food).
React’s framework has provided Hyperwallet with the perfect catalyst for implementing our UI on the client side, and it all starts with the documentation. In today’s world of short attention spans and immediate gratification, you can’t expect anyone to integrate with your framework or API unless you have a documentation set that gets you up and running in 5 minutes or less. React accomplishes this beautifully by allowing you to get started with the framework immediately, through JSFiddle. What’s more, the nuances and caveats are clearly laid out in the documentation. Never once while getting started did we feel like we were lost or unable to figure out the next step on our path.
Finding a framework that alleviated learning friction was very important for us during the evaluation phase, as we needed to quickly compare our chosen framework against what we were already familiar with, which was JSF (server-side rendering) and Angular JS (v1). It didn’t take long for our team to fall in love with the simplicity of React’s constraints:
- React is only concerned with the view in the typical model view controller architecture pattern.
- React consists only of reusable user interface components arranged in a tree like structure.
It was through these constraints that we started to realize the benefits of the framework. Chief among them was the reduced risk associated with developing the interface in React. One of the biggest problems that occurs with any UI technology is the chance of business logic leaking into the controller layer. Thankfully, since React only concerns itself with the view, leakage never becomes an issue. Another common problem with most frameworks is the complex data flow migrations that occur when mixing components, views, and controllers (see JSF, Angula JS v1). By strictly enforcing an interface composed of only components, the React framework provides a natural understanding of how views are laid out, how data flows through a component, and how a component responds to changes.
As you can see in the diagram above, a component is only concerned with the data it receives, and thus acts accordingly; it does not need to know about anything else [component view = f(input data)]. This paradigm continues when you get into state management through the flux pattern and its unidirectional data flow… but we’ll save the discussion of our usage of flux for another post.
Finally, coming from another component framework, JavaServer Faces, the concepts of components and reuse made it easy for our team to derive UI solutions from business requirements. This allowed us to proceed quickly, and with less risk than might otherwise have been had we went with Angular JS (v1). With our chosen view technology in hand, we went on to tackle the required supporting frameworks, a.k.a. which Flux implementation. I won’t get into the specifics of why we went with redux at this time, but I can assure you it was a great choice. Stay tuned; I’ll be detailing our reasoning for this approach in the next dev blog posting.
At Hyperwallet, we have a driven and talented team of cross-disciplinary developers. They are what keeps us competitive in the fast-paced and ever-evolving fintech sector. You’ll be hearing a lot from them—and from me—in the coming weeks, on topics ranging from Architecture and Design, Process and Practices, Performance, and Integrations. Have a fintech topic you’d like us to comment on? Then feel free to shoot me a message through the Author Contact form directly under this blog posting.
