Skip to content
This repository was archived by the owner on Sep 8, 2020. It is now read-only.

Commit 586ed6c

Browse files
committed
Update README.md
1 parent a61795c commit 586ed6c

File tree

1 file changed

+3
-0
lines changed

1 file changed

+3
-0
lines changed

README.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,9 @@ The StyleGuide
2121
#### Don't focus on `src`, `css`, `view`, `controller`, `directives`
2222
In today's code, it's sensible keep modules together and small. HTML, JS and CSS are closely tied together, so we should organize projects that way.
2323

24+
#### Don't use `controllerAs: 'vm'`
25+
This is a practice that is becoming predominant and actually screws up a lot of the benefits of `controllerAs` syntax. Instead of namespacing and bundling controller logic, the only benefit you gain is the little `.` dot notation in `ng-model`. The name `vm` does not tell you where the logic came from or what it has to do with, and does not allow you to work with multiple bundles of logic at the same time. As such, it should be completely avoided.
26+
2427
#### If you can't open-source your directives, they probably shouldn't exist
2528
A lot of people will create what I refer to as 'one-off' directives. They should usually just be sub-states.
2629
If you create directives that are specific to your app's business logic, and aren't focused on purely UI visual implementation (regardless of data, application, etc) then you are too tightly coupling your business logic to your view. You are making it more difficult to quickly refactor your view or view structure. You have to track down where business logic is being executed or modified in multiple places. You start keeping track of data state and lifecycle and implementing things like events and streams because your view lifecycle isn't consistent with your data lifecycle.

0 commit comments

Comments
 (0)