VirtualDom.map preventing reuse of elements

[bcardiff]

During last weeks I've been working on a app that initialize a map (leaflet) in a dom element created by a view function in elm. This has been working great. I wanted for elm to manage root dom element of the page and not to be embedded in a particular dom.

So far so good.

But after tidying things a little bit and using Html.App.map in the view function, the virtual dom algorithm is unable to reuse the dom.

I've reduced as much as possible the sample in https://gist.github.com/bcardiff/d59fa6b70d4aa486534b485049c5be8e so it might look a bit cryptic . A #my-div is mutated from JS, but there is always a #my-div in the same location across life cycle of the application.

With the gist code, when rendering the view using Html.App.map the #my-div is recreated from scratch, loosing the previous mutation: http://g.recordit.co/GaF2HCbynG.gif

Oddly, if instead of using Html.App.map the view is built directly with a wrapping a -> msg function the problem goes away. That is, using https://gist.github.com/bcardiff/d59fa6b70d4aa486534b485049c5be8e#gistcomment-1887851 I got the expected behavior: http://g.recordit.co/Mflh3NmM6y.gif

Am I right in considering this a bug or is off the limits of the diff algorithm of virtual dom?

virutal-dom: 1.1.1

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[evancz]

Can you ask about this on the Elm slack to be more sure about what is going on? I'm hoping they can help refine this issue a bit more.

[bcardiff]

Sure! From reading the source of virtual dom it seems that the taggers (the entity that represents the map) are checked in the diff. But if i get correctly, the tagger should only affect the events/messages sent. So it could be safe to pull the effect of them down the hierarchy of the virtual dom and not use them as a proper node.

It might be more work for the algorithm but otherwise two semantic equivalent Html a will lead in different behavior/dom reuse.

[evancz]

Get someone from the slack to look at this. Right now, I don't know if there's anything to do here or if you'd just prefer some other optimization technique. In either case, this issue should be refined into something more specific.

[bcardiff]

It seems I am not good enough to attract attention in slack.

Either way I have reduced a bit more a sample at https://gist.github.com/bcardiff/9de0dfdde585bb7ee74dfde0ddd19c92

The first thing to decide is, given reusableView : Html Msg, if it is desired or not that changing from reusableView to Html.App.map identity reusableView should trigger a whole drop/rebuild cycle.

In case of identity it seems trivial, but for others transformation the same question holds.

The next step for sure is how to accomplish this in case we want.

This is not stopping me, there are workarounds and I am having some awesome time with elm.

[evancz]

Okay, these lines clarify what you are saying for me:

view model =
    case model of
        NotWrapped ->
            reusableView

        Wrapped ->
            Html.App.map identity reusableView

We are switching between one view, and then the same view with an additional map node. I could potentially add some additional (tricky) logic to detect this, but it is a tradeoff. There are two possible situations that could explain the addition or removal of a map node:

1. The view has changed entirely, thus explaining the drastic change in event management. Something else is showing now, and it works different.
2. The view has changed very slightly or not at all, but the event management has changed dramatically.

I took the view that 1 is way more likely in practice, and optimized for that case. Why do a big diff when you can be pretty certain that nothing is the same? Maybe you could get some reuse, but I think only if the node tag names are structurally the same.

So my question now is: what is the exact situation that led you do discover this? Please explain the particular feature you were working on as concisely as possible. Your experience suggests that 2 can happen, which is surprising to me, and it'd be good to know more about that!

[bcardiff]

As you said I reach the option 2.

I am in a SPA that change which model/view/update should be used. But accross many views there are some DOM that can be reused. In this case a leaflet.js map.

In most cases rebuilding the dom is not a problem, but here the dom is changed by external js library. To recreate/reinitialize will generate some ugly flickering to the user.

On the views of each page module that should have the map I was using a helper function:

module Shared exposing (..)

layoutWithMap : Html a -> Html a
layoutWithMap content =
    div [ ] [ mapCanvas, content ]

mapCanvas : Html a
mapCanvas = div [ id "map" ] []

Each module (PageA, PageB, etc) look something like this:

module PageX exposing (Model, Msg(..), update, view)

import Shared

type Model = ...

type Msg = ...

view : Model -> Html Msg
view model = 
    Shared.layoutWithMap ... other content ...

So they have the freedom to use layoutWithMap or just throw all the dom.

In the main module then I could do something like:

module Main exposing (..)
import PageA
import PageB

type Model = A PageA.Model | B PageB.Model

type Msg = MsgA PageA.Msg | B PageB.Msg

view model = 
    case model of
        A modelA ->
            Html.App.map MsgA <| PageA.view modelA
        B modelB ->
            Html.App.map MsgB <| PageB.view modelB

So there are different wrappers arround the layout dom.

From here I then went to the workarounds:

Alternative 1.- make the Main module aware if each page should use the layoutWithMap. And changing PageX.view to be only the content

view model = 
    case model of
        A modelA ->
            layoutWithMap <| Html.App.map MsgA <| PageA.view modelA
        B modelB ->
            layoutWithMap <| Html.App.map MsgB <| PageB.view modelB

Alternative 2.- make the PageX.view receive a wraper Msg -> a

view : (Msg -> a) -> Model -> Html a
view wmsg model = 
    layoutWithMap ... other content (use wmsg) ...

Both has pros/cons. And both persist the mapCanvas dom.

In my scenario since the mapCanvas : Html a does not send messages it is easy to combine them with other Html b.

In general, if I want to ensure the dom is persisted, instead of using Html.App.map I need to use a wrapper message function Msg -> a at the moment of creating the messages.

I jump to use Html.App.map for a SPA application with dom that I wanted to be persisted and this is where I got.

If there are better patterns to use in this case I am happy and eager to follow them.

[evancz]

I am tracking all of the VirtualDom.map ideas in #105 so that it is clearer how to make coherent changes to how it works.

I'll close here, cleaning up the issue queue. The idea is that this content is all available for reference, but easier for me to find. Point is, thanks for the report!