Components in sub-contexts are created multiple times

[AnAppAMonth]

Test Case

1. controller.js

define(function() {
     return function() {
          return {
               init: function() {
                    console.log('init called');
               },
               ready: function() {
                    console.log('ready called');
               }
          };
     };
});

1. spec.js

define({
     subcontext: {
          wire: {
               spec: {
                    test: {
                         create: 'controller',
                         init: 'init',
                         ready: 'ready'
                    }
               }
          }
     }
});

Expected Result

init called
ready called

Actual Result

init called
init called
ready called
ready called

Even Worse

In this test case, the component test is placed inside one level of sub-context, and the lifecycle listeners are called twice.

What about placing it inside 2, 3, or 4 levels of sub-contexts? You guessed it! The lifecycle listeners will be called 4, 8, or 16 times in these cases.

Analysis

The lifecycle listeners are called multiple times because the component test is created multiple times. Why?

Let's look at the scopes that are wired in this process:

First, it's { subcontext: { wire: { spec: { test: { create: 'controller', init: 'init', ready: 'ready' } } } } }. This is expected.

Second, we would be wiring the sub-context, which is { test: { create: 'controller', init: 'init', ready: 'ready' }, wire: { spec: { test: { create: 'controller', init: 'init', ready: 'ready' } } } }

Third, we wire a scope using spec { spec: { test: { create: 'controller', init: 'init', ready: 'ready' } } }, because there isn't a factory named "spec".

Finally, we wire a scope using spec { test: { create: 'controller', init: 'init', ready: 'ready' } }, because there isn't a factory named "test".

The problem is mixin of the wire: { spec: { test: { create: 'controller', init: 'init', ready: 'ready' } } } part into the sub-context's spec to be wired.

[briancavalier]

This is quite possibly the best bug report we've ever gotten :)

I tested this against b9822c7, which is before the fix in #123, and was able to reproduce the problem. Then, as of 8228c45, it seems to be fixed. That seems to indicate that the problem was indeed related to the spec mixin bug that was fixed in #123.

So, I think both master and dev are ok now. I'll add a unit test specifically for this case, and then close this. I'll also release 0.10.1, which will include the fix.

[briancavalier]

Unit test added in 4c66f67. Verified that it breaks in 5fe8445, but passes in 2371067 (master), and also in 88d35e8 (dev)