A problem with Input[type="number"] arrow controls

[dmitriy-kudelko]

Hey guys,

We observe a weird behaviour with arrow controls when both min and max props are provided.

On the example page here the input field legitimately hides the down arrow since the current value (0) is equal to the min prop.

However, the same happens even if the value is not zero, say 10. I assume that in this case both arrows should be shown initially, but this doesn't happen. If we now remove one of constraints, say max both arrows become visible.

Does it seem to be a bug?

It's worth mentioning that we're using it as a controlled component providing value and onChange props.

[TwilioPasteBot]

Disclaimer: This is a very experimental bot using OpenAI's GPT-4. The answers may not be correct, a human will review the answer and update it if necessary.

---

Sorry, I don't know how to help with that.

I did do a search though, and I managed to find these other Discussions that might be similar or related to your question. Give them a read to see if they answer your question. If they do, head back here and update this discussion and mark it as answered, pointing others to the related discussion:

• Issue with Input component (updated: 11/16/2023, similarity score: 89%)
• Issue with Input component - Answer (updated: 11/16/2023, similarity score: 85%)
• Combobox error on switching between controller/uncontrolled input (updated: 08/04/2022, similarity score: 84%)

[dosubot[bot]]

🤖

Hello @dmitriy-kudelko!

I'm Dosu, a bot that’s here to assist you with bug resolving, answering questions, or helping you become a contributor while you're waiting for a human maintainer. Nice to meet you! Please feel free to reach out if you need any help.

Based on the current implementation of the Paste Input component with type "number", the arrow controls' visibility is determined by the min, max, and step props, as well as the current value of the input. The increment button is hidden when the current value plus the step value is greater than the max value, and the decrement button is hidden when the current value minus the step value is less than the min value. This behavior is expected and is not a bug.

Here is the relevant code that handles this:

React.useEffect(() => {
  if (type !== "number") return;
  if (disabled) {
    setShowDecrement(false);
    setShowIncrement(false);
    return;
  }

  const numVal = Number(internalValue);
  const numStep = step && !isNaN(Number(step)) ? Number(step) : 1;
  const numMax = Number(max);
  if (isNaN(numMax)) return;
  const numMin = Number(min);
  if (isNaN(numMin)) return;

  if (numVal < numMax && numVal + numStep <= numMax) {
    setShowIncrement(true);
  } else {
    setShowIncrement(false);
  }
  if (numVal > numMin && numVal - numStep >= numMin) {
    setShowDecrement(true);
  } else {
    setShowDecrement(false);
  }
}, [max, min, step, disabled, type, internalValue]);

This code is inside a React.useEffect hook, which means it runs whenever any of the dependencies (max, min, step, disabled, type, internalValue) change. The internalValue state is updated whenever the input value changes, as shown in the onChange handler:

onChange={(event) => {
  if (props.onChange != null && typeof props.onChange === "function") {
    props.onChange(event);
  }
  setInternalValue(event.target.value);
}}

So, the increment and decrement buttons should always reflect the current state of the input value, min, max, and step values. You can find this code in the Input.tsx file.

Additionally, there are no known issues or bugs reported related to the arrow controls of the Input component with type "number" in the Paste repository. The test cases for the number input type, including the arrow controls, are passing successfully. Here are the relevant test cases:

describe("Number Input", () => {
  it("increases when step up clicked", () => {
    const { getByRole } = render(<Input type="number" defaultValue={1} />);
    userEvent.click(getByRole("button", { name: "step value up" }));
    expect(getByRole("spinbutton").value).toBe("2");
  });

  it("decreases when step down clicked", () => {
    const { getByRole } = render(<Input type="number" defaultValue={3} />);
    userEvent.click(getByRole("button", { name: "step value down" }));
    expect(getByRole("spinbutton").value).toBe("2");
  });

  // Other test cases...
});

These test cases ensure that the arrow controls of the number input type are working as expected. They test the increment and decrement functionality of the arrow controls, including the behavior when the input value reaches the minimum or maximum value. You can find these test cases in the input.test.tsx file.

I hope this clarifies the behavior of the arrow controls in the Paste Input component with type "number". If you have any other questions or need further clarification, please let me know.

-Dosu

Sources

• packages/paste-core/components/input/src/Input.tsx
• packages/paste-core/components/input/tests/input.test.tsx

---

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[dmitriy-kudelko]

It looks like that according to the following logic above it should work correctly, but it doesn't seem to be the case:

if(numVal > numMin && numVal - numStep >= numMin) {
  setShowDecrement(true);
}

So there might be in an issue with the initial internalValue value calculation.

[TheSisb]

I was able to reproduce this issue here: https://codesandbox.io/p/sandbox/paste-starter-kit-forked-xqgs8v?file=%2Fsrc%2Findex.tsx

We will look into this and implement a fix soon. Thanks for reporting!

[dmitriy-kudelko]

Yes, this is exactly the behavior that we observe.

Sounds good! Thanks @TheSisb 👍

[TheSisb]

The PR has been merged, but it may take a few days for the new version of Paste to be released with the fix. Will report back when it's out.

[dmitriy-kudelko]

Wonderful! Thanks again 🤝

[SiTaggart]

A fix was released in Core v20.8.0