State binding optimization

[efpage]

I came across this code snipplet in the example [State objects as properties](https://vanjs.org/tutorial#state-typed-prop)

  const value = van.state("")
  return span(
    input({type: "text", value, oninput: e => value.val = e.target.value}),
    input({type: "text", value, oninput: e => value.val = e.target.value}),
  )
}

This shows state propagation from one input to the other. So, one is acting as a source and one as a target.

What happens here?

• you select one element for input and type some text
• The new value updates the state object
• The new state updates both inputs, source and target.
  So, everytime you add one letter, the source is also updated.

I was wandering, if this has any effect or if there are any benefits on using different states like this:

  const text1 = van.state("")
  const text2 = van.state("")
  return span(
    input({type: "text", value: text1, oninput: e => text2.val = e.target.value}),
    input({type: "text", value: text2, oninput: e => text1.val = e.target.value}),
}

Here, each input has it´s own state, The source is only updating the target state and vice versa

I could not find any differences in performance, but did not really understand, why. So, here are my questions:

• is there any mechanism that prevents unnecessary updates on the source?
• are there situations, where it could be better to use separate states?
• can it happen, that we get a closed update loop and do we need to be careful about that?:
  - state A updates B
  - B updates A
  - ....

[Tao-VanJS]

Thanks for your question!

First, a note on performance: my hypothesis is that the native DOM implementation is smart enough to skip the execution when the underlying value property is not changed, and the overhead of testing whether the property is changed or not is negligible in benchmark testing. The general, the philosophy of VanJS is not being overly obsessed with performance benchmarking, as there are only sparse scenarios where benchmarking results could translate to noticable difference in the user experience. However, the clarity and simplicity of the code matters in every application.

Back to the original questions, for this specific use case, should we use separate states? My opinion is no. First, we want the code reflects the actual application logic, where in this case, the value of 2 input boxes are designed to be synchronized, thus having a single state reflects that exactly. Second, in this case, the application logic is that the values of the input boxes are always in sync with the val property of the state, but in the code above with separate states, while handling the input event, we only update the val of one state, not the other, causing out of sync between states and the property values they are bound to.

For the 3rd question, yes it's possible to have an infinite loop due to circular dependency, especially if we code not carefully enough with onnew event handlers. Here is an example:

const a = van.state(0), b = van.state(0)
a.onnew(v => b.val = v + 1)
b.onnew(v => a.val = v + 1)

a.val = 1

[efpage]

Hy Tao,

thank you for your detailed answer. It is important to understand the implications and limitations of the concept.

I was expecting some kind of complication if a state change is reflected back to an object that caused the state change, but it is very nice to see that this is not the case. Possibly this is covered also by this part of the code in Van.js ?

    if (v !== curV) {   // <== check for value change?
      if (s.oldVal === curV)
        changedStates = addAndScheduleOnFirst(changedStates, s, updateDoms)
      else if (v === s.oldVal)
        changedStates.delete(s)
      s._val = v
      for (let l of s.listeners) l(v, curV)
    }

I was suspecting that the infinite update loop was prevented by checking the value change. So I tried something very similar to your example. Luckily even that does not cause an "infinite" loop (which would cause the browser to hang), but it fails after some hundred iterations with a stack ovrflow. This is far better than an infinite loop!

So, thank you very much for your great code, it is really a marvel!

[Tao-VanJS]

For the specific example in the ConnectedProps app, here are what happened:

1. User types something in one of the text input boxes.
2. input event is triggered for the the input box which received the user input.
3. As part of the event handler, the val of state text is updated.
4. As a result, the value property of both input boxes is updated. Note that, in this step, only the input box that is not receiving user input is actually being updated, the value property of input box that is receiving the user input has already been updated to the text in the box (also the native DOM implementation is likely optimized to skip the actual execution). Also, according to DOM, input event won't be triggered if we set the value property programatically.

[artydev]

Great discussion :-)