The Perks and Perils of React

I love React. There. I said it. It’s like being gifted a magic sword that can cut through anything and instantly makes you a hero.

Okay, so maybe that’s an exaggeration, but I still love React.

It may have it’s perils, most of which (dare I say it) caused not by React itself but the middleware paired with it, but it’s all the things React brings to the table that make it special. Clearly, React is the cool kid that just moved in next door. You don’t know him yet, but you know you’ve gotta do it soon.

The best way to explain some of the perks and perils of React is to simply spotlight parts of the most recent React project I worked on. Bear in mind, it isn’t finished, but I think it exemplifies pretty well what React can do.

The Perks

Elements are the bread and butter of React. They are what we make components from. Whether you use JSX or React.createElement() you’re dealing with elements constantly in React. Here’s a pretty good example of a React element:

JSX might muddle the issue a little bit, but at it’s core a React element is just a plain old JavaScript (JS) object. In vanilla React it might look something like this:

Simple, right?

JSX makes things even simpler. As you can see from the snippet above, it’s like writing HTML directly into the browser, but it’s not. It’s still JS with some XML syntax mixed in. This (in my humble opinion) is already a step up from Rails where plain HTML is mixed with those awful ERB tags (<%= code %> or <% code %>) and you almost always are missing % or the = . Now view handling has been streamlined into one nearly pure language, making JavaScript almost pretty.

That’s the best part of all, and it isn’t necessarily a React feature. ES6 JavaScript is the bomb.com, and I can’t dream up even the smallest reason why I’d ever go back to anything less. Finally with ES6 JavaScript is coming into it’s own as a full stack language. We now have default errors, and a far more reliable this that acts more almost like Ruby’s self, almost.

The MO for JavaScript these days however is that ES6 isn’t universally supported, which is React is so great (especially if you use create-react-app) because with Webpack and Babel all those great ES6 features are made readily available to you in the development phase. And upon deployment, it’s all compiled for you into ES5 JavaScript to allow your React app to be supported across all browsers. (Or is it most? I’m never sure with JS updates.)

The Perils

Every language, library, and framework has its downside. Thankfully, most of React’s are not any of its fault, but some of the libraries we associate with it. This isn’t to say those libraries aren’t useful. There a just a few things to look out for.

State. This is actually a React feature, and it comes with a set of “bugs” that aren’t really bugs but simply some behavioral issues that work contrary to what’s expected. Basically your state might not be the state you expect at any given moment, because React batch updates you state when it’s the best opportunity to do so.

You would expect upon each click that the counter would increment by one and display below the button. However, with React pushing back state updates, it might say “1” for three consecutive button clicks before the state is actually changed.

Enter Redux. Ultimately I love Redux, too, but it’s a pain to implement at first. However minimal, Redux setup involves creating your actions, your reducers, your combined reducers, your store, and then integration of any middleware you decide to use before Redux is officially up and running in your application and ready for JavaScript to call any dispatches.

My projects Redux file tree looked like this:

src
|- actions
|     |- todos.js
|     |- todoLists.js
|     |- users.js
|- reducers
|     |- index.js
|     |- todoLists.js
|     |- todos.js
|     |- user.js
|- configureStore.js

And then it is all included in your index.js file. When first starting out it I had more Redux related files in my directory than React components. On top of that it can be a pain to keep track of which props you’ve made state and dispatch available too, but we won’t get into that here.

Fetch is the other big worry. And this truly might be because I had gotten to AJAX calls with jQuery. Fetch is the better system in the sense that it’s actually being used for what it was built for. AJAX has frankly been a giant monkey patch for applications before Fetch came on the scene, and although I like AJAX syntax better. Fetch is what we’ll all have to learn. My best recommendation here is to just read the MDN’s articles on the Fetch API. They’ll show you the ropes.

Finally, Rails. Don’t get me wrong. I love Rails, too, but I hated making it my API. Mostly because of finding a seamless way to authenticate and register users. I’ve heard tell of using Express and Node as a React backend, which allows for tighter integration since your whole app will be written in JS (much like my Rails app from before). That’s next on the research docket for me.

Conclusion

This pretty much wraps up my discussion on the Perks and Perils of React. If you haven’t given React a try. Please, do!

I highly recommend reading everything React Armory and redux.js.org. Check out Start Using React to Build Web Applications, Build Your First Production Quality React App, Getting Started with Redux, and Building React Applications with Idiomatic Redux from egghead.io if you want a break from reading or simply like watching video lectures. These guys are awesome and will give you an excellent introduction and deeper insight into all things React and Redux.

Cheers!