First Reactions to React

A Review of Building My First React App

We're moving our corporate site in house and I thought it would be the perfect time to try out a new javascript framework.

Sizing Up the Competition

There are plenty of good javascript frameworks out there right now; among the most popular are Vue.js, Angular, and React. (Yes, I'm aware that React is a library not a framework, but for the sake of this article, I'm going to set that aside.) There's also a ton of posts and articles that can help you understand the differences between them if you're not familiar. Breaking down all the reasons we chose React over the other two would be a whole post in itself. Maybe I'll write something comparing the frameworks and our opinions on their features in the future. For now, it's enough to say that we took a hard look at all three of these and we felt that React was the best choice for our specific situation.

Diving In

We're using webpack for build tooling, a React front-end, and a C# .NET Core API backend. Getting started was the most challenging part of the whole process with the majority of the issues coming from the webpack configuration. I only ever used gulp before and we wanted to switch to webpack so that we could more easily bundle and ship specific components to third-party API consumers. I'm sure that someone more experienced with webpack could have gotten up and running in much less time than it took me, but it's always nice to have the opportunity to learn a new tool. Besides my personal inexperience, there were some versioning issues between the .NET world and the NPM world that we needed to resolve. We also added to our own headaches by using a slightly wonky legacy environment setup (that's hopefully going away shortly) and by having some external requirements from businesses we partner with. With all of the preliminaries out of the way, we could finally get coding.

How Does This All Work Anyway?

Fortunately, React's documentation is quite good. One thing that I really appreciated is that the docs include the rationale for some of the React team's design decisions. There's even a whole section titled Thinking in React that tries to explain how to wrap your head around the declarative approach that React takes for building apps. I find that the classic problem of framework documentation not including more advanced examples can be alleviated by helping the users understand the "expected" use cases.

Components... Components Everywhere

One of the main premises of thinking in React is to decompose your application pages into small components that can be reused anywhere. The problem with this is that you can end up with a lot of components quickly which can be an organizational challenge. Typically, a framework has a required or recommended way of structuring projects, but not React. React is un-opinionated about most things including how you organize your source code. There's a lot of opinions out there about how to best do this but we found that simple groupings based on where the components are used are the easiest for our team.

Another issue that arises from the composition of small components is the passing of data through props. Once you pass a basic level of complexity it can be a headache to keep it all of your components in sync. Again, there are good ways to combat this including extensions like React Redux. This topic is pretty complicated, so all I'll say is that after a little bit of learning and practice it was a non-issue for us, especially after we started taking advantage of components' states and higher order components.

Stateful and Higher Order Components

As someone who has used a lot of jQuery in my time, getting used to the react way of handling things was interesting but oh so welcome. Instead of manually rewriting the DOM or updating values on callback bindings, it's sufficient to update the state of your application. React handles all of the re-rendering and updates that need to be done on state changes all through your app. It definitely took some getting used to, but after a little while, I was really digging the automatic stateful updates. Getting the hang of it was something that greatly increased the quality of the components I was writing as well. Instead of writing things that pass props around everywhere in a tangled web of spaghetti, I started realizing that a higher order component could be used for wrapping cross-cutting concerns. These HOC's lift the state of small components to a place where they can be best utilized to coordinate a logical section of the app.

What's Not to Love?

I've become a big fan of React. Still, there are some things that don't love. One great example is that I couldn't find a good way to do client-side input validation. It's not that there's no way to do it, it just feels cumbersome to implement. Regardless, I'm sure that some of this will be alleviated as I build up our library of common components, but that's just one more thing I have to do on top of the mountain of technical debt we've racked up from switching front-end tech. Another thing worth mentioning is JSX. It's a funny little extension of JavaScript that looks and works a lot like HTML with some key differences. I still can't decide if I actually like it or not. I think I'll have to keep using it for a while before I can make up my mind.

The longevity of JavaScript frameworks is also a major concern for most companies. Fortunately for us, we have a small team that can quickly adapt and pivot. We don't think that React is going anywhere soon, but it's also nice to be able to hedge our bets. Most of what we've written in React can easily be ported back to pure HTML and JS.

Wrapping It Up

I'm really excited to be moving our front end out of the stone age of ASP and VB Script. It's long overdue for our company and I'm glad that I was hired to be part of our big tech push. Whether it's a simple corporate home page, a client facing data collection app, or a backend admin dashboard, React works well for our in-house needs. As an added bonus, it's dead simple to bundle React components into different embeddable packages that third parties can use on their websites. Perhaps most importantly, I'm sure the quality of our front-end code increased with this latest move.