August 22, 2016 at 12:18

ReactJS Year of Use: Summary

Original author: JetRuby Agency
  • Transfer
We love and appreciate React at Voximplant. Not at all because of the hype (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 the interface into small isolated pieces is what Jade / Pug, Web Components, and even Angular lacked.

Under the cut is an adapted translation of an article in which the JetRuby Agency developers share their impressions of React: what they used, what they did not use, and what they still plan to use.


Almost a year has passed since we started using ReactJS and digesting 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 an Rails API server. The overall impression is deeply positive.

What we liked:

  • Good and clear source. The React declarative style makes it easy to understand code and avoid unnecessary complexity. Which strives to accumulate in the UI.

  • Explicit distinction between server and client code. You can easily share 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 (with the exception of degenerate cases like games or something just as interactive). But it is worth noting that recently we often come across articles (for example, this one ), the authors of which claim that React is slow.

  • If you want to open the API out, then developing a SPA application for it will be the best possible test. Moreover, the code that interacts with the backend can be moved into one or several separate modules: this is much better than AJAX hardcode requests in Flux. For example, a module for working with settings can make different requests, depending on whether the application is running on the prod or on the stage.

  • A large number of different Flux implementations. 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 "stories", while others use one global object with FRP or events to coordinate components. You can always choose what you like best. We chose Fluxxor, but we don’t use its implementation of the store, only actions. To work with the state, we chose the approach with one global object and use the Baobab library. From the outside it looks like a re-complication, but we at the company like flexibility.

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

  • The lack of well-maintained, ready-to-use components. Of course, this is a matter of chicken and eggs - their number will increase along with the growing popularity of React itself. But we live here and now.

  • Forms and validation. They are difficult to do. Plus, there are not so many ready-made high-level libraries for creating forms.

  • For our application, we used a custom theme with a lot of jQuery code. It turned out that it’s not so easy to integrate seamlessly into a React application! 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 did not find a good one ready ( this one did not have all the functions we needed). So we had no choice but to design a suitable jQuery plugin as a React component. If you are interested in this topic, then you can read more here .

A few technical solutions that seem right to us and that we want to recommend:

  • Use one side. And that's why. Firstly, the main problem with multiple stores is their synchronization. If you need data from one store for which data from another store is needed, you will have to register it explicitly using the waitFor () function . With the growth of the application, there will be more and more such relationships and it will become more difficult for you to manage them. Using a single store for state management solves such problems. A good candidate for such a store is the implementation from the Baobab library. You can consider it as a kind of local database that lives on the frontend.

  • Use webpack to build modules. Now for this assembly there are many solutions, for example, grunt or gulp together with browserify or requirejs, but webpack is a bit more powerful. Direct inclusion of css, images and fonts in React components allows you to make css more manageable.

  • Use cursors to pass React data to components. This powerful abstraction allows you to not 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 off-the-shelf integration with React supporting PureRenderMixin

What we want to try in the next application:

Use Babel

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

Isomorphic applications

This is a trend right now. If you have not heard of this approach, here is a good review 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 instantly displays in the browser, and then when JavaScript loads, ReactJS will “hook” to the already rendered page and the application will come to life.

Use Functional Reactive Programming (FRP) for coordination (as a Flux dispatcher)

There are several good libraries for using FRP in JavaScript (RxJS, Bacon, Kefir). The main idea is to represent variables as a sequence of their 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 transform a sequence of events into a stream of events and manipulate such flows as objects.

One side for state management

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


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

Immutable data structures

In some cases, their use allows you to write faster code. In which, in addition, there will be fewer bugs due to the lack of mutable objects and values. Although Baobab does not offer immutable data structures (persistent only), it does not recommend directly modifying the data tree, but suggests using the API functions for this.

The author of the image (in front of the cut) is Stefpet , Creative Commons 2.0 .
Tags:

Also popular now: