Merge pull request #2174 from ember-learn/super-rentals-tutorial

Tutorial Updates

Author: mansona

guides/release/tutorial/part-1/orientation.md

@@ -24,8 +24,8 @@ To verify that your installation was successful, run:
 
 ```shell
 $ ember --version
-ember-cli: 6.8.0
-node: 18.20.8
+ember-cli: 6.9.1
+node: 20.19.6
 os: linux x64
 ```
 
@@ -61,6 +61,7 @@ Creating a new Ember app in /home/runner/work/super-rentals-tutorial/super-renta
   create app/models/.gitkeep
   create app/router.js
   create app/routes/.gitkeep
+  create app/services/.gitkeep
   create app/styles/app.css
   create /home/runner/work/super-rentals-tutorial/super-rentals-tutorial/dist/code/super-rentals/app/templates/application.gjs
   create config/ember-cli-update.json
@@ -122,6 +123,8 @@ super-rentals
 │   │   └── .gitkeep
 │   ├── routes
 │   │   └── .gitkeep
+│   ├── services
+│   │   └── .gitkeep
 │   ├── styles
 │   │   └── app.css
 │   ├── templates
@@ -165,7 +168,7 @@ super-rentals
 ├── testem.cjs
 └── vite.config.mjs
 
-27 directories, 56 files
+28 directories, 58 files
 ```
 
 We'll learn about the purposes of these files and folders as we go. For now, just know that we'll spend most of our time working within the `app` folder.
@@ -189,13 +192,14 @@ building...
 
 Build successful (9761ms)
 
+
 Slowest Nodes (totalTime >= 5%) | Total (avg)
 -+-
-Babel: @embroider/macros (1) | 436ms
+Babel: @embroider/macros (1) | 389ms
 
 
 
-  VITE v6.3.6  ready in 4143 ms
+  VITE v7.3.0  ready in 3754 ms
 
   ➜  Local:   http://localhost:4200/
 ```

guides/release/tutorial/part-1/reusable-components.md

@@ -99,13 +99,14 @@ building...
 
 Build successful (13286ms)
 
+
 Slowest Nodes (totalTime >= 5%) | Total (avg)
 -+-
-Babel: @embroider/macros (1) | 423ms
+Babel: @embroider/macros (1) | 389ms
 
 
 
-  VITE v6.3.6  ready in 4119 ms
+  VITE v7.3.0  ready in 3756 ms
 
   ➜  Local:   http://localhost:4200/
 ```

guides/release/tutorial/part-1/working-with-data.md

@@ -418,7 +418,7 @@ Awesome! Now we're in business.
 
 ## Loops and Local Variables in Templates with `{{#each}}`
 
-The last change we'll need to make is to our `index.hbs` route template, where we invoke our `<Rental>` components. Previously, we were passing in `@rental` as `@model` to our components. However, `@model` is no longer a single object, but rather, an array! So, we'll need to change this template to account for that.
+The last change we'll need to make is to our `index.gjs` route template, where we invoke our `<Rental>` components. Previously, we were passing in `@rental` as `@model` to our components. However, `@model` is no longer a single object, but rather, an array! So, we'll need to change this template to account for that.
 
 Let's see how.
 

guides/release/tutorial/part-2/ember-data.md

@@ -334,18 +334,14 @@ Let's start customizing the things that didn't work for us by default. Specifica
 
 The first thing we want to do is have our builder respect a configurable default host and/or namespace. Adding a namespace prefix happens to be pretty common across Ember apps, so EmberData provides a global config mechanism for host and namespace. Typically you will want to do this either in your store file or app file.
 
-```js { data-filename="app/app.js" data-diff="+7,+8,+9,+10,+11" }
+```js { data-filename="app/app.js" data-diff="+21,+22,+23,+24,+25" }
 import Application from '@ember/application';
 import compatModules from '@embroider/virtual/compat-modules';
 import Resolver from 'ember-resolver';
 import loadInitializers from 'ember-load-initializers';
 import config from 'super-rentals/config/environment';
 import { importSync, isDevelopingApp, macroCondition } from '@embroider/macros';
-import { setBuildURLConfig } from '@ember-data/request-utils';
-
-setBuildURLConfig({
-  namespace: 'api',
-});
+import setupInspector from '@embroider/legacy-inspector-support/ember-source-4.12';
 
 if (macroCondition(isDevelopingApp())) {
   importSync('./deprecation-workflow');
@@ -355,9 +351,15 @@ export default class App extends Application {
   modulePrefix = config.modulePrefix;
   podModulePrefix = config.podModulePrefix;
   Resolver = Resolver.withModules(compatModules);
+  inspector = setupInspector(this);
 }
 
 loadInitializers(App, config.modulePrefix, compatModules);
+import { setBuildURLConfig } from '@ember-data/request-utils';
+
+setBuildURLConfig({
+  namespace: 'api',
+});
 ```
 
 Adding the `.json` extension is a bit less common, and doesn't have a declarative configuration API of its own. We could just modify request options directly in place of use, but that would be a bit messy. Instead, let's create a handler to do this for us.

guides/release/tutorial/part-2/provider-components.md

@@ -1,6 +1,6 @@
 <!-- Heads up! This is a generated file, do not edit directly. You can find the source at https://github.com/ember-learn/super-rentals-tutorial/blob/master/src/markdown/tutorial/part-2/12-provider-components.md -->
 
-In this chapter, we'll work on adding a new search feature, and refactor our `index.hbs` template into a new component along the way. We'll learn about a new pattern for passing data around between components, too! Once we're done, our page will look like this:
+In this chapter, we'll work on adding a new search feature, and refactor our `index.gjs` template into a new component along the way. We'll learn about a new pattern for passing data around between components, too! Once we're done, our page will look like this:
 
 <!-- TODO: make this a gif instead -->
 
@@ -58,7 +58,7 @@ Awesome, one step done. Now, this input looks great, but it doesn't actually _do
 
 In order to make our search box actually work, we are going to need to retain and store the text that the user types in when they use the search box. This text is the search query, and it is a piece of _[state](../../../components/component-state-and-actions/)_ that is going to change whenever the user types something into the search box.
 
-But where are we going to put this newly-introduced piece of state? In order to wire up the search box, we need a place to store the search query. At the moment, our search box lives on the `index.hbs` route template, which doesn't have a good place to store this search query state. Darn, this would be so much easier to do if we had a component, because we could just store the state directly on the component!
+But where are we going to put this newly-introduced piece of state? In order to wire up the search box, we need a place to store the search query. At the moment, our search box lives on the `index.gjs` route template, which doesn't have a good place to store this search query state. Darn, this would be so much easier to do if we had a component, because we could just store the state directly on the component!
 
 Wait...why don't we just refactor the search box into a component? Once we do that, this will all be a bit easier—hooray!