Components: better, modular slider-related controls

[ciampo]

What problem does this address?

The RangeControl component is a slider + (optional) NumberControl and icons. Its monolithic approach has a few limitations — for example, it doesn't allow for a UnitControl component to be used instead of NumberControl.

The new approach aims at isolating the "slider" part to a separate component, so that we can more easily compose it with different components (e.g. NumberControl and UnitControl)

What is your proposed solution?

As initially discussed in https://github.com/WordPress/gutenberg/pull/40462#issuecomment-1104376886, the tentative plan is to:

• [x] Convert RangeControl to TypeScript. This is necessary to make sure we have the best understanding of the component and its public APIs (and that we can iron out any issues before proceding). #40535

  • [x] Issue to fix: https://github.com/WordPress/gutenberg/pull/42571

• [ ] Create a new SliderControl component. This component would basically be only the slider part of RangeControl (ie. no number input field, no icons..). #42315

  • [ ] When it comes to the implementation of this component, we have a couple of choices: we could use the code from RangeControl, or instead use the approach from the g2 Slider. In both cases, we should then "adapt" the code to the current format recommended by the guidelines (e.g. TypeScript, Emotion, hooks/components..)
  • [ ] SliderControl should be written in TypeScript, styled with Emotion, connected to the context system
  • [ ] Question: should the SliderControl component be based off BaseControl ?
  • [ ] Can we fix the issues with the included ToolTip which is cut off when at extremes of range against other containers due to absolute positioning?
  • [ ] Should SliderControl have sifferent sizes ?
  • [ ] We could initially decide not to export SliderControl from the components package

• [ ] Create two new components that build on top of SliderControl:

  • [ ] This would be a good moment to discuss the internal layout of these components (e.g. should they always be on one "row"? Should the input be shown first, of the slider track?)
  • [ ] These components would ideally inherit most of their types from the underlying components (e.g. NumberControl, UnitControl, SliderControl), which means that ideally, at this point the NumberControl component will be fully typed (and we'll have an agreement on the type for the value prop)
  • [ ] SliderNumberControl (name TBD), which internally uses NumberControl and SliderControl (plus support for icons?)
  • [ ] SliderUnitControl (names TBD), which internally uses UnitControl and SliderControl (plus support for icons?)
  • [ ] Explore adding the ability to dynamically set max and step for SliderUnitControl see this comment for details

• [ ] Convert all internal usages of RangeControl to SliderNumberControl or SliderUnitControl as needed

• [ ] Alias RangeControl to SliderNumberControl. In doing so, we should add a "compat layer" to translate from RangeControl's public APIs to SliderNumberControl's new APIs (similarly to what done for ColorPicker)

• [ ] Mark RangeControl as deprecated

• [ ] Clean up or refactor any custom styling of RangeControls once they are aliased or replaced. BorderRadiusControl and the SpacingSizesControl in the block editor included.

[ciampo]

cc @aaronrobertshaw and @mirka , let me know if there's anything in the plan outlined above that you'd like to discuss / change.