@@ -53,7 +53,7 @@ We will keep this in mind though, as we add more features.
53
53
54
54
So, now that we learned we should put everything in its own file, our `app/` directory will soon be
55
55
full with dozens of files and specs (remember we keep our unit test files next to the corresponding
56
- source code files). What's more important, logically related files will not be groupped together; it
56
+ source code files). What's more important, logically related files will not be grouped together; it
57
57
will be really difficult of locate all files related to a specific section of the application and
58
58
make a change or fix a bug.
59
59
@@ -66,8 +66,8 @@ parts of the application. We will put those inside `app/core/`.
66
66
67
67
<div class="alert alert-info">
68
68
<p>
69
- Other typical names for our `core` directory are `common` and `components`. The latter is kind
70
- of misleading though, as it will contain other things than components as well.
69
+ Other typical names for our `core` directory are `shared`, ` common` and `components`. The last
70
+ one is kind of misleading though, as it will contain other things than components as well.
71
71
</p>
72
72
<p>
73
73
(This is mostly a relic of the past, when "components" just meant the generic building blocks of
@@ -90,7 +90,7 @@ Based on what we have discussed so far, here is our directory/file layout for th
90
90
## Using Modules
91
91
92
92
As previously mentioned, one of the benefits of having a modular architecture is code reuse —
93
- not only inside the same application, but across application too. There is one final step in making
93
+ not only inside the same application, but across applications too. There is one final step in making
94
94
this code reuse frictionless:
95
95
96
96
* Each feature/section should declare its own module and all related entities should register
@@ -175,11 +175,16 @@ will make all entities registered on `phoneList` available on `phonecatApp` as w
175
175
we have created. This might seem tedious, but is totally worth it.
176
176
</p>
177
177
<p>
178
- In a production-ready application, you are better off concatenating and minifying all your
179
- JavaScript files anyway (for performance reasons), so this won't be an issue any more.
178
+ In a production-ready application, you would concatenate and minify all your JavaScript files
179
+ anyway (for performance reasons), so this won't be an issue any more.
180
180
</p>
181
181
</div>
182
182
183
+ <div class="alert alert-warning">
184
+ Note that files defining a module (i.e. `.module.js`) need to be included before other files that
185
+ add features (e.g. components, controllers, services, filters) to that module.
186
+ </div>
187
+
183
188
184
189
## External Templates
185
190
@@ -193,7 +198,7 @@ IDE/editor has to offer (e.g. HTML-specific color-highlighting and auto-completi
193
198
our component definitions cleaner.
194
199
195
200
So, while it's perfectly fine to keep our component templates inline (using the `template` property
196
- of the CDO), we decided to use an external template for our `phoneList` component. In order to
201
+ of the CDO), we are going to use an external template for our `phoneList` component. In order to
197
202
denote that we are using an external template, we use the `templateUrl` property and specify the URL
198
203
that our template will be loaded from. Since we want to keep our template close to where the
199
204
component is defined, we place it inside `app/phone-list/`.
@@ -242,7 +247,7 @@ HTTP request to get the template from `app/phone-list/phone-list.template.html`.
242
247
243
248
## Final Directory/File Layout
244
249
245
- After all the refactorings that took place, this is how our application looks like from the outside:
250
+ After all the refactorings that took place, this is how our application looks from the outside:
246
251
247
252
<br />
248
253
**`/`:**
@@ -289,10 +294,10 @@ If not already done so, run the tests (using the `npm test` command) and verify
289
294
pass.
290
295
291
296
<div class="alert alert-success">
292
- One of the great things about tests is the confidence the provide, when refactoring your
297
+ One of the great things about tests is the confidence they provide, when refactoring your
293
298
application. It's easy to break something as you start moving files around and re-arranging
294
- modules. Having a good test coverage is the quickest, easiest and most reliable way of knowing
295
- that your application will continue to work as expected.
299
+ modules. Having good test coverage is the quickest, easiest and most reliable way of knowing that
300
+ your application will continue to work as expected.
296
301
</div>
297
302
298
303
0 commit comments