I started to write a blog post detailing everything I’ve learned over the last few months building applications with React & Flux. After writing down about 10% of it, I realized it was becoming far too long. So, instead, I’ll be doing a series of posts over the next few weeks.
Over the last two months, interest in React has had a surge of interest. If you look at the search term reactjs over the last 12 months:
With many people discovering React & Flux, and their benefits, I thought it would be helpful to share our experience with them.
We’ve been using React at work for several months now. We’ve liked it so much that we sent a developer from each team to ReactWeek for a full week of training. We’re big fans of React, Flux, and both of their futures.
However, it hasn’t been 100% easy learning it. React, and especially Flux, requires you to re-think how you would traditionally write your client-side JavaScript, how it pulls data from the server, etc. This post shares some thoughts on our journey to learn and use React & flux.
React: The View
React solves one problem, and it does so really well: the view. It makes it very easy to organize your view logic while also writing reusable components. I’ve used other templating systems in JS and PHP, and React definitely has felt the most natural for me. Using React by itself isn’t actually that difficult. The hardest part with using React at first was getting your JSX files to compile to JS. We’re currently using webpack to compile our JS & JSX files, and in the past we used Browserify.
Once you get used to transforming your JSX files, using React by itself becomes very simple. We have a project where we are creating a reusable header for multiple products that live under the same domain. It is done all in React, and each site just passes the correct props data into it. The data the header uses doesn’t change once it has been passed to the header. So while the header has many dynamic elements to it, it’s state is static.
Where things get tricky is when you want to introduce dynamic data. React is still awesome at this, but understand how to do it properly requires some understanding. Especially if you want to build a Single Page app.
Flux: One-Way Data Flow
So as you read the React documentation, you’ll see links and references to the Flux Pattern. I watched the video and thought “this is awesome!” I’ve built projects using Backbone, Ember, and Angular. I’ve ran into the same scaling & consistency problems they described in the video with two-way binding. Just like when I learned about React and how it works, when I learned about Flux I thought “this totally makes sense, we’re doing this.”
The only problem was that while I felt both React and Flux were awesome, they are radically different. This may turn some heads to word it like that, but hear me out.
React is a JavaScript library. It is very concrete, it has versions, it has new releases, etc. You download it and use it. It has great documentation and when I google problems I encounter I typically find solid, definitive answers.
Flux is a Design Pattern. So while at the same high level it makes a lot of sense, it isn’t concrete and definitive as React. It is like REST, where there are a million different ways to implement a RESTful API. While something can very clearly use React or not use React, when you implement a Fluxful design, it isn’t yes or no. It really is more varying degrees of Flux-like design. If you look at the Flux website, there are only code exmaple of ways you could implement a Flux design. The have a 247 line Dispatcher.js example file, which is mostly just comments.
So this is where I personally ran into a lot of cognitive dissonance with trying to use React and Flux. On the one hand, the React side of things was relatively simple to implement. When I ran into issues, I could figure them relatively easily.
Flux, on the other hand, felt like I was just getting wrong again and again. I’d get about 2/3rds of the way done with an implementation and think “I’ve structured this wrong, let me re-do this.” I was feeling frustrated because the React part was so straightforward. Flux, on the other hand, felt like I had to do wrong & completely rewrite before I started to get it less wrong.
This was about the time I came across Dan Abramov’s post A Case for Flux. I think it is required reading for anyone who wants to do React & Flux. He does a great job of breaking down the whys of Flux. Go read his article if you haven’t, but he summarizes that “You Might Need Flux…”
- … if your data changes over time.
- … if you want to cache data in memory, but it can change while cached.
- … if your data is relational and models include and depend on each other.
- … if the same data is assembled from different sources and can be rendered in several places throughout the UI.
Understanding the whys of Flux really helped me understand how to implement a Flux-like pattern in my own code.
Libraries for React & Flux
So if I were to start a new React/Flux project today, I would look at two libraries to help implement Flux. Several of these libraries that our team learned about at ReactWeek.
- Reflux – Simple, straight-forward library that allows you to define Actions & Stores in very similar way as React Components. Has great mixins for your React Components, and you can define Mixins for your Stores. Actions also have great Async/Promise support.
- Flummox – This looks like the library to use if you want to do an isomorphic app (render both server and client side). While building our isomorphic app, I ran into every single problem they set out to solve.
Aside from using Reflux or Flummox, if you’re builing a Single Page App I recommend looking at react-router. It works really well, and what I’ve used it on each React project I’ve done.
Note on Isomorphic apps
One of the biggest features of React that interested me was the ability to render React components both on the server side in Node, and the client side in the browser. With our news apps, we must send out HTML for the page for the first request. However, if I wanted to load additional pages in a continuous scroll, I need templates written in PHP for our server side, and then in a JS template like handlebars for client side. It was a lot of work maintaining both.
Our first serious foray into React & Flux was an Isomorphic site powered by our CMS’s REST API. In hindsight, I would build something client-side only first. Rendering both server-side and client-side, while pretty cool, adds a whole new level of complexity. If you’re building an App interface that doesn’t care about SEO, OpenGraph, etc I would try to do client-side only first.
So What’s Next?
While most of our React projects are in-house, over the weekend I wrote a tool called Clarity. It is a Dashboard tool for munging data from GitHub and Pivotal Tracker. It is completely written in React & a Flux Pattern. I’ll likely refactor it to use either Reflux or Flummox, but feel free to poke around. I’ll go over these next few weeks discussing how I solved some problems it seems most people face when trying React & Flux in the first place.
Until the next post!
— Carmony
Justin Carmony 