custom snabbdom props module

[cornerman]

As discussed in #105, this adds a custom snabbdom props module, which compares against the actual element property.

Please do not merge, as I think, the generated code for scala-js is not as performant as a pure javascript implementation. So, we should implement this module in js and somehow include it with scalajs-bundler/webpack.

What do you think?

[cornerman]

here is an example of how to have custom javascript resources: https://github.com/scalacenter/scalajs-bundler/tree/master/sbt-scalajs-bundler/src/sbt-test/sbt-scalajs-bundler/js-resources

[mariusmuja]

After reading snabbdom/snabbdom#345, I'd like to do some benchmarking on how this affects the performance for patching larger VNodes that contain multiple props.

[fdietze]

@cornerman which properties are used by outwatch?

[cornerman]

only these five props: value, checled, selected, textContent, indeterminate.

If we wanted we could also use the prop module for the reflected attributes, but there we currently use attributes.

[fdietze]

The current alternatives to the custom snabbdom-module are:

• The old valueSyncHook (also reads from dom, so probably worse performance)
• Via Handlers (<-->) from Problem with updating user-changeable properties #105 (updates the dom on every keystroke)

Before taking the time to benchmark this approach, are there any other (theoretically) faster alternatives?

[cornerman]

exactly, the ValueSyncHook did actually the same before for the value property. Here even reading the attribute AND the property:

  private val valueSyncHook: (VNodeProxy, VNodeProxy) => Unit = (_, node) => {
    node.elm.foreach { elm =>
      val input = elm.asInstanceOf[HTMLInputElement]
      if (input.value != input.getAttribute("value")) {
        input.value = input.getAttribute("value")
      }
    }
  }

[mariusmuja]

Agreed, all alternatives for keeping the DOM in sync seem to have similar trade-offs. Except that with the current snabbdom props, the DOM value only gets updated if it changed and the --> gets updates via Events, not from reading the DOM.

So, I don't know what the performance of the <--> alternative is, as for values it doesn't update the DOM on every keystroke, it reads the DOM on every keystroke event and skips updating because it didn't change)... something to benchmark.

Just occurred to me about reflected attributes... what is the performance of updating an attribute vs updating a prop (with the current snabbdom props module). Would the performance be better to use props instead for reflected attributes ( since most reflected attributes don't get changed by another agent)

[fdietze]

So, I don't know what the performance of the <--> alternative is, as for values it doesn't update the DOM on every keystroke, it reads the DOM on every keystroke event and skips updating because it didn't change)... something to benchmark.

I don't understand what you are trying to say here. Most keystrokes on an input field change the value. So it only skips in the rare cases of keys which don't change it (e.g. arrow keys). Am I overlooking something?

[mariusmuja]

I don't understand what you are trying to say here. Most keystrokes on an input field change the value. So it only skips in the rare cases of keys which don't change it (e.g. arrow keys). Am I overlooking something?

I was thinking of the current props implementation that handles value as a special case and only writes the DOM prop it if the value changed compared to the actual DOM value. So, for something like this:

input(tpe := "text", value <-- strHandler, onInputString --> strHandler),

there is no DOM prop write on each keystoke, only a DOM prop read.

... but that's exactly what the proposed props module does too. And since outwatch is only updating 5 props though the props module and the rest are reflected attributes, I'm not so worried any more about the performance impact (I was forgetting earlier that we're using reflected attributes for all other props and I was worried about the performance impact of reading the DOM when updating each of them).

[cornerman]

Just occurred to me about reflected attributes... what is the performance of updating an attribute vs updating a prop (with the current snabbdom props module). Would the performance be better to use props instead for reflected attributes ( since most reflected attributes don't get changed by another agent)

This is still a valid question, but I do not know of any benchmarks and how syncing between props and attributes actually behaves.

[LukaJCB]

Thanks for working on this!