Questions about Var and View updates

[cata]

Hi,

I was wondering what are your thoughts on:

1. preventing spurious Var updates:

• Currently, Var.Set will trigger an update of the corresponding View even if the current Var value is the same with the one being set.
• As calls to Var.Set can be triggered as a result of external events, one currently has to check the Var value prior to setting a new one, in order to prevent spurious updates.

I was wondering if you would be partial to introducing an internal check for equality in the Var.Set function
If so, I can create a pull request.

2. preventing spurious View updates:

• Currently, there are no equality checks in the various Snap functions (Map, etc.) This means that, when composing Views, one can end up with unnecessary updates on the resulting view.
  For example, given a function f: a-> b that can yield the same b for distinct values of a and a view A: View, should one create a view B as View.Map f A, one would observe spurious View B updates (i.e successive updates of View B, say with the values bx and by even though bx = by )

Given my current understanding of UI.Next, I think addressing this would require changing the Snap implementation. This would be helpful in simplifying client code (right now I need to perform these checks in functions generating the UI, to avoid unnecessarily recreating DOM elements)

Are you open to such a change?

[SimonJF]

Hi,

Thanks for the comment -- I'm one of the implementers of UI.Next, and it's always good to see user comments!

Unfortunately, there are a couple of reasons why I don't support this proposal. In particular, the main reason for this is that Vars of say, unit type, can be set in order to trigger a callback function. By setting a Var of unit type's value as (), for example, a function in a Sink can be triggered, which is a useful pattern in some circumstances. Indeed, this would break the implementations of SnapshotOn and UpdateWhile (although these may be revisited in future -- we have plans to look at Hopac-style concurrency abstractions for event handling at some point).

For a similar reason, the second suggestion wouldn't work. Indeed, the implementation of the dataflow->DOM integration relies on views of unit type being triggered, so if this was done, the entire system would break :) Have a look here for an example of what I mean: https://github.com/intellifactory/websharper.ui.next/blob/master/WebSharper.UI.Next/Doc.fs#L356

It might be an idea to introduce specialised versions of Vars and Views which have more specific properties regarding updates, for example only triggering when the value is different.

Regarding not unnecessarily creating DOM elements, this functionality is implemented already and the preservation of node identity was an important part of the design. If you use the View.Convert family of functions instead of Map, you can preserve DOM elements when something changes. Take a look at around 27:00 of Anton Tayanovskyy's tutorial, https://www.youtube.com/watch?v=wEkS09s3KBc, the Documentation on Sharing, and the TODO List Example.

On the other hand, I think your pull request for the form component certainly looks reasonable and should work. I'll have a play with it once I'm back on my Windows laptop!

Thanks again, and sorry it took me a while to reply.

[cata]

Hi Simon,

Thank you for the detailed explanation and code pointers. I certainly don't want to break the system - I love it :)

I was misled by the fact that my experimenting with the Var implementation by adding an equality check on Set (which did involve introducing a number of cascading type restrictions) did both build and appeared to work in my application (which does not hit the Sink execution path you've mentioned). This led me to wonder whether the behavior could be extended to the view updates.

I will move to use View.Convert in the code where I am now performing manual checks - thanks again!

[SimonJF]

Thanks for the response, and glad you're enjoying UI.Next!

Great -- hope it works out. Please let me know!

[cata]

It did work out, and beautifully so :)

'''Document.Convert''' proved to be the simplest solution in my case - the Convert family of functions works like a charm 👍

Regarding the pull request: I'm now using a fork of UI.Next with that particular change included and haven't seen any ill effects. I hope you can include it in the next nuget version, it would save me the headache of maintaining a separate fork.

Thank you for your help - Convert is a very nice way to deal with time-varying collections in a sane manner - I should have read the docs more carefully :)