Closed wuxiaoying closed 10 years ago
Also, is it possible to not require the localInject dependency if the plugin isn't used in the classy controller?
Yes, this is a bug. Good find, thanks!
I'm happy to take a PR on this, otherwise I'll get around to fixing it next week.
I don't really understand your second question? If you're asking does your plugin need to have the localInject
property then no it doesn't require that.
By the way, I've released a simple Computed Properties plugin here: https://github.com/davej/classy-computed
The 2nd question was because if I included a localInject dependency on a plugin, then I think it injects it into all classy controllers (that loop through enabled plugins) even if the classy plugin wasn't active? It was a problem for me because it failed all my unit tests that didn't have a mock for the dependency =/,
The computed properties plugin looks very useful :).
The 2nd question was because if I included a localInject dependency on a plugin, then I think it injects it into all classy controllers (that loop through enabled plugins) even if the classy plugin wasn't active? It was a problem for me because it failed all my unit tests that didn't have a mock for the dependency =/,
Ah ok, I understand. Unfortunately, I can't figure out a better way to do that. The only way that I could get an instance of a dependency was to pass it through the controller's $inject
and then pull it out the other end when the controller is instantiated. I briefly played around with the $injector
service but I couldn't get it to do what I wanted.
I'll try and do a bit more research to find a better way to do localInject
, any ideas?
Is the ".concat(classFns.localInject)" supposed to be outside of the for loop? I get the wrong dependencies with localInject if I have more than one plugin with localInject classy-bindDependencies line 26: pluginDepNames = pluginDepNames.concat(plugin.localInject).concat(classFns.localInject)