Remove componentWillReceiveProps from ColorPicker

[oandregal]

We want to get rid of componentWillReceiveProps method #11360

Some context

This is the ColorPicker tree:

ColorPicker

• Saturation
• Hue
• Inputs
  • Input (for HEX)
  • Input (for RGB - actually, three inputs, one for each band)
  • Input (for HSL - actually, three inputs, one for each band)

The ColorPicker acts as a coordinator of the different color views (Saturation, Inputs) and keeps them in sync - when one changes the color, the others are updated. It uses some utils to work with colors (such as converting #fff to #ffffff and so on).

Besides those updates, the Input leaf components were updated when some internal state changed. They used this internal state as a cache. They didn't notify the ColorPicker of changes on every keystroke, only for certain kind of events (when the users hit the ENTER key, on blur, etc).

The problem

The Input leaf component was updated both on state and prop changes. It took advantage of componentWillReceiveProps only executing when props changed to differentiate state and props changes. This is considered an anti-pattern in React and the reason why they deprecated componentWillReceiveProps in favor of getDerivedStateFromProps.

Unlike componentWillReceiveProps, getDerivedStateFromProps is called when either props or state changes, so we no longer can distinguish why the method is called (is it a prop change or a state change?) within the same component. To deal with this use case React recommends centralizing all data in one place, either in a component state (they call this uncontrolled component) or props (they call this controlled component).

How this PR fixes it

We wanted the Input leaf components to react to changes in other views (Saturation, for example) by updating their props. To achieve this I needed to do two things:

• Converting the Input components into controlled components. Lift up the cache (internal state) to the ColorPicker by distinguishing when a change needs to be commited (spread to the other views) or when a change is a draft (should only affect the Inputs view).
• Centralizing all the logic to decide when to commit changes to the colors. It was previously spread through several components, for example, the Inputs component checked if the Hex code was valid and the ColorPicker checked whether the RGB/HSL was valid to back out from notifying all the views of the color change.

Testing

• Test that changes in one view update the others.
• Test color changes only the keyboard, to make sure focus is preserved.

[jorgefilipecosta]

Things look good in my tests 👍

[oandregal]

Ugh, this has taken more time than I expected. The CodePicker component tree suffered from a couple of smells that made it difficult to work with. I've updated the description to better explain the changes here so you may want to read that first.

I still need to update the tests I've added in this PR to the new changes, but wanted to give you as much time as possible for review.

[oandregal]

I've fixed all the concerns I had about this PR and this is ready for review/merge.

Additional changes happened. Author requested a new review.

[oandregal]

@jorgefilipecosta that was a good catch, thanks! :)

@jorgefilipecosta @mcsf @ryelle It took me a few days to get back to this, sorry about that. The bug was caused by an extra check (isEmptyColor) for Saturation and Hue that I had inadvertently added in the refactor and that isn't present in master. I tested this on FF and Chrome (Ubuntu Linux):

[oandregal]

@jorgefilipecosta this is ready for a review.

[jorgefilipecosta]

In my tests, I did not found any regression so I think this PR is ready. Thank you @nosolosw for all the iterations performed. This is a nice step in removing deprecated react methods.

As noted during the discussions, we may have an opportunity to simplify the way these components work based on the prototype code shared.