Update EuiInMemoryTable's and EuiCustomItemAction lifecycle for React 16.3

[chandlerprall]

For #763

• EuiInMemoryTable implements getDerivedStateFromProps to replace componentWillReceiveProps. Moved items into component state instead of accessing it from props.
• EuiCustomItemAction componentWillMount -> componentDidMount

[cjcenizal]

⭐️ Thanks for tagging me on this, it's awesome seeing these changes being made! I had one nitpicky suggestion, feel free to ignore it.

I know that duplicating items onto the state is the idiomatic way to address this kind of situation. I think one vulnerability of this pattern is that someone may see items on state and think it can be manipulated internally, when really we're just caching it until the corresponding prop changes. Do you think it's worth thinking of a naming convention or other pattern we can reuse in the future to make it clear that this type of state property isn't meant to be changed?

For example, maybe prefixing it with an underscore, state._items. Or naming it explicitly: propItems. Or name-spacing it inside of an object: state.props.items (I think I like this one the most). Just something that indicates that it isn't a traditional state property.

[cjcenizal]

Minor nit, but since we're exiting early on line 247, the else isn't necessary.

  static getDerivedStateFromProps(nextProps, prevState) {
    if (nextProps.items !== prevState.items) {
      // We have new items because an external search has completed, so reset pagination state.
      return {
        items: nextProps.items,
        pageIndex: 0,
      };
    }
    return null;
  }

[chandlerprall]

@cjcenizal I played with pre-computing the visible items and storing on state, but it gets repetitive as you must explicitly re-compute the items when the pagination or row length state values change. getDerivedStateFromProps is not called after a setState, only on a parent re-render. I applied your suggestion to store items under state.props

[chandlerprall]

getDerivedStateFromProps is not called after a setState, only on a parent re-render

And then React 16.4 was released last night which fixes that, so getDerivedStateFromProps is called after setState. Oh well, in the future we can do something with that.

[cjcenizal]

Haha well at least they fixed it quickly! It's pretty cool that their guidance is to store previous props as state.prevProps if needed, which is close to what we were thinking.