A tour of modern frontend with React and Flux
We are available for Go/Python/Haskell/Data Science projects. Drop us a mail at [email protected]!
Reading time: ~10 minutes.
In this article we are going to have a look at my preferred set of tools for writing React/Flux web apps. If you don’t know React or Flux, you can finds their documentation at their respective websites: React, Flux.
Tools of the trade
- A constant changes in libraries and their sheer number were making it very hard to keep up-to-date definitions
- Typescript is still lacking support for some things, making some libraries like ImmutableJS and its records very hard to use in a type-safe way
- Getting tired of casting things to
because of the compiler not picking up the correct things
I do very much like types though and since they are not in the horizon of ES standards, so I will have a look at Flow when it fully supports ES6. Flow differs from typescript by only being annotations that you can strip down and inferring as much as possible from the context instead of being a language like Typescript.
If you look at most React/Flux boilerplates, you will notice they often use different tools than you might be used with Angular for example.
Firstly, as mentioned in the previous section, Babel is omnipresent along with its linter of choice, eslint.
A good number of projects eschew tasks runners such as gulp in favour of a tool called Webpack and npm tasks. Webpack is a module bundler like Browserify but while Browserify takes the Unix philosophy of having small modules working together, Webpack comes with a lot more out of the box. Both works great though, so choose the one you like the most.
In terms of actual dependencies, we obviously need React. Since 0.14, you will also need the react-dom package to actually render.
In terms of Flux implementation, my favourite is Redux which actually deviates of the Flux reference, leaning towards a FRP (look here for a nice introduction on Functional Reactive Programming) approach like Elm and having pure functions.
The documentation of Redux being first-class, I will not write about it and invite you to read it, even if you aren’t planning to use it. Bindings for React can be found under the react-redux package.
A very nice thing about having pure reducers in Redux (the equivalent of stores in Flux) is that you can easily build time-travelling tools, replay actions and testing become trivial. Look at redux-devtools for the official one.
Lastly there is another optional dependency I like: ImmutableJS. Reducers in Redux are pure but using ImmutableJS gives us a faster
shouldComponentUpdate (more info) as we can compare our props by reference rather than inspecting their values deeply.
Looking at that list may appear daunting at first and plenty of boilerplates exist but they didn’t fit my own needs as I was first writing it in Typescript.
Switching to Babel was pretty trivial as it only involved changing loaders in webpack and the linter.
Combining live reload of components and reducers with the simplicity and easy testing of React and Redux makes for a very good developer experience. Some may wonder why not use Elm, ClojureScript or PureScript when looking at what we end up (and we would get types in some of them too!). This is a good point and we are going to look into Elm more seriously in the coming weeks so expect a post about our experience soon.
- Share on Twitter
- Share on Facebook