You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+14-9
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,3 @@
1
-
[Please click here to support the Standing Rock Sioux Tribe and their peaceful resistance to the Dakota Access Pipeline which threatens their only source of water.](http://www.powwows.com/2016/09/07/10-ways-can-help-standing-rock-sioux-fight-dakota-access-pipeline/)
1. Code examples are better than docs, lessons and Gitter Q&A.
16
+
1. Real, complete code examples are better than docs, lessons and Gitter Q&A. And MUCH better
17
+
than ellipses (...).
19
18
2. If you want a job making commercial-grade code, you should study commercial-grade code,
20
19
not tutorial-grade code. Anything you learn in a tutorial must sadly be approached with caution
21
20
because corners have probably been cut, it's probably been simplified and it probably doesn't
@@ -26,6 +25,8 @@ The rationale behind this is pretty simple...
26
25
you even write Hello World.
27
26
4. If you want to know the complexity limits a technology will place on your app before you
28
27
commit to using it, there's no better way than to see a complex example made with that technology.
28
+
5. Making architectural decisions or convention decisions is a whole lot easier when you have
29
+
a complete application with all of its edge cases to illuminate the consequences.
29
30
30
31
Hopefully, when the project is done it will make the learning process for others much easier and prepare them to
31
32
make real things rather than instructional ones. I expect it to reduce the time to implement your own real
@@ -41,7 +42,7 @@ according to the following prioritization. Disagreements in approach between two
41
42
lower influence yielding to the higher one:
42
43
43
44
1.[Angular Style Guide](https://angular.io/docs/ts/latest/guide/style-guide.html) by Google
44
-
2.[Tour of Heroes (ngModules, Routing, App Specs versions)](https://github.com/dancancro/tour-of-heroes-versions) by Google
45
+
2.[Tour of Heroes (ngModules, Routing, App Specs, HTTP, Server Communication versions)](https://github.com/dancancro/tour-of-heroes-versions) by Google
45
46
3.[Angular CLI](https://github.com/angular/angular-cli) by Google and the community
46
47
4.[ngrx example app - book collection](https://github.com/ngrx/example-app) by [@MikeRyan52](https://github.com/MikeRyan52)
47
48
5.[angular-seed-advanced](https://github.com/NathanWalker/angular-seed-advanced) by Minko Gechev + Nathan Walker + community
@@ -64,14 +65,17 @@ While the goal of the project is to combine the wisdom of different experts, nob
64
65
no obvious case against doing so. So you will see a couple of practices in this project that came from my head rather than the sources
65
66
of expertise from which the project was assembled. If you can think of reasons not to do these things, please let me know.
66
67
67
-
1. I have put the Redux store reducers in `app/core/store` separate from the feature directories located under `app`. This agrees with
68
-
the traditional relational database structure that has tables together in one place and referenced by UI artifacts in another place. This is the
69
-
recommended practice with Redux.
68
+
1. I have put the Redux store reducers in `app/core/store` separate from the feature directories located under `app` and did not make folders
69
+
for `reducers`, `actions`, and `effects`. This jibes with the traditional relational database structure that has tables together in one place
70
+
and referenced by UI artifacts in another place. This is the recommended practice with Redux.
70
71
2. As much as practical the names of files in a directory begin with the directory name. I did this to prevent directories from having a mixture of
71
72
unrelated concerns. If a directory in a source demo had files for two different things, I created more directories. I thought about
72
73
removing that part of the file name, `src/app/app.page.ts` -> `src/app/page.ts`, for the sake of DRY, and I might still do that, but I'm
73
74
undecided on whether it would cause confusion to see many files in an editor with the same name.
74
-
3. I came up with a mini lexicon of file types to keep file names shorter and more expressive. A "page" is understood to be a smart `@Component`
75
+
3. I noticed a lot of duplication and boilerplate of identical CRUD code for each of my types of entities. So I made an `entities` folder akin to
76
+
the other parts of the store to hold what was common to all of them. `entity.action.ts` has the common actions. `entity.effects.ts` has some utility
77
+
functions for the common CRUD effects that are called from minimal specific entities. `entity.model.ts` contains the common schema and reducer code.
78
+
4. I came up with a mini lexicon of file types to keep file names shorter and more expressive. A "page" is understood to be a smart `@Component`
75
79
class that fills the page and might have a router-outlet and route configurations. A "guard" is understood to be an `@Injectable` "service" class that
76
80
returns a boolean. A "routing" is a `@NgModule` class that contains route configurations. So I memorize this simple lexicon, and drop the
77
81
redundant, less-clear words from the names. For example, I use the name `app.page.ts` rather than `app.component.ts` or `app-page.component.ts`.
@@ -93,6 +97,7 @@ That's it. It shouldn't be too hard to remember these, and in return you will ha
93
97
| Issue | Description | Features |
94
98
| :-- | :-- | :-- |
95
99
|[14480](https://github.com/angular/angular/issues/14480)| Angular 2 relative pathing from siblings doesn't work | Compose Message box on Crisis Center and login success routing |
0 commit comments