React is all the rage right now. And since Smashing Boxes is always all the rage, we decided that we should start using React. It all began in Smashing Labs, our weekly innovation time, when a few developers started making small apps using React. It didn’t take long before we realized it had a LOT of potential. It was time to bring in an alternative to Angular.So for the first time at Smashing Boxes, React was used as the sole framework (okay, “library”) for a client project. We were amped to get started but we definitely had to answer some important questions beforehand. A few:
- Facebook Flux or Redux? [Flux]
- How would we incorporate TDD with React? [It actually wasn’t that hard]
- Webpack instead of Gulp and Bower???? [Yes]
To be fair, Greg, the single greatest developer ever, answered those questions. I just tagged along for the ride.So how did we make it work? We only delivered high quality code, took the time to refactor, and wrote unit tests for every bit of logic. Delivering high quality code is not easy. For me, it meant that I had to study up on all the new ES6 hotness that was available. With that, Greg and I (okay, 99% Greg) could truly harness JavaScript to write object oriented code. It also meant that we had to learn the best ways to create a React/Flux file structure. We ended up completely separating the four main data handlers (actions, components, stores, and services for dispatching). This was the final structure:
Once we had an idea of how we would handle new code from that point on, we could start.In order to write high quality code, we’d occasionally have to scrap something we had just written, recognize when our methods had too much responsibility, or determine that a piece of logic was being reused and should be written as a service so it could be referenced throughout the app. When this happened, we’d stop what we were doing, and make that refactor. Taking time to refactor was paramount to writing a solid React app.The obvious concern is “It’s working. Why take valuable time to rewrite code some other way?” Because now the next feature we implement may only take 75% of the original time. And the one after that may only take 50% of the time. When you accrue technical debt and don’t pay up immediately, you’ll pay for it later when you’re having to work off of sloppy code. If you keep hitting features while ignoring the technical debt, it WILL compound. And now a feature that should have only taken one day has taken one week. It’s the equivalent of stretching after your workout. Taking 15 minutes to stretch could save you from months of rehab in the long run.While refactoring continuously is amazing, it’s equally as powerful as having your app tested. There is almost no logic in our app that isn’t covered by unit tests. QA took it to another level and even had automated feature tests. Because we were test-conscious, we were able to confidently refactor or add in a new feature without fear that something was breaking. There are many reasons why using TDD is necessary for medium-large apps but I won’t bore you with the details here.That’s how you protect yourself when using a new technology on a deliverable project. You continuously take a step back and think, “is this the best code I can deliver to the client?” If the answer is ever no, you take the time to refactor, add tests, rename methods, etc. Because we continuously paid off that technical debt, we delivered a top tier React web client.So why did we use React instead of using the tried-and-true framework, Angular?It’s because React is JavaScript centric instead of HTML centric (Angular). We felt that React has a proclivity for high quality, object-oriented code since all logic could be contained in JavaScript. This would also make unit testing considerably easier.At Smashing Boxes, we have the opportunity to continuously try new technologies. It was another chance to learn the ins and outs of a new library and see if we could use it on future projects. That’s the nature of development here. We are always pushing ourselves to continue learning. And the best way to learn a new technology is to USE it in an application.Will we be using React on other projects?Oh yeah! Almost all the developers here want to use it on their next project. Most importantly, there’s a lot of support for React within the company since close to every front end developer has tried React. We can now send React changes through the code review ringer with confidence.We can’t forget, React is still very young. There are still many packages/modules/libraries that will be coming out in the next few months that will drastically change the React ecosystem. The code we wrote this project may very well be outdated in a year. But it says something that we delivered a high quality app using React, despite React still being fairly unestablished.We won’t quit using Angular. We’re not calling React the GOAT. But React is a great client side framework (library…) that we were happy to use and will continue using on future projects.Need extra muscle on your next React project? GET IN TOUCH.
