Components in sub-contexts are created multiple times #128

Closed
AnAppAMonth opened this Issue Jul 17, 2013 · 2 comments

Comments

Projects
None yet
2 participants

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.

Owner

briancavalier commented Jul 17, 2013

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.

Owner

briancavalier commented Jul 17, 2013

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment