Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

A React App Done Right

DZone's Guide to

A React App Done Right

Learn about developing the highest quality app with React by looking at code quality, project structure, and other considerations.

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

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.

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:

  1. Facebook Flux or Redux? [Flux]
  2. How would we incorporate TDD with React? [It actually wasn't that hard]
  3. 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.

So why did we use React instead of using a tried-and-true framework?

It's because React is JavaScript centric instead of HTML centric. 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'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.

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

Topics:
mobile ,react ,mobile app development ,ios ,native

Published at DZone with permission of Jordan Hammond, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}