The register mismatch between display value in input and reactive variable about core

[YiMo1]

这种情况确实存在，因为vue会通过hasChanged函数判断新旧两个值是否相同来决定是否执行trigger，但由于你事先将input元素的值发生了修改，然后将修改后的值传递给ref，导致hasChanged函数判断为false，所以dom无法及时更新，如果你确实需要对input的value属性做出修改后再传递给ref，那么请你对updateText函数作出这样的修改：

const updateText = (e) => {
const value = e.target.value;
text.value = value;
text.value = text.value.toLowerCase();
};

先将input元素的原始值传递给ref，让hasChanged函数判断为true，这样vue就会把effect放入执行队列中，然后再将text.value的值修改为你想要的值，这样就可以正确的响应式。且由于vue对effect做了去重处理，所以你不必担心dom更新两次。

希望对你有些帮助。

[LinusBorg]

I can't reproduce the behavior of the video in the linked playground on either Chrome, Safari or Firefox.

Please provide more detail and a reproduction that acutally reproduces the issue. also test your reproduction in different browsers, with extensions disabled etc.

[zh-lx]

I can't reproduce the behavior of the video in the linked playground on either Chrome, Safari or Firefox.

Please provide more detail and a reproduction that acutally reproduces the issue. also test your reproduction in different browsers, with extensions disabled etc.

It can be reproduced when change the value of the input from aaa to aaA. Because the text.value is both aaa((hasChanged(value, oldValue) === false), so it won't execute trigger.

[mcmimik]

@LinusBorg

1. Type aaaaa into the input field.
2. Select the middle a (using the Shift key or the mouse) and replace it with an uppercase A. Observe that the input field shows aaAaa, but the ref variable does not update.
3. Now, replace an a with a different letter, like B, and notice both the displayed value and the ref variable value change accordingly.

[mcmimik]

@zh-lx So, it turns out that if I want to reliably synchronize a ref variable with an input, I should always use v-model with @input and never rely on :value? Otherwise, discrepancies between the reactive variable and the input's internal value might occur.

[mcmimik]

It appears that the source of truth for an <input> with the :value prop and @input handler becomes not the prop itself, but the user's input. Is this architecture intentional and considered desirable behavior?

It seems that developers must "catch up" with the new value, as noted by @YiMo1, through double assignment. This looks odd. For instance, in React (sorry), achieving the same goals does not require extra manipulation:

const [text, setText] = React.useState('');
const handleSetText = (e) => {
  const value = e.target.value;
  if (/^[a-z]*$/.test(value)) setText(value);
};

<input value={text} onChange={handleSetText} />

My question: Is the current approach in Vue considered optimal for handling user input, and are there plans to simplify this aspect to make the behavior more intuitive?

P.S. Here is also a real-life example illustrating the consequences of non-obvious behavior, which leads to different solutions, like this one:

<input v-model="model" @keydown="onKeydown" />

const onKeydown = (e: KeyboardEvent) => {
  if (
    regexpPattern.value &&
    !regexpPattern.value.test(e.key)
    // and many other extra keydown checks
  ) {
    e.preventDefault();
  }
};

Here, I omitted the logic with handling the Backspace key, cutting through Cmd+X/Ctrl+X, but it also needs to be additionally described.

All of this could be avoided if the <input> simply looked at the value from the :value prop, and user input did not affect anything other than sending input events and others.

Perhaps there is a more elegant solution; I would appreciate a tip!

[yyx990803]

This is expected behavior IMO, as when you are assigning text.value = value.toLowerCase(), the old text.value and the new text.value is exactly the same. To Vue this means nothing has changed state-wise, so no updates will happen.

Avoiding updates when no state change has happened is fundamental to performance, so this is not something that can or will be changed.

You can use either the workaround by @YiMo1 or use v-model with a watcher.

[mcmimik]

Appreciating the prompt response, @yyx990803.

Noting a nuance: the <input> in Vue appears to favor user input over the :value prop. Wondering if this is intentional and if there's a thought about bringing it in line with the prop's role as the main source? This seems to be a central quirk in the issue.

[yyx990803]

The central issue here is that there is no update is happening because no reactive state has changed.