What’s New In React 16.3.0 – 16.4.2 | K&C React Dev

React released version 16.4.2 today. As always, the K&C React development team is on a mission to keep you up to date with the latest versions of React. Here’s our guide to the new features present in the last two iterations of React – 16.3.0 and 16.4.2. And of course, if you would like to speak to one of K&C’s React or web development consultants please do get in touch!

The most anticipated feature of the React 16.3.0 release was the introduction of a new context API designed to be more efficient and support both deep updates and static type checking. It is well known that React has already tried multiple experimental APIs. However, they had an “unofficial” disclaimer attached to them and not recommended for use. So, after multiple experiments and debugging, it looks like React has finally managed to represent the updated API that will simplify state management without the need to resort to Redux / MobX.

The React store is built on top of the new context API.

Here is an example of a basic implementation.

https://github.com/didierfranc/react-waterfall

instead of Redux in simple use cases;

• if you want to reduce prop drilling when passing props
• several times down to the root children;
• to control theming in your app;
• to control the flow of data;
• for localization.

Despite the React 16.3.0’s new Context API, there are still cases when you may need to use Redux. So, when do we need to use it and when to avoid?

Rule of thumb – “if you don’t know why you may need to use a Redux – DO NOT use it”

Let’s take a closer look at the advantages that the new API offers, as well as disadvantages that can be overcome with Redux.

• The new Context is easier to implement;
• You don’t need an additional library;
• There’s less code, it’s better understandable.

Limited functionality. It doesn’t offer:

• Great set of development tools as in Redux;
• No ‘undo’ (time traveling);
• Less scalable;
• Not as many of ready-to-use tools as Redux can offer (ecosystem).

To summarize the above said, we’d say that the new Context app could be used for data flow in smaller apps, while in some cases you should stick to previous versions that will keep working for all React 16.x versions. However, with React 17 the old API will be deprecated, so don’t forget to migrate on time.

Previously, React alloweded for the management of refs in two different ways: through legacy string ref API and the callback API. Legacy strings had multiple significant downsides, like problems with async, render props or static typing, which is why React recommended to use callbacks.

In the new 16.3.0 version, in addition to callback refs, which will continue to be supported, React has eliminated all the downsides and introduced new createRef API, which can be an ergonomic alternative to callback refs.

Now, there’s also another new ref API that comes with the 16.3 version – the Object Ref API. It brings the simplicity of strings API combined with the stability of a callback ref API. Object refs should be a good fit in most cases Finally, another new API that was introduced is the forwardRef API, which enables a ref to be taken and forwarded as a normal prop. This ref can be used to access a nested element.

The React API evolves over time, which has led to a few problematic lifecycle methods that have meant bugs need to be eliminated and replaced by the newer API versions. Components that will soon be deprecated and prepended with UNSAFE are:

• componentWillMount
• componentWIllUpdate
• componentWIllReceiveProps

These methods have proven to be a source of confusion and bugs in the past and they also need to be deprecated in light of React’s steady movement towards Async Mode.

So what can we use instead? The React team offers the following migrations for the deprecated methods:

16.3 – Everything works as before

16.x – Everything works as before, but the deprecation warning will be added

17 – Still works with “UNSAFE_” prefix

Now let’s move to new methods that were introduced with React 16.3 release

-getDerivedStateFromProps

This method is actually static (ES6). Since it’s static, you can’t reference it, so whatever is returned from the method would be updated. It will be called on the initial mounting of the component, as well as when it’s re-rendered. This method is considered to be a safer alternative to the legacy componentWillReceiveProps. And in the version 16.4.0, the React developers managed to do so that every time under component rendering, getDerivedStateFromProps is now called every time regardless what caused the update.