Fix: input control drag and box control change

[stokesman]

As an alternative to #25913, adds some changes that fix the issues:

• avoid overwriting the react-use-gesture drag handlers 54e0484
• fix InputControl's handling of blur commits 78a0e90

Additionally, some minor enhancements:

• let UnitControl trigger parsed unit changes even if the parsed value is the same 79949f9
• corrects a small oversight in NumberControl to get value resolution working for blur commits d6aec80

Here's visual of what the UnitControl change enables:

Before	After

How has this been tested?

Storybook and Wordpress 5.5.1

Types of changes

Bug fix

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[ItsJonQ]

@stokesman Haii! Just a heads up, the BoxControl components (using UnitControls) need isPressEnterToChange. The reason is because it allows for the auto unit parsing step.

That is... typing in 50%, it can parse that out as [50, %], and propagate those changes.

[stokesman]

e801eed803d1b49be53d5b8b488db988c32516e3 This diff is kind of funky but(rebased/edited it and the diff is easier to read) I think the overall flow of the code is easier to understand now. The gist of it is to handle the parse of any entered value+unit sooner than was previously done (by the state reducer) and update state / propagate at the same time. Then all the state reducer has to do is pass it along.

[ItsJonQ]

@stokesman Haiii! I just tested this out on my end. It looks like it's working very well!
Tested it across Chrome, Safari, Firefox. Local Gutenberg and Storybook.

Tested drag interactions, "reset" interactions, intentionally going beyond min/max values via keyboard, and up/down arrows.

I left a comment for something to resolve. Once that's done, I feel okay merging this in, and closing the PR I had:
#25913

Note: I hope the the state handling/flow of these components can be improved in the future 🙏 .
That being said, I don't think the use cases would become simpler, as this logic is needed to handle complex interactions.

[stokesman]

@ItsJonQ, thanks for testing and reviewing!

That being said, I don't think the use cases would become simpler, as this logic is needed to handle complex interactions.

I'm not sure if you're talking about the UnitControl changes or the general idea of using the focus status as part of state handling logic.

If you'd prefer, I'd be glad to drop that UnitControl change (09a4127495dc66eea57b9e3a196e489c4d4fb35b) from this PR and make it into its own. I would think the old flow could be retained but still enable the new feature (changing units from a parse even when the value didn't change).

[ItsJonQ]

I'm not sure if you're talking about the UnitControl changes or the general idea of using the focus status as part of state handling logic.

@stokesman Oh, I'm talking about InputControl based UI in general (not of your specific change). Apologies for lack of clarity!

I think your UnitControl fix is great! Thank you for that 🙏

[ItsJonQ]

Hm... I'm really not sure what the PHP unit test may be failing.
@stokesman Would you be able to rebase/merge in the latest master, just in case?

Once tests are green, then I'd be happy to merge this PR :)

Thanks!

[stokesman]

@ItsJonQ, rebased on master and 💚

[ItsJonQ]

🚀 from me! Thanks @stokesman for this update 🙏