Added all requested links and changes. (#168)

* Added all requested links and changes.

* Updated urls to use relative paths.

Author: Rockin4Life33

src/markdown/tutorial/part-1/07-reusable-components.md

@@ -114,7 +114,7 @@ Let's start with our JavaScript file:
  }
 ```
 
-Here, we import the access token from the config file and return it from a `token` *[getter][TODO: link to getter]*. This allows us to access our token as `this.token` both inside the `MapComponent` class body, as well as the component's template. It is also important to [URL-encode][TODO: link to URL-encode] the token, just in case it contains any special characters that are not URL-safe.
+Here, we import the access token from the config file and return it from a `token` *[getter](https://javascript.info/property-accessors)*. This allows us to access our token as `this.token` both inside the `MapComponent` class body, as well as the component's template. It is also important to [URL-encode](https://javascript.info/url#encoding-strings) the token, just in case it contains any special characters that are not URL-safe.
 
 ## Interpolating Values in Templates
 
@@ -138,7 +138,7 @@ First, we have a container element for styling purposes.
 
 Then we have an `<img>` tag to request and render the static map image from Mapbox.
 
-Our template contains several values that don't yet exist&mdash;`@lat`, `@lng`, `@zoom`, `@width`, and `@height`. These are *[arguments][TODO: link to arguments]* to the `<Map>` component that we will supply when invoking it.
+Our template contains several values that don't yet exist&mdash;`@lat`, `@lng`, `@zoom`, `@width`, and `@height`. These are *[arguments](../../../components/component-arguments-and-html-attributes/#toc_arguments)* to the `<Map>` component that we will supply when invoking it.
 
 By *[parameterizing][TODO: link to parameterizing]* our component using arguments, we made a reusable component that can be invoked from different parts of the app and customized to meet the needs for those specific contexts. We have already seen this in action when using the `<LinkTo>` component [earlier](../building-pages/); we had to specify a `@route` argument so that it knew what page to navigate to.
 
@@ -156,7 +156,7 @@ The `src` attribute interpolates all the required parameters into the URL format
 
 Finally, since we are using the `@2x` "retina" image, we should specify the `width` and `height` attributes. Otherwise, the `<img>` will be rendered at twice the size than what we expected!
 
-We just added a lot of behavior into a single component, so let's write some tests! In particular, we should make sure to have some *[test coverage][TODO: link to test coverage]* for the overriding-HTML-attributes behavior we discussed above.
+We just added a lot of behavior into a single component, so let's write some tests! In particular, we should make sure to have some *[test coverage](../../../testing/)* for the overriding-HTML-attributes behavior we discussed above.
 
 ```run:file:patch lang=js cwd=super-rentals filename=tests/integration/components/map-test.js
 @@ -2,4 +2,5 @@
