6.0 - `onConnected` should be called even if not connected.

[justinbmeyer]

This test doesn't work in can-component:

https://github.com/canjs/can-component/blob/d5fbce6786261f93a73b0748a5fe30757154160e/test/component-events-test.js#L170

[justinbmeyer]

The problem is that disconnected callbacks are called before the connected callbacks:

var done = assert.async();
var doc = globals.getKeyValue('document');
var parent = testUtils.getFixture();
var wrapper = doc.createElement("div");
var called = false;

domMutate.onNodeDisconnected(wrapper, function(){
	assert.ok(called, "connected called before disconnected");
	done();
});
domMutate.onNodeConnected(wrapper, function () {
	called = true;
	assert.ok(true, "connected called");
	done();
});

node.appendChild.call(parent, wrapper);
node.removeChild.call(parent, wrapper);

This happens currently because handleTreeMutations batches all removes before inserts.

I think we did this for performance reasons, but I'm going to undo this and see if it fixes things.

[justinbmeyer]

After updating onNodeRemoved to be queued, there is another problem. Namely, that with a virtual DOM, an element can be disconnected and inserted into something (say another element). Then when that outer element is inserted, the inner element won't have connected called on it because at its first mutation, it was disconnected.

[justinbmeyer]

There's another problem that is related to the solution to the previous problem ...

If say an element is appended and then removed right away ... checking if it's "connected" at the time of the batch doesn't help.

[justinbmeyer]

The original problem I was facing was this test in can-component:

Component.extend({
            tag: 'child-tag',

            ViewModel: DefineMap.extend({
                init: function () {
                    inited++;
                }
            }),
            events: {
                ' inserted': function () {
                    debugger;
                    console.log("!  inserting  !")
                    inserted++;
                }
            }
        });

        Component.extend({
            tag: 'parent-tag',

            view: stache('{{#shown}}<child-tag></child-tag>{{/shown}}'),

            viewModel: DefineMap.extend("ParentTag",{},{
                shown: { default: false }
            }),
            events: {
                ' inserted': function () {
                    // marked as `inserted` when the `div` is inserted
                    // when `<parent-tag>` mutation is then re-run
                    // inserted happens again ...
                    debugger;
                    this.viewModel.shown = true;
                }
            }
        });

        var frag = stache("<parent-tag id='pt'></parent-tag>")({});

        domMutateNode.appendChild.call(this.fixture, frag);

<child-tag> is appearing to be inserted twice because:

1. QUnit creates the fixture element.
2. We append <parent-tag> to the parent element.
3. A Mutation for the <div> fixture is created.
4. CanJS sees the <parent-tag> inside the <div> and calls the <parent-tag>’s inserted, which sets shown to true. This will eventually append the <child-tag>
5. A Mutation for the <parent-tag> insertion is created. This will see <child-tag> and call inserted on it.
6. A Mutation for the <child-tag> insertion is cerated. This will see <child-tag> and call inserted on it.

[justinbmeyer]

I'm now unsure about how to proceed.

Essentially, we'd like a "snapshot" of what is happening to the DOM.

If we are using MOs, the data about if the element is connected or not comes late. We need to rely on the MO.

If we are using domMutateNode, we know the state of the DOM, but when we process the mutations, the state might have changed.

I think the most simple fix is to make processedState include connected information.

Basically, if the connected state changes, we are able to dispatch the connected listeners.

This would allow us to dispatch "connected" on an inner element that has already had its "inserted" fired.

Basically "inserted" and "connected" should be treated differently.

[justinbmeyer]

basically ... we should:

• include in the mutation if it was "connected" or not at the time of the mutation. ALL MO events we can assume are connected.
• store if elements have been inserted, connnected AND removed, disconnected
• while dispatching, for each added node, check if it's been inserted yet or connected yet.