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.
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 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
this that acts more almost like Ruby’s
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.
My projects Redux file tree looked like this:
| |- todos.js
| |- todoLists.js
| |- users.js
| |- index.js
| |- todoLists.js
| |- todos.js
| |- user.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.
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.