React v16.4.0: Pointer Events

Original author: Andrew Clark
  • Transfer

The latest minor release adds support for a frequently requested feature - pointer events !


Also, it includes corrections for the method getDerivedStateFromProps. A complete list of changes is available below.


Pointer Events


The following event types appeared in the 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 specification of pointer events . (At the time of writing, these browsers include Chrome, Firefox, Edge, and Internet Explorer.) If your application is dependent on pointer events, we recommend using a third-party polyphile. It was decided not to include the polyphile in the React DOM, so as not to increase the size of the final bundle.


We recommend watching this example on CodeSandbox .


Many thanks to a man named Philipp Spiess for working on this change!


Hotfix for getDerivedStateFromProps


getDerivedStateFromPropsNow it is called every time the component is drawn, regardless of the reason for its change. Prior to this, it was called only when the component was redrawn by its parent and did not work when the setStatecomponent was called . This was an omission of the initial implementation of the method, and it is now fixed. The previous behavior was more like componentWillReceiveProps, but in its improved state, compatibility with the asynchronous rendering mode, which will be available soon in React, is provided.


This fix will not affect most applications , but may cause problems for a small fraction of the components. Those rare cases when this can happen fall into one of two categories:


  1. Avoid adverse ( side ) effectsgetDerivedStateFromProps
    as the method render, getDerivedStateFromPropsmust be clean function works only with propsami and state. Side effects have never been supported in getDerivedStateFromProps, but since it now works more often than before, this change may reveal previously undetected bugs.
    The code with side effects should be transferred to other methods: for example, calls to Flux-events should be located directly in the event handler, and manipulations with the DOM should be done in componentDidMountor componentDidUpdate. Check out our recent article on preparing for asynchronous rendering .
  2. Compare new props with previous ones when calculating controlled values.
    The following piece of code assumes what will be getDerivedStateFromPropscalled when the props change:

static getDerivedStateFromProps(props, state) {
  if (props.value !== state.controlledValue) {
    return {
      // Так как этот метод срабатывает при изменении и пропсов, и состояния,
      // изменение controlledValue через setState будет игнорироваться, потому что значение из пропсов всегда будет перезаписывать его. Та-дам!
      controlledValue: props.value,
    };
  }
  return null;
}

One possible solution is to compare the new value with the previous one, keeping the previous one in a state:


static getDerivedStateFromProps(props, state) {
  const prevProps = state.prevProps;
  // Сравниваем новый пропс со старым
  const controlledValue =
    prevProps.value !== props.value
      ? props.value
      : state.controlledValue;
  return {
    // Сохраняем старые пропсы в состоянии
    prevProps: props,
    controlledValue,
  };
}

However, try to avoid mixing props and state this way - it rarely happens that a state should duplicate a value from props, and this practice can lead to implicit bugs. It is advisable to have a single correct source for any value and, if possible, pass on the parent component to be used in other components. Most use cases getDerivedStateFromProps(and its predecessor componentWillReceiveProps) are resolved by transferring the control of contraction to a superior component.


It is important to remember that most components are not requiredgetDerivedStateFromProps . He did not think of an exact replacement componentWillReceiveProps. In the coming weeks, we will post a post with recommendations on how to use (and not use) getDerivedStateFromProps.




Full changelog ( Changelog )




PS If you would like to see some kind of translation from the React world, write in PM or telegram / vk


Also popular now: