Questions about Var and View updates about ui HOT 4 CLOSED

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.

from ui.

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!

from ui.

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

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

from ui.

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 :)

from ui.