Update TIPS-AND-TRICKS.md

Author: ProLoser

TIPS-AND-TRICKS.md

@@ -27,46 +27,55 @@ Apps that don't let you access their content without being logged in don't have
 #### Don't use `controllerAs` in routes. Use it in directives only.
 _pasted from slack_
 
-controller instances are not shareable. Meaning if you put logic into a controller (`this.doSomething()`) although you can reuse the logic elsewhere, you can’t reuse the instance
-controllerAs syntax fixes a few issues, but I believe it will mislead people into thinking it’s okay to bloat controllers, which it isn’t (except for directives)
-the reason is because your special logic that’s usually stateful shouldn’t be in the controller, it should be in something stateful that can be shared
-so you should instead put most of your `this.doSomething()` into a factory, preferrably (if you follow my talks) a class or object instance
-then you can share this factory/class/instance across multiple controllers, and not just the logic is shared, but also the highly stateful data
+Controller instances are not shareable.  
+Meaning if you put logic into a controller (`this.doSomething()`) although you can reuse the logic elsewhere, you can’t reuse the instance.
+`controllerAs` syntax fixes a few issues, but it misleads people into thinking it’s okay to bloat controllers, which it isn’t (except for directives).
+Your stateful logic  shouldn’t be in the controller, it should be in something stateful that can be shared
+so instead put most of your `this.doSomething()` into a factory, preferrably in a `class` or `object instance`.
+Then you can share it across multiple controllers, not just the logic, but the **highly stateful data**:  
 `resolve: { person: function(Person) { return new Person() } }`
-you inject `person` into multiple controllers and they all share the same data, and they all update in sync
-so instead of doing `this.doSomething()` in your controller, and keeping track of info about how a `Person` works inside a controller (which is reusable, but not shareable) you should keep it inside your factories, which are even FURTHER abstracted from the view/angular-centric mindset, but are also instantiatable and manageable
-I can control more concretely when a person is created, destroyed, updated, who has access to it, how it gets reused, etc
-angular no longer handles the lifecycle of the data, i do
-my route-controllers are generally 2-10 lines of code
-$scope.person = person
-or `$scope.save = function(){ $scope.loading = true; person.save().then({ $scope.loading = false }) }` (edited)
-so my controller does nothing more than putting my business logic onto the view and occasionally wrapping business logic with view logic and / or route logic (edited)
-now lets say you STILL wanted to use controllerAs yet still keep things organized the way i described
-you CAN, except your bindings look like this: `<input ng-model=“personCtrl.person.name”>`
-instead of just `<input ng-model=“person.name”>`
-that is fairly trivial, mind you, but there is another big annoyance I have with it
-your view is no longer reusable with different controllers
-lets say i want to use the same view with a create vs edit controller
-my view bindings have to be `<input ng-model=“createCtrl.person.name”>` or `<input ng-model=“updateCtrl.person.name”>`
-or lets just say you call the controller `person` or `personCtrl`
-then you could have a view person controller and inside of it a edit person controller
-who gets which name?
-no, when you start to build big apps and deal with these design questions, I find `controllerAs` is NOT the answer
-I like having brittle scope bindings, for instance you may have cringed when i did `$scope.loading = true` because if you put a `ng-click=“loading = false”` inside of an `ng-if` it won’t work
-except i want to keep my view-state flags shallow, simple, clean, and I don’t want the view to update them
-I like having 2 controllers, both with their own `loading` flags
-I prefer not having to namespace all my loading flags by my controller name or variable or state name, and yet my views simply don’t care
-doing `ng-show=personLoading` is the same as doing `ng-show=personCtrl.loading`
-my view becomes more brittle and heavily tied to controllers
-it’s a weird like way of walking this fine line of things
-but i’ve come to find i’m extremely happy with the architecture i’ve built and it scales ridiculously well
-now in directives, it’s a completely different ballgame
-that’s because *directives* are entirely about view logic, and should almost never do business logic. Period.
-and anyone who things otherwise I humbly disagree with.
-Now the thing is, the old way of doing directives you put all your shit into a linking function
-a directive controller is essentially identical to a linking function except it is reusable by other directives
-so it’s a visual-widgets externally visible api
-so if you look at `ui-select` i love controllerAs because I can give it methods like `uiSelectCtrl.open()`
-and that really is what it’s doing. It’s the controls for my ui-select widget
-`personCtrl.person.open()` just doesn’t make sense if you read it. The ‘controller’ (guy doing shit to people) isn’t the one with the method, the object itself has methods that work upon itself
-and doing `personCtrl.open()` is just a sign of bad design, because skinny controllers
+
+You inject `person` into multiple controllers and they all share the same data, and update in sync.
+So instead of doing `this.doSomething()` in your controller, and keeping track of info about how a `Person` works inside a controller (_which is reusable, but **not shareable**_) you should keep it inside your factories, which are even FURTHER abstracted from the view/angular-centric mindset, but are also instantiatable and manageable.
+I can control more concretely when a person is created, destroyed, updated, who has access to it, how it gets reused, etc.
+Angular no longer handles the lifecycle of the data, i do.
+
+Controllers are generally 2-10 lines of code so my controller does nothing more than putting my business logic onto the view and occasionally wrapping business logic with view logic and / or route logic:  
+```
+$scope.person = person;
+$scope.save = function(){
+  $scope.loading = true;
+  person.save().then(() => {
+    $scope.loading = false
+  });
+});
+```
+
+Now lets say you STILL wanted to use `controllerAs` yet still keep things organized the way I described.
+You CAN, except your bindings look like this: `<input ng-model=“personCtrl.person.name”>`
+instead of just `<input ng-model=“person.name”>`.
+That is fairly trivial, but there is another big annoyance I have with it.
+**Your view is no longer reusable with different controllers**.
+
+Lets say i want to use the same view with a create vs edit controller.
+My view bindings have to be `<input ng-model=“createCtrl.person.name”>` or `<input ng-model=“updateCtrl.person.name”>`
+or lets just say you call the controller `person` or `personCtrl`.
+You could have a `personEditCtrl` inside of a `personViewCtrl`
+so who gets which namespace?
+
+When you start to build big apps and deal with these design questions, I find `controllerAs` is **NOT** the answer.  
+I like having brittle scope bindings, for instance you may have cringed when i did `$scope.loading = true` because if you put a `ng-click=“loading = false”` inside of an `ng-if` it won’t work.
+Except I _want_ to keep my view-state flags shallow, simple, clean, and I don’t want the view to update them.
+I like having 2 controllers, both with their own `loading` flags that are not the same variable.
+I prefer not having to namespace all my loading flags by my controller name or variable or state name, and yet my views simply don’t care.
+To them, doing `ng-show=personLoading` is the same as doing `ng-show=personCtrl.loading` and
+my view becomes more brittle and heavily tied to the controller in use.
+
+**In directives, it’s a completely different ballgame**  
+Because *directives* are entirely about view logic, and should almost never do business logic. Period.
+The old way of doing directives you put all your shit into a linking function.
+A directive controller is essentially identical to a linking function except it is **reusable by other directives**, a visual-widget's externally visible api.
+If you look at [ui-select](https://github.com/angular-ui/ui-select) i love `controllerAs` because I can give it methods like `uiSelectCtrl.open()`
+and that really is what it’s doing. It’s the controls for my `ui-select` widget.  
+`personCtrl.person.open()` just doesn’t make sense if you read it. The ‘controller’ (guy doing shit to people) isn’t the one with the method, the object itself has methods that work upon itself.
+Doing `personCtrl.open()` is just a sign of bad design, because controllers should be skinny.