Our latest release includes an important performance bugfix for React.lazy. Although there are no API changes, we’re releasing it as a minor instead of a patch.

Why Is This Bugfix a Minor Instead of a Patch?

React follows semantic versioning. Typically, this means that we use patch versions for bugfixes, and minors for new (non-breaking) features. However, we reserve the option to release minor versions even if they do not include new features. The motivation is to reserve patches for changes that have a very low chance of breaking. Patches are the most important type of release because they sometimes contain critical bugfixes. That means patch releases have a higher bar for reliability. It’s unacceptable for a patch to introduce additional bugs, because if people come to distrust patches, it compromises our ability to fix critical bugs when they arise — for example, to fix a security vulnerability.

If you're a React user, this is going to be a lot like going from 15 to 16. Not a lot of user-facing changes, but some interesting improvements under the hood.

The major changes (#1342) are around our TypeScript definitions, bundled CommonJS and ES builds, throwing if you subscribe or getState from a reducer, and a bunch of other smaller things. The full changes are listed below.

Enjoy!

Tons of docs updates. Thanks @markerikson and the Redux community for all your PRs!

Make middleware API dispatch pass through all call arguments (#2560 by @Asvarox)

The danger from that wasn’t really that the code was deleted, that only breaks the build and anyone worth one’s salt would catch that during the build process before deploying it live on the web.

The danger was that it was a small redundant package that no one would ever actually bother to audit before deploying, so anyone could have jumped in and published a package with the same functionality but also stick some malicious code into it and get a free ride to get deployed essentially anywhere that ran JavaScript.

Redux is a state container for Javascript apps, mostly used with React. It's based on actions that are dispatched and listened by reducers which modify the state properly. If you're not familiar with the Redux principles, you should read this article first.

This article will be focus on the first step: dispatching an action. We will see how we could do this in a way that our components are as decoupled as possible from Redux.

Let's say we're implementing a service enabling the user to send a message to a group. We're creating a form, MessageSending.js, and when pressing the SEND button, we want to send the message to our API which takes care of it.

I’ve been involved in react-redux projects for several years. After I first met with flux, I was impressed by its expressive power that describes complicated use cases in contrast to other dataflow concepts, which caused many troubles when the complexity of a project increased.

The action controlled dataflow concept is simple and clear. Data changes can be described as actions with a minimal payload. These actions make a deterministic, time-independent history of the application’s life. The application’s state at a given point is reducible by picking an action in the chain.

The concept of Redux has many theoretical principles and advantages, but I do not intend to talk about them. There is only one major disadvantage of immutability: the cost of it. But

Flux is not a library, or a framework. It is an architecture that Facebook uses internally while working with React, which follows the concept of unidirectional data flow.

The core idea of the flux architecture is the unidirectional flow of data in the application.

Flex consists of four major parts: Dispatcher, Stores, Views and Actions.

Actions: Actions are nothing but events that are fired from the views (or from other places as well) to the store. These actions flow via the dispatcher (we will cover dispatcher soon). Dispatcher exposes a way that allows us to fire an action to the store along with the data and type.

As the next round of the FOSS Outreach Program for Women (OPW) approaches, my mind turns to mentorship, and lessons learned when dealing with newcomers to open source projects. Many open source contributors have been in the FOSS community for long enough to forget how painful their first experience contributing to a project was. As the coordinator for the Linux kernel OPW internships, I get to help newcomers go through that experience every six months. I’ve learned a lot about how we, as open source reviewers, maintainers, and mentors, can help newcomers during their first contributions, and I’d like to share some of the perspective I’ve gained from OPW.

Routing in client-side applications usually starts off as a small number of routes with a few redirects or custom code here and there. But as soon as the application starts to grow and the number of features on it increases, routing commonly becomes a hard to maintain and complex domain. Ever more interactive client-side applications require an intuitive and consistent routing solution to provide a better UX, and we as developers must make sure we use equally intuitive and consistent design paradigms to deal with complex routing requirements.