React v16.4.0: Pointer Events

The latest minor release adds support for an oft-requested feature: pointer events!

It also includes a bugfix for getDerivedStateFromProps. Check out the full changelog below.

Pointer Events

The following event types are now available in React DOM:

onPointerDown

onPointerMove

onPointerUp

onPointerCancel

onGotPointerCapture

onLostPointerCapture

onPointerEnter

onPointerLeave

onPointerOver

onPointerOut

Please note that these events will only work in browsers that support the Pointer Events specification. (At the time of this writing, this includes the latest versions of Chrome, Firefox, Edge, and Internet Explorer.) If your application depends on pointer events, we recommend using a third-party pointer events polyfill. We have opted not to include such a polyfill in React DOM, to avoid an increase in bundle size.

Bugfix for getDerivedStateFromProps

getDerivedStateFromProps is now called every time a component is rendered, regardless of the cause of the update. Previously, it was only called if the component was re-rendered by its parent, and would not fire as the result of a local setState. This was an oversight in the initial implementation that has now been corrected. The previous behavior was more similar to componentWillReceiveProps, but the improved behavior ensures compatibility with React’s upcoming asynchronous rendering mode.

This bug fix will not affect most apps, but it may cause issues with a small fraction of components. The rare cases where it does matter fall into one of two categories:

1. Avoid Side Effects in getDerivedStateFromProps

Like the render method, getDerivedStateFromProps should be a pure function of props and state. Side effects in getDerivedStateFromProps were never supported, but since it now fires more often than it used to, the recent change may expose previously undiscovered bugs.

Side effectful code should be moved to other methods: for example, Flux dispatches typically belong inside the originating event handler, and manual DOM mutations belong inside componentDidMount or componentDidUpdate. You can read more about this in our recent post about preparing for asynchronous rendering.

The following code assumes getDerivedStateFromProps only fires on prop changes:

staticgetDerivedStateFromProps(props, state){if(props.value !== state.controlledValue){return{// Since this method fires on both props and state changes, local updates// to the controlled value will be ignored, because the props version// always overrides it. Oops!
controlledValue: props.value,};}returnnull;}

One possible way to fix this is to compare the incoming value to the previous value by storing the previous props in state:

However, code that “mirrors” props in state usually contains bugs, whether you use the newer getDerivedStateFromProps or the legacy componentWillReceiveProps. We published a follow-up blog post that explains these problems in more detail, and suggests simpler solutions that don’t involve getDerivedStateFromProps().