suffix not working properly in jest + testing-library

[csantos1113]

Describe the issue and the actual behavior

typing a number with 2 digits in a NumericFormat with suffix result in the wrong value when done in a jest test.

Describe the expected behavior

typing with jest should result in the same behavior as if typing in browser

Provide a CodeSandbox link illustrating the issue

https://codesandbox.io/s/recursing-poitras-rxtjkj?file=/src/index.test.js

Provide steps to reproduce this issue

• go to "Browser" in CodeSandbox
• type 9
• notice:
  • input value is 9 people ✅
  • caret position is after the 9 ✅
• type 1
• notice:
  • input value is 91 people ✅
  • caret position is after the 1 ✅
• go to "Tests" in CodeSandbox
  • the test will type 91 and expect 91 people as outcome
  • the input value ends up being 9 people 😢🔴

Please check the browsers where the issue is seen

• Chrome
• Chrome (Android)
• Safari (OSX)
• Safari (iOS)
• Firefox
• Firefox (Android)
• jest + testing-library

Additional details

After a lot of local debugging; it seems that when userEvent tries to type 1 (from 91); the caret is placed at the end of the input, so the input value is: 9 people1 which gets cleaned up back to 9 people making it fail

[csantos1113]

I get the same error with

decimalScale={4}
fixedDecimalScale

Basically, anything that adds something to the right messes up with the caret position

[csantos1113]

I wonder if the following validation is correct (and/or why it was needed)?

react-number-format/src/number_format_base.tsx

Lines 118 to 122 in e2179f9

	timeout.current.setCaretTimeout = setTimeout(() => {
	if (el.value === currentValue && el.selectionStart !== el.selectionEnd) {
	setCaretPosition(el, caretPos);
	}
	}, 0);

the solution for my error is:

- if (el.value === currentValue && el.selectionStart !== el.selectionEnd) {
+ if (el.value === currentValue && el.selectionStart !== caretPos) {

But I would like to understand why the current check is needed before I open a PR proposing my change.

---

Update:
I actually see my "solution" was proposed here: #736 (comment) but it ended up being different; so yeah, I'd love to know why it is checking against el.selectionEnd instead of caretPos