@@ -238,7 +238,7 @@ We just added a lot of behavior into a single component, so let's write some tes
    });
 ```
 
-Note that the `hasAttribute` test helper from [`qunit-dom`][TODO: link to qunit-dom] supports using *[regular expressions][TODO: link to regular expressions]*. We used this feature to confirm that the `src` attribute starts with `https://api.mapbox.com/`, as opposed to requiring it to be an exact match against a string. This allows us to be reasonably confident that the code is working correctly, without being overly-detailed in our tests.
+Note that the `hasAttribute` test helper from [`qunit-dom`](https://github.com/simplabs/qunit-dom/blob/master/API.md) supports using *[regular expressions](https://javascript.info/regexp-introduction)*. We used this feature to confirm that the `src` attribute starts with `https://api.mapbox.com/`, as opposed to requiring it to be an exact match against a string. This allows us to be reasonably confident that the code is working correctly, without being overly-detailed in our tests.
 
 *Fingers crossed...* Let's run our tests.
 
@@ -356,7 +356,7 @@ Note that we did not mark our getter as `@tracked`. Unlike instance variables, g
 
 That being said, the values *produced* by getters can certainly change. In our case, the value produced by our `src` getter depends on the values of `lat`, `lng`, `width`, `height` and `zoom` from `this.args`. Whenever these *[dependencies][TODO: link to dependencies]* get updated, we would expect `{{this.src}}` from our template to be updated accordingly.
 
-Ember does this by automatically tracking any variables that were accessed while computing a getter's value. As long as the dependencies themselves are marked as `@tracked`, Ember knows exactly when to invalidate and re-render any templates that may potentially contain any "stale" and outdated getter values. This feature is also known as *[auto-track][TODO: link to auto-track]*. All arguments that can be accessed from `this.args` (in other words, `this.args.*`) are implicitly marked as `@tracked` by the Glimmer component superclass. Since we inherited from that superclass, everything Just Works&trade;.
+Ember does this by automatically tracking any variables that were accessed while computing a getter's value. As long as the dependencies themselves are marked as `@tracked`, Ember knows exactly when to invalidate and re-render any templates that may potentially contain any "stale" and outdated getter values. This feature is also known as *[auto-track](../../../in-depth-topics/autotracking-in-depth/)*. All arguments that can be accessed from `this.args` (in other words, `this.args.*`) are implicitly marked as `@tracked` by the Glimmer component superclass. Since we inherited from that superclass, everything Just Works&trade;.
 
 ## Getting JavaScript Values into the Test Context
 

src/markdown/tutorial/part-1/08-working-with-data.md

@@ -24,7 +24,7 @@ So far, we've been hard-coding everything into our `<Rental>` component. But tha
 
 We want to start working towards a place where we can eventually fetch data from the server, and then render the requested data as dynamic content from the templates. In order to do that, we will need a place where we can write the code for fetching data and loading it into the routes.
 
-In Ember, *[route files][TODO: link to route files]* are the place to do that. We haven't needed them yet, because all our routes are essentially just rendering static pages up until this point, but we are about to change that.
+In Ember, *[route files](../../../routing/defining-your-routes/)* are the place to do that. We haven't needed them yet, because all our routes are essentially just rendering static pages up until this point, but we are about to change that.
 
 Let's start by creating a route file for the index route. We will create a new file at `app/routes/index.js` with the following content:
 
@@ -51,19 +51,19 @@ export default class IndexRoute extends Route {
 }
 ```
 
-There's a lot happening here that we haven't seen before, so let's walk through this. First, we're importing the *[`Route` class][TODO: link to Route class]* into the file. This class is used as a starting point for adding functionality to a route, such as loading data.
+There's a lot happening here that we haven't seen before, so let's walk through this. First, we're importing the *[`Route` class](https://api.emberjs.com/ember/release/classes/Route)* into the file. This class is used as a starting point for adding functionality to a route, such as loading data.
 
-Then, we are extending the `Route` class into our *own* `IndexRoute`, which we also *[`export`][TODO: link to export]* so that the rest of the application can use it.
+Then, we are extending the `Route` class into our *own* `IndexRoute`, which we also *[`export`](https://javascript.info/import-export#export-default)* so that the rest of the application can use it.
 
 ## Returning Local Data from the Model Hook
 
-So far, so good. But what's happening inside of this route class? We implemented an *[async method][TODO: link to async method]* called `model()`. This method is also known as the *[model hook][TODO: link to model hook]*.
+So far, so good. But what's happening inside of this route class? We implemented an *[async](https://developer.mozilla.org/docs/Learn/JavaScript/Asynchronous/Concepts)* method called `model()`. This method is also known as the *[model hook][TODO: link to model hook]*.
 
-The model hook is responsible for fetching and preparing any data that you need for your route. Ember will automatically call this hook when entering a route, so that you can have an opportunity to run your own code to get the data you need. The object returned from this hook is known as the *[model][TODO: link to model]* for the route (surprise!).
+The model hook is responsible for fetching and preparing any data that you need for your route. Ember will automatically call this hook when entering a route, so that you can have an opportunity to run your own code to get the data you need. The object returned from this hook is known as the *[model](../../../routing/specifying-a-routes-model/)* for the route (surprise!).
 
 Usually, this is where we'd fetch data from a server. Since fetching data is usually an asynchronous operation, the model hook is marked as `async`. This gives us the option of using the `await` keyword to wait for the data fetching operations to finish.
 
-We'll get to that bit later on. At the moment, we are just returning the same hard-coding model data, extracted from the `<Rental>` component, but in a JavaScript object (also known as *[POJO][TODO: link to POJO]*) format.
+We'll get to that bit later on. At the moment, we are just returning the same hard-coding model data, extracted from the `<Rental>` component, but in a *[JavaScript object](https://developer.mozilla.org/docs/Learn/JavaScript/Objects/Basics)* format.
 
 ## Accessing Route Models from Templates
 
@@ -284,7 +284,7 @@ First off, we're using the browser's *[Fetch API](https://developer.mozilla.org/
 
 As mentioned above, fetching data from the server is usually an asynchronous operation. The Fetch API takes this into account, which is why `fetch` is an `async` function, just like our model hook. To consume its response, we will have to pair it with the `await` keyword.
 
-The Fetch API returns a *[response object][TODO: link to response object]* asynchronously. Once we have this object, we can convert the server's response into whatever format we need; in our case, we knew the server sent the data using the JSON format, so we can use the `json()` method to *[parse][TODO: link to parse]* the response data accordingly. Parsing the response data is *also* an asynchronous operation, so we'll just use the `await` keyword here, too.
+The Fetch API returns a *[response object](https://developer.mozilla.org/docs/Web/API/Response)* asynchronously. Once we have this object, we can convert the server's response into whatever format we need; in our case, we knew the server sent the data using the JSON format, so we can use the `json()` method to *[parse](https://developer.mozilla.org/docs/Web/API/Body/json)* the response data accordingly. Parsing the response data is *also* an asynchronous operation, so we'll just use the `await` keyword here, too.
 
 ```run:command hidden=true cwd=super-rentals
 git add app/routes/index.js
@@ -297,7 +297,7 @@ Before we go any further, let's pause for a second to look at the server's data
 ```run:file:show lang=json cwd=super-rentals filename=public/api/rentals.json
 ```
 
-This data follows the *[JSON:API][TODO: link to JSON:API]* format, which is *slightly* different than the hard-coded data that we were returning from the model hook before.
+This data follows the *[JSON:API](https://jsonapi.org/)* format, which is *slightly* different than the hard-coded data that we were returning from the model hook before.
 
 First off, the JSON:API format returns an array nested under the `"data"` key, rather than just the data for a single rental property. If we think about this, though, it makes sense; we now want to show a whole list of rental properties that are coming from our server, not just one, so an array of rental property objects is just what we need.
 

src/markdown/tutorial/part-2/09-route-params.md

@@ -28,7 +28,7 @@ But first things first: we need to add a route for this new page. We can do that
  });
 ```
 
-Notice that we are doing something a little different here. Instead of using the default path (`/rental`), we're specifying a custom path. Not only are we using a custom path, but we're also passing in a `:rental_id`, which is what we call a *[dynamic segment][TODO: link to dynamic segment]*. When these routes are evaluated, the `rental_id` will be substituted with the `id` of the individual rental property that we are trying to navigate to.
+Notice that we are doing something a little different here. Instead of using the default path (`/rental`), we're specifying a custom path. Not only are we using a custom path, but we're also passing in a `:rental_id`, which is what we call a *[dynamic segment](../../../routing/defining-your-routes/#toc_dynamic-segments)*. When these routes are evaluated, the `rental_id` will be substituted with the `id` of the individual rental property that we are trying to navigate to.
 
 ```run:command hidden=true cwd=super-rentals
 git add app/router.js