Keyed updates

[Rich-Harris]

This implements keyed updates, as discussed in #81. For now, it's a slightly naive implementation – it re-mounts each iteration every time the block updates, which in many cases is wasteful – but that's okay, since we can iterate on the performance aspects once we're happy that the behaviour is correct.

You opt in to keyed updates like so:

{{#each todos as todo @id}}
  <p>{{todo.description}}</p>
{{/each}}

In this case, if an item was removed from the middle of the todos array, all <p> elements would continue to represent the same todo item, as long as each todo item had an id property. (The property doesn't need to be called id, of course.)

sample code

function renderMainFragment ( root, component ) {
    var eachBlock_anchor = document.createComment( "#each todos" );
    var eachBlock_value = root.todos;
    var eachBlock_iterations = [];
    var eachBlock_lookup = Object.create( null );

    for ( var i = 0; i < eachBlock_value.length; i += 1 ) {
        var key = eachBlock_value[i].id;
        eachBlock_iterations[i] = eachBlock_lookup[ key ] = renderEachBlock( root, eachBlock_value, eachBlock_value[i], i, component, key );
    }

    return {
        mount: function ( target, anchor ) {
            target.insertBefore( eachBlock_anchor, anchor );

            for ( var i = 0; i < eachBlock_iterations.length; i += 1 ) {
                eachBlock_iterations[i].mount( eachBlock_anchor.parentNode, eachBlock_anchor );
            }
        },

        update: function ( changed, root ) {
            var eachBlock_value = root.todos;
            var _eachBlock_iterations = [];
            var _eachBlock_lookup = Object.create( null );

            var fragment = document.createDocumentFragment();

            // create new iterations as necessary
            for ( var i = 0; i < eachBlock_value.length; i += 1 ) {
                var value = eachBlock_value[i];
                var key = value.id;

                if ( eachBlock_lookup[ key ] ) {
                    _eachBlock_iterations[i] = _eachBlock_lookup[ key ] = eachBlock_lookup[ key ];
                    _eachBlock_lookup[ key ].update( changed, root, eachBlock_value, eachBlock_value[i], i );
                } else {
                    _eachBlock_iterations[i] = _eachBlock_lookup[ key ] = renderEachBlock( root, eachBlock_value, eachBlock_value[i], i, component, key );
                }

                _eachBlock_iterations[i].mount( fragment, null );
            }

            // remove old iterations
            for ( var i = 0; i < eachBlock_iterations.length; i += 1 ) {
                var eachBlock_iteration = eachBlock_iterations[i];
                if ( !_eachBlock_lookup[ eachBlock_iteration.key ] ) {
                    eachBlock_iteration.teardown( true );
                }
            }

            eachBlock_anchor.parentNode.insertBefore( fragment, eachBlock_anchor );

            eachBlock_iterations = _eachBlock_iterations;
            eachBlock_lookup = _eachBlock_lookup;
        },

        teardown: function ( detach ) {
            for ( var i = 0; i < eachBlock_iterations.length; i += 1 ) {
                eachBlock_iterations[i].teardown( detach );
            }

            if ( detach ) {
                eachBlock_anchor.parentNode.removeChild( eachBlock_anchor );
            }
        }
    };
}

function renderEachBlock ( root, eachBlock_value, todo, todo__index, component, key ) {
    var p = document.createElement( 'p' );

    var text = document.createTextNode( todo.description );
    p.appendChild( text );

    return {
        key: key,

        mount: function ( target, anchor ) {
            target.insertBefore( p, anchor );
        },

        update: function ( changed, root, eachBlock_value, todo, todo__index ) {
            var todo = eachBlock_value[todo__index];

            text.data = todo.description;
        },

        teardown: function ( detach ) {
            if ( detach ) {
                p.parentNode.removeChild( p );
            }
        }
    };
}

function SvelteComponent ( options ) {
    // ...
}

export default SvelteComponent;

[codecov-io]

Current coverage is 92.60% (diff: 100%)

Merging #209 into master will increase coverage by 0.10%

@@             master       #209   diff @@
==========================================
  Files            71         71          
  Lines          1666       1690    +24   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits           1541       1565    +24   
  Misses          125        125          
  Partials          0          0          

Powered by Codecov. Last update 4332310...d0ffb64

[Ryuno-Ki]

Ans limitations oft how @id is named? I assume it must be a valid JavaScript variable Name.

[Rich-Harris]

Currently yes. Could change it to any valid property name, though that could be done later - var names covers 99% of uses I think

[Swatinem]

I like how you pass in / attach the key prop to sub-blocks :-)

Using ${iterations}/${listName} more consistently would be nice.

From the generated code:

        update: function ( changed, root, eachBlock_value, todo, todo__index ) {
            var todo = eachBlock_value[todo__index];

That todo is redefined, although its the same as the one passed in from outside. But the same is true for the current code, so its not specific to this PR.

[Rich-Harris]

Using ${iterations}/${listName} more consistently would be nice.

Yeah – I was finding things easier to follow when it's ${name}_iterations and ${name}_lookup etc – fewer variables, easier to keep consistent. Maybe we should just remove ${iterations} etc altogether?

That todo is redefined

Whoops! In a lot of cases we probably only need to pass the todo through – the eachBlock_value and todo__index are only used in certain situations

[Swatinem]

I was finding things easier to follow when it's ${name}_iterations and ${name}_lookup etc – fewer variables, easier to keep consistent.

I actually find it easier to follow if you have one variable for each in generated code variable. Since syntax highlighting shows you the template string interpolations clearly, but suffixes tend to move into the background. Also its shorter to type :-) But I think its a matter of taste.