5 ms·
I agree with most of the things mentioned in the article, but here are a couple of nits, just in case you have that exact problem and look for the fix: $timeou
by Nitramp 13y ago
I agree with most of the things mentioned in the article, but here are a couple of nits, just in case you have that exact problem and look for the fix:
$timeout having no $cancelTimeout: that's just called $timeout.cancel(), taking the promise you got out of the initial $timeout call.
$.when is called $q in AngularJS, support for promises actually runs deep in the framework.
Regarding the difficulty of instantiating controllers, and controlling who publishes what on the $scope when: I think there should be a style rule that you never, ever have some piece of JavaScript depend on the fact that some other piece of JS adds a variable to its parent scope. Yes, that's global state, or dynamic scoping, and should never be used. Just create a service if you need two directives to communicate. This gets more obvious and easier with 1.2 and the controller-as style.
Bi-directional data binding should never get you into a loop if you take care to only use the APIs in ngModelController. If you managed to trigger a loop, you're probably using the wrong API - loops are something that can happen in bi-directional data binding, but it's not a given.
This is not to say the author is wrong, as said above, I agree with most of his points.
- Bahamut 13y agoYeah, he had a few minor incorrect details - the $q one was a big omission, it sounds like he never explored using $q.all, much less $q at all. I think Angular's complexity can be daunting without someone who can help set you back on the right path when you're stumped. We (the regular denizens on IRC) do a pretty good job in #angularjs on Freenode helping people out when we can, but it's obviously whenever people can spare the time to answer questions. I am constantly helping people at work grasp how to think the Angular way, and it has resulted in my team being incredibly productive due to Angular's excellent upsides. Regardless though, I think it's good that this article was written, even if a little prematurely. People should know both the upsides and downsides.
- lhorie 13y agoHi author here. Thanks for the feedback :) re: instantiating controllers - services definitely help, but you still have to design and expose APIs to manage the lifecycle of variables from the controllers, and often times (at least for me), there are a lot of cross-concerns and it becomes impractical to have services to deal with each permutation of concern groups (this is especially a problem in more exploratory projects). I should note that in the cases where maintainability suffers the most, I have upwards of 5 core model entities and a dozen other auxiliary ones being manipulated in a single page. Also, when things need to persist across route changes, then you're pretty much stuck to polluting $rootScope (or worse, $cookie) re: "Bi-directional data binding should never get you into a loop if you take care to only use the APIs in ngModelController" Yes, they shouldn't, but under some unexplainable circumstances they do, even when I'm explicitly avoiding all the other undocumented traps (e.g. isolated scope interop, etc). One very big weakness in Angular is internal integration testing. Given enough moving parts, even simple things that should just work start breaking in very strange ways (looking at you, ng-if).
- anoncowherd 13y agoSo why does Backbone.JS suck then? :)