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,

先查看 React DOM input 和 textarea 參考頁面中連結的疑難排解章節，然後在提供的 CodeSandbox 中重現該行為。將轉換後的受控值與文件中描述的游標跳動情境進行比較。完成的標準是：文件準確說明哪些值更新模式會導致游標移動，並且不再將有效的格式化使用情境呈現為誤導性範例。