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.
Nesta palestra é apresentado o conceito emergente de desenvolvimento baseado em componentes usando como exemplo o famoso ReactJS do Facebook. São demonstradas as características principais do ReactJS, tais como Virtual DOM e JSX. Além disso, são introduzidas formas de composição de componentes usando callbacks e/ou eventos.
In the third part of this article series I introduced the Dispatcher, the central hub of the Flux architecture,which is responsible for propagation of actions. I also showed, that in most implementations actions can be chained, albeit I do not recommend to make regular use of that feature. In this last part of the series I present the Action Creator which helps us to launch actions in an expressive manner.
In the second part of this article series I explained that Flux is an architectural pattern and introduced the concept of a Store, one of the essential elements of Flux. I gradually explained the meaning and functionality of a Store and how it differs from the concept of a classical model. I emphasized that a Store in Flux is responsible for maintaining and updating its application state, and notifying interested components. I concluded the article with code snippet demonstrating the usage of a Store using a fictitious Flux implementation. This part introduces the Dispatcher.