Weird troubleshooting info for controlled inputs?

Hi team! 👋

During our translation work I came across a weird bit of troubleshooting advice on the <textarea> page.

Quite expectedly, it's also found in the <input> page.

It basically states that setting the controlling state variable to anything other than the raw e.target.value (e.g. transforming it to uppercase, used to illustrate the "bug", only it works just fine) is the cause for the caret jumping back to the beginning.

This seems misleading and borderline incorrect; one of the key benefits of controlled inputs is our ability to format / filter / validate values live (think phone numbers, SSNs, CC numbers, VAT identifiers, etc.) and this only moves the caret back when the resulting value is shorter. It doesn't reset it to the beginning.

Here's a CodeSandbox demonstrating things are just fine for many use-cases of setting the controlled value to a transformed version of the incoming DOM value.

Any light on this? What are the actually problematic patterns for caret jumping?

Best,

Bắt đầu với các phần khắc phục sự cố được liên kết trên các trang tham chiếu về React DOM input và textarea, sau đó tái hiện hành vi trong CodeSandbox được cung cấp. So sánh các giá trị được kiểm soát đã chuyển đổi với kịch bản nhảy con trỏ được mô tả trong tài liệu. Công việc được xem là hoàn tất khi tài liệu giải thích chính xác những mẫu cập nhật giá trị nào gây ra việc di chuyển con trỏ và không còn trình bày các trường hợp sử dụng định dạng hợp lệ như những ví dụ gây hiểu lầm.