Back to Questions
252
views4
comments
WebSharper.Mvu suggestion
websharper

I think the WebSharper.Mvu model with elm-style, React-style and reactive variables is fantastic. It combines the best of both worlds.

I do have a suggestion to add to the reactive library. I took the MVU TodoMvc snippet and added a simple function:

1
2
3
4
5

    let [<Inline>] inline consistentView   (vw:View<_>)  = 
        let prior      = ref <| Var.Create Unchecked.defaultof<_>
        let setPrior v = if (!prior).Value <> v then (!prior).Value <- v 
        View.Sink setPrior vw
        (!prior).View

This stops the propagation of views that do not change, to reduce unnecessary rendering. This is the result: http://try.websharper.com/snippet/user3359/0000L8

Superficially the two snippets behave exactly the same, but from Chrome Developer Tools it can be noted that in the first snippet every element is being re-rendered whenever anything changes in the model. For instance, as someone types in a new task, all the other tasks labels can be seen flickering. In a more complex page the user could notice the lag.

Anyway, just a suggestion. The name of the function can probably have a better name.

.

Indeed I see some undue re-rendering. As far as I can tell, this only concerns text nodes; the containing element flashes, but it's really just the text content that updates. This should be fixable in the rendering engine, without needing a special View. Unless you've seen other nodes being re-rendered?

By on 4/29/2018 1:05 AM ()

Fixing it in the final rendering is, of course, a good idea, but sometimes stopping the propagation of views earlier may be useful to prevent some views that take longer to calculate to do so unnecessarily. For instance, a view may need to sort, join and then filter a collection of elements. Or a view may end up in a sink that triggers an action like invoking a parser, or saving a value to disk, or querying an external source.

By on 4/29/2018 5:06 AM ()

I agree that these are legit use cases, and I've had various ideas in the past to support them.

Part of them are covered by View.MapCached / View.MapCachedBy. These functions are equivalent to View.Map, except that they don't call their mapping function again if their input is equal to the previous input, so you can put expensive computation in the mapping function. However, it still propagates the output value downstream every time, so this doesn't cover all use cases.

The problem with using View.Sink like you did is that it has the potential to cause memory leaks if you use it in a dynamic part of the reactive graph. For example, if you call it in the function of a View.Bind, then you'll have leaks.

I've looked into what it would take to implement a non-leaking consistentView, and I think it would take a fairly fundamental change in the implementation of the reactive system. More specifically, the Snap type's obsolete callback would need to propagate the replacement Snap. I had started to experiment with this on the obsolete-snap-successor branch, but that was quite a long time ago. I should pick that back up though, because this would definitely be very useful.

By on 4/29/2018 8:16 AM ()

Good to know about the risks of leaking. This is very interesting information. I hope you find a good way to implement consistentView without too many painful changes.

In the meantime, for the elm-style solution where we have a single Var<_> containing the whole model, even a less than perfect version of consistentView (maybe even thru .V. notation) could be good to internally separate the parts that change often from the rest and reduce unnecessary processing.

Having a single Var<> makes for such an elegant solution with just one moving part. It also opens up new possibilities like the time-traveling debugger and taking elm or React code and easily porting it to WebSharper.

By on 4/29/2018 1:59 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper