React works, in what I would call, homogeneous manner. A tree of components is going to be rendered in the given component using a render or recently introduced hydrate function. You are not supposed to change DOM elements created by React or at least do not change components which can return true from shouldComponentUpdate. But what if you need to change an element outside of the React realm? Well, portals are the way to go!
This guide is a form of writing down few techniques that I have been using with ups and downs for the past two years. Optimizations highly depend on your goals, how users are experiencing your app, whether you care more about time to interactive or overall size. It should not come as a surprise, that like always, there is no silver bullet. Consider yourself warned. Although you have to optimize for your use cases, there is a set of common methods and rules to follow. Those rules are a great starting point to make your build lighter and faster.
I know, I know. This title sounds cocky. In fact, it makes a lot of sense if you think about it. I have been asked multiple times by my friends from our local React meetup group I am organizing or by teams I am helping to develop their applications for a starter, boilerplate or a setup. This post is a result of another such question. Most of the time it is one of the two scenarios.
React components went the long way from
React.createClass through ES2015 powered
React.PureComponent and stateless functional components. I really enjoy the idea that we don’t have to “hack” the language anymore, at least not that much as we used to. The progress in this department is quite clear and brings not always obvious benefits. Using constructs built into the language/transpiler instead of relying on framework’s factory functions or constructors accepting huge configuration objects future proofs your code.
Pure functions are functions which for certain input always returns the same output without modifying its surroundings. So, they are free from side effects. Because of that feature they are easy to test and highly reliable part of your system. Why only a part? There is a lot of different side effects and it’s more probably than not that your app is full of them. Every DOM mutation, API request, pushState or even console.log is a side effect. It’s hard to imagine an useful application without side effects.
At first sight, RxJS is blown up lodash but for dealing also with async. In reality, it is so much more than that. With a few simple operators, you can implement a Redux-like state machine, schedule animation or deal with any type of events no matter whether it is WebSocket message or filling in the text input.
On 16th December I had a pleasure to give the presentation about Flux architecture pattern on ReactJS Wrocław meetup. Flux is well known in React community and has many different implementations not without reason. After short introduction I pointed out 7 common problems and compered how different implementations are trying to solve them.