ReactJS year of use: sum up

React we love and appreciate in Voximplant. It’s not because of HYIP (one and a half thousand tweets about the new SDK, simply because it is React Native), but because the framework is really convenient. Simply splitting up the interface into small isolated pieces is something that Jade / Pug, Web Components, and even Angular lacked so much.

Under the cut, an adapted translation of an article in which the developers of JetRuby Agency share their impressions of React: what they used, what they didn’t use and what they are still planning to use.


Almost a year has passed since we began to apply ReactJS and digest a sea of ​​related technologies. And we are here to share our experience with you.
')
We recently completed a project that used client-side rendering and a Rails API server. The overall impression is deeply positive.

What we liked:

• Good and clear source code. React's declarative style makes it easy to understand code and avoid unnecessary complexity. Which and strives to accumulate in the UI.
  
  
• Explicit differentiation between server and client code. You can easily divide tasks between front-end and back-end developers, and they will not intersect with each other.
  
  
• Thanks to Virtual DOM technology, page changes happen very quickly (except for degenerate cases like games or something just as interactive). But it is worth noting that lately we often encounter articles (for example, this one ), the authors of which claim that React is slow.
  
  
• If you want to open the API to the outside, then developing a SPA application for it will be the best possible test. Moreover, the code that interacts with the backend can be put into one or several separate modules: this is much better than hardcoding AJAX requests in Flux. For example, the module for working with settings can make different requests depending on whether the application is running on the prode or on the stage.
  
  
• A large number of different implementations of Flux. Well, if you like to keep abreast of technology. It’s bad if you just want to do something quickly and don’t know what to choose. Some implementations use several “stores”, others use a single global object with FRP or events to coordinate components. You can always choose what you like more. We have chosen “Fluxxor”, but we do not use its implementation of stor, only actions. To work with the state, we chose an approach with one global object and use the Baobab library. From the side it looks like an over-complication, but we in the company like flexibility.

Naturally, in this new beautiful world, not everything is so beautiful. We still encountered a number of problems:

• The lack of well-maintained, ready-to-use components. Of course, this is a question of chicken and eggs - their number will increase with the growing popularity of React itself. But we live here and now.
  
  
• Forms and validation. They are hard to do. Plus ready-made high-level libraries for creating forms is not that much.
  
  
• For our application, we used a custom theme with a lot of jQuery code. It turned out that it is not so easy to integrate seamlessly into the React application! It is technically possible, but I would not recommend doing this if you have ready-made components or resources to do this from scratch. In our case, we needed a date time picker on bootstrap, and we didn’t find a good finished one ( this one didn’t have all the functions we needed). So we had no choice but to arrange the appropriate jQuery plugin as a React component. If you are interested in this topic, then you can read more here .

Several technical solutions that seem right to us and which we want to recommend:

• Use one side. And that's why. First of all, the main problem with several storages is their synchronization. If you need data from one store, for which you need data from another store, you will have to write it explicitly using the waitFor () function. With the growth of the application of such relationships will be more and you will be harder to manage them. Using one stop to manage states solves similar problems. A good candidate for this is the implementation from the Baobab library. You can consider it as a kind of local database that lives on the front end.
  
  
• Use webpack to build modules. Now for such an assembly there are many solutions, for example, grunt or gulp together with browserify or requirejs, but the webpack is a bit more powerful. The direct inclusion of css, images and fonts in React components allows you to make css more manageable.
  
  
• Use cursors to pass data to React components. This powerful abstraction allows you not to transfer intermediate data down the “chain” of components, which greatly simplifies the code. We used cursors from Baobab, but there are many other good implementations. Baobab was chosen because of its simplicity, straightforwardness and ready integration with React, which supports PureRenderMixin

What we want to try in the following application:

Use babel

Babel is already officially used by React to work with JSX. But, even if you do not use JSX, Babel is still an excellent tool for front-end development. Who does not want to use all these cool features of ES6 and ES7, without waiting for their support in browsers?

Isomorphic applications

Right now it's a trend. If you have not heard of this approach yet , here is a good overview from the Airbnb team. The idea is to render the HTML page on the server, transfer it to the client (with caching and CDN) so that it is instantly displayed in the browser, and then when JavaScript loads, ReactJS will “pick up” to the already rendered page and the application will “come to life”.

Use Functional Reactive Programming (FRP) to coordinate (as a Flux Dispatcher)

There are some good libraries for using FRP in JavaScript (RxJS, Bacon, Kefir). The basic idea is to present variables as a sequence of changes, and combine these changes using functions such as map , filter , reduce, and higher-order functions (a function that takes another function as an argument). For the user interface, this approach makes it possible to convert a sequence of events into a stream of events and manipulate such flows as objects.

One stop for state management

Gives only one, but a huge advantage. Since there is no local state in the components of React, we can consider the UI as one pure function (a term from functional programming) that receives one input state as an argument and returns the user interface (more precisely, its React representation) corresponding to this state. In practice, this approach allows for real-time debugging, undo and redo, time travel. Here you can see how it's all done:

• debug.elm-lang.org/edit/Stamps.elm - debugger for Elm
• www.youtube.com/watch?v=Fo86aiBoomE - the same, but implemented in JS, the debugger from the cerebraljs library is used
• www.youtube.com/watch?v=5yHFTN-_mOo - t about what the guy from CircleCI did, guys use ClojureScript Om, which also uses one object to store state. A more detailed description of how it all works.

This approach takes testing and debugging of web applications to a completely new level. No longer need screenshots and a long list of “playback steps”. If you encounter a bug, simply copy the current state of the application and give it to the developers.

Immunity data structures

In some cases, their use allows you to write faster code. In which, moreover, there will be fewer bugs due to the absence of mutable objects and values. Despite the fact that Baobab does not offer immutable data structures (only persistent), he does not recommend directly changing the data tree, but suggests using API functions for this.

Image author (in front of the cut) - Stefpet , reative Commons 2.0 .