Merge pull request #12 from FullStacksDev/doc-updates

Doc updates

Author: jits

docs/2.routes-and-shell.md

@@ -6,7 +6,7 @@
 
 The base template comes with a `website` feature folder (within the `app`) where the static pages live. We could've added more pages and components here to build our logbook app, but it's better to separate it out into a dedicated feature folder ([`app/src/app/logbook/`](../app/src/app/logbook/)) and lazily load it only when the user navigates to a particular URL — `/logbook` in this case — as registered in the top-level app routes file:
 
-<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/7573043239af19257b40c3c2b19c6b5bc98d3b27/app/src/app/app.routes.ts#L9-L12>
+<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/f283f8f73e5d318c08d85e226a85a56f9df03d8e/app/src/app/app.routes.ts#L8-L11>
 
 Here, the use of an `import` for the `loadChildren` property tells Angular to separate out the code for the logbook feature into its own bundle and only load it when the user navigates to `/logbook`.
 
@@ -16,7 +16,7 @@ Here, the use of an `import` for the `loadChildren` property tells Angular to se
 
 Let's now look at the routes for the logbook feature itself:
 
-<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/7573043239af19257b40c3c2b19c6b5bc98d3b27/app/src/app/logbook/logbook.routes.ts#L9-L25>
+<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/f283f8f73e5d318c08d85e226a85a56f9df03d8e/app/src/app/logbook/logbook.routes.ts#L9-L25>
 
 - We define a parent route that will load the `LogbookShellComponent`, with child routes defined within.
   - This shell component has a `<router-outlet>` in its template where a matching child route will have it's component placed in to.

docs/3.data-model-and-access.md

@@ -64,7 +64,7 @@ erDiagram
 
 Given the design decision to store all entries in a single collection, we first set up the security rules to ensure proper access control:
 
-<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/7573043239af19257b40c3c2b19c6b5bc98d3b27/firebase/firestore.rules#L4-L19>
+<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/f283f8f73e5d318c08d85e226a85a56f9df03d8e/firebase/firestore.rules#L4-L19>
 
 - This is a special "domain specific language" (DSL) that Firestore uses to define access control rules in the [`firebase/firestore.rules`](../firebase/firestore.rules) file ([docs](https://firebase.google.com/docs/firestore/security/get-started)).
 - `isAuthed()` and `matchesAuthedUser(userId)` are helper functions we've defined to allow easy reuse in multiple rules.
@@ -104,11 +104,11 @@ Both Angular and the Firebase JavaScript SDK have first class support for TypeSc
 
 When loading entries from Firestore we want to assume they take a particular _shape_ — the `EntryDoc` type — which the TypeScript (and VS Code) tooling can then use to look for type errors and provide code completion.
 
-<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/7573043239af19257b40c3c2b19c6b5bc98d3b27/app/src/app/shared/models.ts#L15-L23>
+<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/f283f8f73e5d318c08d85e226a85a56f9df03d8e/app/src/app/shared/models.ts#L15-L23>
 
 - This uses the `Readonly` TypeScript utility type to mark the whole object as readonly.
 - We build on the `WithId` type from the [`firebase/common/models.ts`](../firebase/common/models.ts) file, which adds the `id` field to the object.
-  - We're using TypeScript's intersection type (`&`) to combine the `WithId` type with the rest of the fields, to make up the `EntryDoc` type.
+  - We're using TypeScript's intersection operator (`&`) to combine the `WithId` type with the rest of the fields, to make up the `EntryDoc` type.
   - We'll see below how this `id` field is populated.
 - The rest of the fields conform directly to the data model defined earlier.
 
@@ -122,7 +122,7 @@ When loading entries from Firestore we want to assume they take a particular _sh
 
 In the same file we also define a special `NewOrUpdatedEntryInput` type for the data we send to Firestore when creating or updating an entry:
 
-<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/7573043239af19257b40c3c2b19c6b5bc98d3b27/app/src/app/shared/models.ts#L25>
+<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/f283f8f73e5d318c08d85e226a85a56f9df03d8e/app/src/app/shared/models.ts#L25>
 
 Here we're picking a subset of the fields from the `EntryDoc` type — we only want to allow the user to set or update these fields.
 
@@ -150,11 +150,11 @@ Let's walk through this service:
 
 First, we inject the Firestore client using the helper provided from the base template:
 
-<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/7573043239af19257b40c3c2b19c6b5bc98d3b27/app/src/app/logbook/data/db/entries.service.ts#L29>
+<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/f283f8f73e5d318c08d85e226a85a56f9df03d8e/app/src/app/logbook/data/db/entries.service.ts#L29>
 
 Next, we define a special converter object that the Firestore JavaScript library understands. We also define a reference to the collection (which we use in the actual data access methods):
 
-<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/7573043239af19257b40c3c2b19c6b5bc98d3b27/app/src/app/logbook/data/db/entries.service.ts#L31-L51>
+<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/f283f8f73e5d318c08d85e226a85a56f9df03d8e/app/src/app/logbook/data/db/entries.service.ts#L31-L51>
 
 [Firestore converters](https://firebase.google.com/docs/firestore/query-data/get-data#custom_objects) are a first class way to convert Firestore document data into strongly typed objects, and back. A converter is an object that conforms to the `FirestoreDataConverter` type, which requires two methods:
 
@@ -299,13 +299,13 @@ Because Realtime Database doesn't natively support arrays we have to model the c
 
 We then have some very basic security rules to allow anyone to read but no one to write (from the client-side):
 
-<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/7573043239af19257b40c3c2b19c6b5bc98d3b27/firebase/database.rules.json#L1-L8>
+<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/f283f8f73e5d318c08d85e226a85a56f9df03d8e/firebase/database.rules.json#L1-L8>
 
 We add some tests in [`firebase/test/rtdb/rtdb-rules.spec.ts`](../firebase/test/rtdb/rtdb-rules.spec.ts) to ensure that these work as expected.
 
 Finally, we have a service that wraps access to this config object (and thus the underlying categories): [`ConfigService`](../app/src/app/logbook/data/db/config.service.ts). The key line in this service is where we flatten the `categories` object into an array of strings:
 
-<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/7573043239af19257b40c3c2b19c6b5bc98d3b27/app/src/app/logbook/data/db/config.service.ts#L23-L25>
+<https://github.com/FullStacksDev/angular-and-firebase-simple-example-app/blob/f283f8f73e5d318c08d85e226a85a56f9df03d8e/app/src/app/logbook/data/db/config.service.ts#L29-L32>
 
 Next we look at how we build on top of these data access services to drive state management and app logic using stores.