fix(number-field): add support for scrubbing

[bengfarrell]

Allow scrubbing (dragging your mouse left and right across the component to increment/decrement)

Description

When not in focus, a east/west cursor is shown over the component, and a user is allowed to scrub left and right to increment/decrement. Included in this PR is my other PR for step multipliers because it follows to add that support here as well. (#1534)

In terms of implementation, I tried to adhere to the existing pointer event implementation as best I could so we don't have duplicate handlers, but diverged such that my events don't repeat like the button ones do.

For distance per delta, it simply uses the step property as the delta per pixel, however I added another attribute that will override this: "stepperpixel".

There is some change in focus behavior here, which may or may not fly with SWC. The user interaction in other Adobe products like Illustrator (that has actually since been removed) as well as software like Blender, requires that if the user is interacting by scrubbing, the component does not focus as a result of this interaction. In fact I'm taking steps to suppress focus (including blurring the inputElement) on interaction. It's only on pointerup if the user has not scrubbed that I allow focus to happen.

This is why I had it behind a flag in my original issue, but have now removed the flag because we're being slow about this PR and merging into the next branch.

Related Issue

#1528

Motivation and Context

Our app is canvas based, and this is a nicety when working with inputs that affect the canvas. We can drag the input and watch the width/height/x/y change on canvas. I'm sure it'll help in a number of places though.

How Has This Been Tested?

Tested during dev process on Chrome

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[bengfarrell]

Just want to explain my last commit, cause it's kind of important "fix(number-field): add property to indicate that the user is scrubbing"

So, both the stepper buttons and the scrubbing behavior fire "input" events. As an aside, I'm not sure what to do about "change" events on the scrubber, since I feel like change happens on committing a focused field, but feel free to correct me if I'm wrong.

Anyway, input events can come from the stepper buttons, scrubbing, or the keyboard. The keyboard is a bit complicated because you might want to type "600", but to get there you're typing "6", "0", and "0". So during this user interaction, your input values are "6", then "60", then finally "600". In the case of transforming an item on the canvas, this is bad because it'll jump around as a user types.

So we need a way to differentiate between input events, and I don't believe the actual event supports any properties that would help with this. So, I added a "scrubbing" property that indicates that the user is currently scrubbing and use this to filter out keyboard input. I suspect you'd want something similar for button stepper interactions, but I'm not sure if it should be differentiated from scrubbing or what

[bengfarrell]

Not sure if it will help steer any decisions, but I'm finding that integrating the change and input events to be kind of tedious and repetitive. The issue is that on every numeric field I have, I'm having to filter on input, but not on change. Its adding a lot of boilerplate code to use this.

I made the following directive to consolidate these events and just listen to a new custom event:

import { directive } from 'lit-html';
import { NumberField } from '../index';

export const NUMBER_CHANGE = 'numberchange';

const onChange = (e: Event) => {
    const value = Number((e.target as HTMLInputElement).value);
    const ce = new CustomEvent(NUMBER_CHANGE, { detail: { value }, bubbles: true, composed: true });
    e.currentTarget?.dispatchEvent(ce);
};

const onInput = (e: InputEvent) => {
    const value = Number((e.target as HTMLInputElement).value);

    // on input number can be NaN
    if (Number.isNaN(value)) {
        return;
    }

    // dont event on input unless scrubbing
    if (!(e.target as NumberField).scrubbing) {
        return;
    }
    const ce = new CustomEvent(NUMBER_CHANGE, { detail: { value }, bubbles: true, composed: true });
    e.currentTarget?.dispatchEvent(ce);
};

// Normalize NumberField input/change events to numberchange event so we don't have repeated code
export const numberevent = directive(() => (part: any) => {
    part.committer.element.addEventListener('change', onChange);
    part.committer.element.addEventListener('input', onInput);
});

[Westbrook]

@bengfarrell let me know if you wanted to add/tweak anything else to this. Otherwise, I'll merge it into a local project branch so we can start checking it out with our CI/demo sites/etc.

[bengfarrell]

@bengfarrell let me know if you wanted to add/tweak anything else to this. Otherwise, I'll merge it into a local project branch so we can start checking it out with our CI/demo sites/etc.

Nope! Things have calmed down. I found a number of things to fix on my project when integrating, but right now, this is feeling good. Obviously it's going to be a bit out of step with the new changes regarding the other PR I made, but the scrubbing behavior feels solid to me