> 24. Wherever possible, use AngularJS versions of JavaScript functionality. So instead of setInterval, use the $interval service....It becomes easier to mock them or write unit tests
I've always been very against these angular versions of basic js functions because it requires everyone on the team to learn them and it puts you even deeper into the angular lock in swamp, hindering you from eventually changing your view-framework in the future. Any takes on this?
I like the data binding of angular but try to restrict angular coming in contact with "core" code. As example we hardly write any services, we just use them to hold an instance of plain js-classes that can easily be reused in non angular projects.
Services such as $interval or $timeout are very simple - $http is also a fairly simple service to replace too. I don't really view it as much of an issue when it comes to lock in or migration, there are usually far more perilous pitfalls when it comes to lack of being able to migrate, such as bad app architecture or hacks.
I agree with you. It doesn't matter how thin the wrappers are or whether they preserve the API, the problem is all code is supposed to call them.
It's no problem to call $timeout in your Controller code or whatever, but what if you want to require a module that uses `setTimeout`? Either the module has to have some way of passing in the timeout function it should call, or you'd have to have a shim that monkey patches it or something.
Services like $timeout and $interval are basically just thin wrappers around their vanilla JS relatives(setTimeout and setInterval), there are more examples like this.
The APIs look identical, some with a little added functionality - but the primary reason for the AngularJS wrappers is that they'll automatically call $scope.$apply() for you, so that you don't have to do it yourself.
I've always been very against these angular versions of basic js functions because it requires everyone on the team to learn them and it puts you even deeper into the angular lock in swamp, hindering you from eventually changing your view-framework in the future. Any takes on this?
I like the data binding of angular but try to restrict angular coming in contact with "core" code. As example we hardly write any services, we just use them to hold an instance of plain js-classes that can easily be reused in non angular projects.