Since a few days Facebook has its official tool to create a React web application. Gulp, Grunt, Webpack, Browserify, Babel, ... forget about it - no more fuss with it. It's all too easy now!
Currently, I am refactoring a mid-size application which I started more than a year ago (additionally, to my daily workload). The project is a ReactJS application consisting of more than 120 components already. I started developing without Flux (mainly, due to the fact that I didn't understand the need for Flux initially). In the meanwhile, I gained a deeper knowledge of Flux and decided to go for it in that project. I chose nanoflux as a Flux implementation, my very own implementation. While I think that Flux is - once understood - a very simple concept I discovered that one challenge is to decide what shall be treated by Flux and what not - By far, not everything that is a state is worth being shifted towards Flux.
A few weeks ago I complained that calling asynchronous operations inside Reacts lifecycle method
componentWillMount like AJAX may have collateral effects. In my case, the application hangs and stuck inside an infinite rendering loop. I discovered that my first attempt to solve the problem was by no way the solution, although I thought it was. The real cause was an unfortunate composition of components. The scenario was the following:
Today I'd like to talk about a composition pattern, which can be best denominated as Decorator. Like in object oriented programming the decorator wraps a component and extends its functionality, usually without changing the basic behaviour. With the composition capabilities of ReactJS it is possible to adopt this concept and allows to create components that extends other components, for example by visual effects, or pure functional behaviour like logging activities. In this article I'll present a simple use case demonstrating the pattern.
Today I spoke about ReactJS at the DevCamp 2015 in Campinas in the interior of state São Paulo, Brazil.