diff --git a/guides/release/in-depth-topics/autotracking-in-depth.md b/guides/release/in-depth-topics/autotracking-in-depth.md
index 0ff6f514ce..322fe78141 100644
--- a/guides/release/in-depth-topics/autotracking-in-depth.md
+++ b/guides/release/in-depth-topics/autotracking-in-depth.md
@@ -9,11 +9,7 @@ When Ember first renders a component, it renders the initial _state_ of that
 component - the state of the instance, and state of the arguments that are
 passed to it:
 
-```handlebars {data-filename=app/components/hello.hbs}
-{{this.greeting}}, {{@name}}!
-```
-
-```js {data-filename=app/components/hello.js}
+```gjs {data-filename=app/components/hello.gjs}
 import Component from '@glimmer/component';
 
 export default class HelloComponent extends Component {
@@ -29,11 +25,19 @@ export default class HelloComponent extends Component {
         return 'Hola';
     }
   }
+
+  <template>
+    {{this.greeting}}, {{@name}}!
+  </template>
 }
 ```
 
-```handlebars {data-filename=app/templates/application.hbs}
-<Hello @name="Jen Weber">
+```gjs {data-filename=app/templates/application.gjs}
+import 'my-app/components/hello';
+
+<template>
+  <Hello @name="Jen Weber">
+</template>
 ```
 
 When Ember renders this template, we get:
@@ -59,11 +63,12 @@ Trackable values are values that:
 
 We can do this by marking the field with the `@tracked` decorator:
 
-```js {data-filename=app/components/hello.js}
+```gjs {data-filename=app/components/hello.gjs data-diff="+2,-5,+6"}
 import Component from '@glimmer/component';
 import { tracked } from '@glimmer/tracking';
 
 export default class HelloComponent extends Component {
+  language = 'en';
   @tracked language = 'en';
 
   get greeting() {
@@ -76,6 +81,10 @@ export default class HelloComponent extends Component {
         return 'Hola';
     }
   }
+
+  <template>
+    {{this.greeting}}, {{@name}}!
+  </template>
 }
 ```
 
@@ -95,20 +104,10 @@ Tracked properties can be updated like any other property, using standard
 JavaScript syntax. For instance, we could update a tracked property via an
 action, as in this example component.
 
-```handlebars {data-filename=app/components/hello.hbs}
-{{this.greeting}}, {{@name}}!
-
-<select {{on "change" this.updateLanguage}}>
-  <option value="en">English</option>
-  <option value="de">German</option>
-  <option value="sp">Spanish</option>
-</select>
-```
-
-```js {data-filename=app/components/hello.js}
+``` gjs { data-filename=app/components/hello.gjs data-diff="+3,+18,+19,+20,+21,+25,+26,+27,+28,+29,+30" }
 import Component from '@glimmer/component';
 import { tracked } from '@glimmer/tracking';
-import { action } from '@ember/object';
+import { on } from '@ember/modifier';
 
 export default class HelloComponent extends Component {
   @tracked language = 'en';
@@ -124,10 +123,19 @@ export default class HelloComponent extends Component {
     }
   }
 
-  @action
-  updateLanguage(event) {
+  updateLanguage = (event) => {
     this.language = event.target.value;
-  }
+  };
+
+  <template>
+    {{this.greeting}}, {{@name}}!
+
+    <select {{on "change" this.updateLanguage}}>
+      <option value="en">English</option>
+      <option value="de">German</option>
+      <option value="sp">Spanish</option>
+    </select>
+  </template>
 }
 ```
 
@@ -140,10 +148,10 @@ Another way that a tracked property could be updated is asynchronously, if
 you're sending a request to the server. For instance, maybe we would want to
 load the user's preferred language:
 
-```js
+``` gjs { data-filename=app/components/hello.gjs data-diff="+6,+7,+8,+9,+10,+11,+12,+13,+14,+15" }
 import Component from '@glimmer/component';
 import { tracked } from '@glimmer/tracking';
-import { action } from '@ember/object';
+import { on } from '@ember/modifier';
 
 export default class HelloComponent extends Component {
   constructor() {
@@ -168,6 +176,20 @@ export default class HelloComponent extends Component {
         return 'Hola';
     }
   }
+
+  updateLanguage = (event) => {
+    this.language = event.target.value;
+  };
+
+  <template>
+    {{this.greeting}}, {{@name}}!
+
+    <select {{on "change" this.updateLanguage}}>
+      <option value="en">English</option>
+      <option value="de">German</option>
+      <option value="sp">Spanish</option>
+    </select>
+  </template>
 }
 ```
 
@@ -180,16 +202,26 @@ app.
 So far we've only shown tracked properties working through getters, but tracking
 works through _methods_ or _functions_ as well:
 
-```js
+``` gjs { data-diff="+17,+18,+19,+20,+21,+24,+25,+26,+27" }
 import Component from '@glimmer/component';
 import { tracked } from '@glimmer/tracking';
-import { action } from '@ember/object';
+import { on } from '@ember/modifier';
 
 export default class HelloComponent extends Component {
+  constructor() {
+    super(...arguments);
+
+    fetch('/api/preferences')
+      .then(r => r.json()) // convert the response to a JS object
+      .then(response => {
+        this.language = response.preferredLanguage;
+      });
+  }
+
   @tracked language = 'en';
   @tracked supportedLanguages = ['en', 'de', 'es'];
 
-  isSupported(language) {
+  isSupported = (language) => {
     return this.supportedLanguages.includes(language);
   }
 
@@ -207,6 +239,20 @@ export default class HelloComponent extends Component {
         return 'Hola';
     }
   }
+
+  updateLanguage = (event) => {
+    this.language = event.target.value;
+  };
+
+  <template>
+    {{this.greeting}}, {{@name}}!
+
+    <select {{on "change" this.updateLanguage}}>
+      <option value="en">English</option>
+      <option value="de">German</option>
+      <option value="sp">Spanish</option>
+    </select>
+  </template>
 }
 ```
 
@@ -237,7 +283,7 @@ export default class Person {
 
 ```js {data-filename=app/routes/application.js}
 import Route from '@ember/routing/route';
-import Person from '../../../../utils/person';
+import Person from 'my-app/utils/person';
 
 export default class ApplicationRoute extends Route {
   model() {
@@ -246,27 +292,27 @@ export default class ApplicationRoute extends Route {
 }
 ```
 
-```js {data-filename=app/controllers/application.js}
-import Controller from '@ember/controller';
-import { action } from '@ember/object';
-
-export default class ApplicationController extends Controller {
-  @action
-  updateName(title, name) {
-    this.model.title = title;
-    this.model.name = name;
-  }
+```gjs {data-filename=app/templates/application.gjs}
+import Component from '@glimmer/component';
+import { on } from '@ember/modifier';
+import { fn } from '@ember/helper';
+
+export default class ApplicationRouteComponent extends Component {
+  updateName = (title, name) => {
+    this.args.model.title = title;
+    this.args.model.name = name;
+  };
+
+  <template>
+    {{@model.fullName}}
+
+    <button type="button" {{on "click" (fn this.updateName 'Prof.' 'Tomster')}}>
+      Update Name
+    </button>
+  </template>
 }
 ```
 
-```handlebars {data-filename=app/templates/application.hbs}
-{{@model.fullName}}
-
-<button type="button" {{on "click" (fn this.updateName 'Prof.' 'Tomster')}}>
-  Update Name
-</button>
-```
-
 As long as the properties are tracked, and accessed when rendering the template
 directly or indirectly, everything should update as expected
 
@@ -362,7 +408,8 @@ you cache (or "memoize") a getter by simply marking it as `@cached`.
 
 With this in mind, let's introduce caching to `aspectRatio`:
 
-```js
+``` js { data-diff="-1,+2,+10,-22,+23,-28,+29" }
+import { tracked } from '@glimmer/tracking';
 import { cached, tracked } from '@glimmer/tracking';
 
 let count = 0;
@@ -383,11 +430,13 @@ let photo = new Photo();
 console.log(photo.aspectRatio); // 1.5
 console.log(count); // 1
 console.log(photo.aspectRatio); // 1.5
+console.log(count); // 2
 console.log(count); // 1
 
 photo.width = 800;
 
 console.log(photo.aspectRatio); // 2
+console.log(count); // 3
 console.log(count); // 2
 ```
 
diff --git a/guides/release/in-depth-topics/patterns-for-actions.md b/guides/release/in-depth-topics/patterns-for-actions.md
index d753a80d61..81976a38d8 100644
--- a/guides/release/in-depth-topics/patterns-for-actions.md
+++ b/guides/release/in-depth-topics/patterns-for-actions.md
@@ -12,27 +12,27 @@ to confirm in order to trigger some action.
 We'll call this the `ButtonWithConfirmation` component. We can start off with a
 normal component definition, like we've seen before:
 
-```handlebars {data-filename=app/components/button-with-confirmation.hbs}
-<button type="button">{{@text}}</button>
-
-{{#if this.isConfirming}}
-  <div class="confirm-dialog">
-    <button type="button" class="confirm-submit">
-      OK
-    </button>
-    <button type="button" class="confirm-cancel">
-      Cancel
-    </button>
-  </div>
-{{/if}}
-```
-
-```js {data-filename=app/components/button-with-confirmation.js}
+```gjs {data-filename=app/components/button-with-confirmation.gjs}
 import Component from '@glimmer/component';
 import { tracked } from '@glimmer/tracking';
 
 export default class ButtonWithConfirmationComponent extends Component {
   @tracked isConfirming = false;
+
+  <template>
+    <button type="button">{{@text}}</button>
+
+    {{#if this.isConfirming}}
+      <div class="confirm-dialog">
+        <button type="button" class="confirm-submit">
+          OK
+        </button>
+        <button type="button" class="confirm-cancel">
+          Cancel
+        </button>
+      </div>
+    {{/if}}
+  </template>
 }
 ```
 
@@ -45,92 +45,113 @@ more about tracked properties in the [Autotracking In-Depth](../autotracking-in-
 guide.
 
 Next, we need to hook up the button to toggle that property. We'll
-do this with an _action_:
+do this with an _action_.
+An action is a function that is bound to the component instance. There are two common ways to bind a function to a component instance.  The first way is to assign an arrow function to a property, like this:
+
+```js
+  // in component
+  myAction = () => {
+    // do something here
+  };
+```
+
+The second way is to import and use the `@action` decorator, like this:
+
+```js
+import { action } from '@ember/object';
+// ...
 
-```js {data-filename=app/components/button-with-confirmation.js}
+  // in component
+  @action
+  myAction() {
+    // do something here
+  }
+```
+
+These two are functionally equivalent and are used interchangeably throughout these guides.
+
+So, to hook up the button to toggle the `isConfirming` property, we'll define a `launchConfirmDialog` action:
+
+```gjs {data-filename=app/components/button-with-confirmation.gjs}
 import Component from '@glimmer/component';
 import { tracked } from '@glimmer/tracking';
-import { action } from '@ember/object';
+import { on } from '@ember/modifier';
 
 export default class ButtonWithConfirmationComponent extends Component {
   @tracked isConfirming = false;
 
-  @action
-  launchConfirmDialog() {
+  launchConfirmDialog = () => {
     this.isConfirming = true;
-  }
-}
-```
-
-```handlebars
-<button type="button" {{on "click" this.launchConfirmDialog}}>
-  {{@text}}
-</button>
+  };
 
-{{#if this.isConfirming}}
-  <div class="confirm-dialog">
-    <button type="button" class="confirm-submit">
-      OK
-    </button>
-    <button type="button" class="confirm-cancel">
-      Cancel
+  <template>
+    <button type="button" {{on "click" this.launchConfirmDialog}}>
+      {{@text}}
     </button>
-  </div>
-{{/if}}
+
+    {{#if this.isConfirming}}
+      <div class="confirm-dialog">
+        <button type="button" class="confirm-submit">
+          OK
+        </button>
+        <button type="button" class="confirm-cancel">
+          Cancel
+        </button>
+      </div>
+    {{/if}}  
+  </template>
+}
 ```
 
 Now if we click the button, it will show the confirmation dialog - our first
 interactive component! We'll also want the modal to close when we click either
 of the modal buttons, so we can add a couple more actions to handle that:
 
-```js {data-filename=app/components/button-with-confirmation.js}
+```gjs {data-filename=app/components/button-with-confirmation.gjs}
 import Component from '@glimmer/component';
 import { tracked } from '@glimmer/tracking';
-import { action } from '@ember/object';
+import { on } from '@ember/modifier';
 
 export default class ButtonWithConfirmationComponent extends Component {
   @tracked isConfirming = false;
 
-  @action
-  launchConfirmDialog() {
+  launchConfirmDialog = () => {
     this.isConfirming = true;
-  }
+  };
 
-  @action
-  submitConfirm() {
+  submitConfirm = () => {
     this.isConfirming = false;
-  }
+  };
 
-  @action
-  cancelConfirm() {
+  cancelConfirm = () => {
     this.isConfirming = false;
-  }
-}
-```
+  };
 
-```handlebars
-<button type="button" {{on "click" this.launchConfirmDialog}}>
-  {{@text}}
-</button>
-
-{{#if this.isConfirming}}
-  <div class="confirm-dialog">
-    <button
-      type="button"
-      class="confirm-submit"
-      {{on "click" this.submitConfirm}}
-    >
-      OK
+  <template>
+    <button type="button" {{on "click" this.launchConfirmDialog}}>
+      {{@text}}
     </button>
-    <button
-      type="submit"
-      class="confirm-cancel"
-      {{on "click" this.cancelConfirm}}
-    >
-      Cancel
-    </button>
-  </div>
-{{/if}}
+
+    {{#if this.isConfirming}}
+      <div class="confirm-dialog">
+        <button
+          type="button"
+          class="confirm-submit"
+          {{on "click" this.submitConfirm}}
+        >
+          OK
+        </button>
+        <button
+          type="submit"
+          class="confirm-cancel"
+          {{on "click" this.cancelConfirm}}
+        >
+          Cancel
+        </button>
+      </div>
+    {{/if}}
+  </template>
+}
 ```
 
 Now we can open and close the modal dialog at will! Next, we'll setup the
@@ -142,10 +163,17 @@ buttons.
 Let's create a parent component, the `UserProfile` component, where the user can
 delete their profile:
 
-```handlebars {data-filename=app/components/user-profile.hbs}
-<ButtonWithConfirmation
-  @text="Click OK to delete your account."
-/>
+```gjs {data-filename=app/components/user-profile.gjs}
+import Component from '@glimmer/component';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
+
+export default class UserProfileComponent extends Component {
+  <template>
+    <ButtonWithConfirmation
+      @text="Click OK to delete your account."
+    />
+  </template>
+}
 ```
 
 First we'll define what we want to happen when the user clicks the button and
@@ -157,18 +185,23 @@ We'll implement an action on the parent component called
 method. We'll go over services later on - for now, think of it as an API
 that manages the user's login and information.
 
-```javascript {data-filename=app/components/user-profile.js}
+```gjs {data-filename=app/components/user-profile.gjs}
 import Component from '@glimmer/component';
 import { service } from '@ember/service';
-import { action } from '@ember/object';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
 
 export default class UserProfileComponent extends Component {
   @service login;
 
-  @action
-  deleteAccount() {
+  deleteAccount = () => {
     this.login.deleteUser();
   }
+
+  <template>
+    <ButtonWithConfirmation
+      @text="Click OK to delete your account."
+    />
+  </template>
 }
 ```
 
@@ -177,42 +210,78 @@ action to be triggered. In order to trigger the action when the user clicks "OK"
 in the `ButtonWithConfirmation` component, we'll need to pass the action _down_
 to it as an argument:
 
-```handlebars {data-filename=app/components/user-profile.hbs}
-<ButtonWithConfirmation
-  @text="Click OK to delete your account."
-  @onConfirm={{this.deleteAccount}}
-/>
+```gjs {data-filename=app/components/user-profile.gjs}
+import Component from '@glimmer/component';
+import { service } from '@ember/service';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
+
+export default class UserProfileComponent extends Component {
+  @service login;
+
+  deleteAccount = () => {
+    this.login.deleteUser();
+  }
+
+  <template>
+    <ButtonWithConfirmation
+      @text="Click OK to delete your account."
+      @onConfirm={{this.deleteAccount}}
+    />
+  </template>
+}
 ```
 
 Next, in the child component we will implement the logic to confirm that the
 user wants to take the action they indicated by clicking the button:
 
-```javascript {data-filename=app/components/button-with-confirmation.js}
+```gjs {data-filename=app/components/button-with-confirmation.gjs}
 import Component from '@glimmer/component';
 import { tracked } from '@glimmer/tracking';
-import { action } from '@ember/object';
+import { on } from '@ember/modifier';
 
 export default class ButtonWithConfirmationComponent extends Component {
   @tracked isConfirming = false;
 
-  @action
-  launchConfirmDialog() {
+  launchConfirmDialog = () => {
     this.isConfirming = true;
-  }
+  };
 
-  @action
-  submitConfirm() {
+  submitConfirm = () => {
     if (this.args.onConfirm) {
       this.args.onConfirm();
     }
 
     this.isConfirming = false;
-  }
+  };
 
-  @action
-  cancelConfirm() {
+  cancelConfirm = () => {
     this.isConfirming = false;
-  }
+  };
+
+  <template>
+    <button type="button" {{on "click" this.launchConfirmDialog}}>
+      {{@text}}
+    </button>
+
+    {{#if this.isConfirming}}
+      <div class="confirm-dialog">
+        <button
+          type="button"
+          class="confirm-submit"
+          {{on "click" this.submitConfirm}}
+        >
+          OK
+        </button>
+        <button
+          type="submit"
+          class="confirm-cancel"
+          {{on "click" this.cancelConfirm}}
+        >
+          Cancel
+        </button>
+      </div>
+    {{/if}}
+  </template>
 }
 ```
 
@@ -235,33 +304,56 @@ accomplished by expecting a promise to be returned from `onConfirm`. Upon
 resolution of the promise, we set a property used to indicate the visibility of
 the confirmation modal. We can use an `async` function to handle that promise:
 
-```javascript {data-filename=app/components/button-with-confirmation.js}
+```gjs {data-filename=app/components/button-with-confirmation.gjs}
 import Component from '@glimmer/component';
 import { tracked } from '@glimmer/tracking';
-import { action } from '@ember/object';
+import { on } from '@ember/modifier';
 
 export default class ButtonWithConfirmationComponent extends Component {
   @tracked isConfirming = false;
 
-  @action
-  launchConfirmDialog() {
+  launchConfirmDialog = () => {
     this.isConfirming = true;
-  }
+  };
 
-  @action
-  async submitConfirm() {
+  submitConfirm = async () => {
     if (this.args.onConfirm) {
       await this.args.onConfirm();
     }
 
     this.isConfirming = false;
-  }
+  };
 
-  @action
-  cancelConfirm() {
+  cancelConfirm = () => {
     this.isConfirming = false;
-  }
+  };
+
+  <template>
+    <button type="button" {{on "click" this.launchConfirmDialog}}>
+      {{@text}}
+    </button>
+
+    {{#if this.isConfirming}}
+      <div class="confirm-dialog">
+        <button
+          type="button"
+          class="confirm-submit"
+          {{on "click" this.submitConfirm}}
+        >
+          OK
+        </button>
+        <button
+          type="submit"
+          class="confirm-cancel"
+          {{on "click" this.cancelConfirm}}
+        >
+          Cancel
+        </button>
+      </div>
+    {{/if}}
+  </template>
 }
+
 ```
 
 ## Passing Arguments
@@ -272,15 +364,17 @@ where the `ButtonWithConfirmation` component we've defined is used within
 `SendMessage`. The `sendMessage` action that we pass to the child component may
 expect a message type parameter to be provided as an argument:
 
-```javascript {data-filename=app/components/send-message.js}
+```gjs {data-filename=app/components/send-message.gjs}
 import Component from '@glimmer/component';
-import { action } from '@ember/object';
 
 export default class SendMessageComponent extends Component {
-  @action
-  async sendMessage(messageType) {
+  sendMessage = async (messageType) => {
     // send message here and return a promise
-  }
+  };
+
+  <template>
+    {{! ... send message ... }}
+  </template>
 }
 ```
 
@@ -290,18 +384,32 @@ template can provide the required parameter when the action is passed to the
 child. For example, if we want to use the button to send a message of type
 `"info"`:
 
-```handlebars {data-filename=app/components/send-message.hbs}
-<ButtonWithConfirmation
-  @text="Click to send your message."
-  @onConfirm={{fn this.sendMessage "info"}}
-/>
+```gjs {data-filename=app/components/send-message.gjs}
+import Component from '@glimmer/component';
+import { fn } from '@ember/helper';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
+
+export default class SendMessageComponent extends Component {
+  sendMessage = async (messageType) => {
+    // send message here and return a promise
+  };
+
+  <template>
+    <ButtonWithConfirmation
+      @text="Click to send your message."
+      @onConfirm={{fn this.sendMessage "info"}}
+    />
+  </template>
+}
 ```
 
 Within `ButtonWithConfirmation`, the code in the `submitConfirm` action does not
 change. It will still invoke `onConfirm` without explicit arguments:
 
-```javascript {data-filename=app/components/button-with-confirmation.js}
-await this.args.onConfirm();
+```gjs {data-filename=app/components/button-with-confirmation.gjs}
+  // ...
+  await this.args.onConfirm();
+  // ...
 ```
 
 However the expression `{{fn this.sendMessage "info"}}` used in passing the
@@ -314,15 +422,15 @@ a function that accepts one argument, `messageType`. Suppose we want to extend
 this by allowing `sendMessage` to take a second argument, the actual text of the
 message the user is sending:
 
-```javascript {data-filename=app/components/send-message.js}
+```gjs {data-filename=app/components/send-message.gjs}
 import Component from '@glimmer/component';
-import { action } from '@ember/object';
 
 export default class SendMessageComponent extends Component {
-  @action
-  async sendMessage(messageType, messageText) {
+  sendMessage = async (messageType, messageText) => {
     // send message here and return a promise
-  }
+  };
+
+  // ...
 }
 ```
 
@@ -343,20 +451,18 @@ in a messaging application. Therefore within the component's JavaScript file, we
 will use a property `confirmValue` to represent that argument and pass it to
 `onConfirm` as shown here:
 
-```javascript {data-filename=app/components/button-with-confirmation.js}
+```gjs {data-filename=app/components/button-with-confirmation.gjs}
 import Component from '@glimmer/component';
-import { action } from '@ember/object';
 
 export default class ButtonWithConfirmationComponent extends Component {
-  @action
-  async submitConfirm() {
+  submitConfirm = async() => {
     if (this.args.onConfirm) {
       // call `onConfirm` with a second argument
       await this.args.onConfirm(this.confirmValue);
     }
 
     this.isConfirming = false;
-  }
+  };
 
   //...
 }
@@ -369,41 +475,71 @@ be used in block form and we will pass `confirmValue` as a
 [block parameter](../../components/block-content/) within the confirm dialog
 element:
 
-```handlebars {data-filename=app/components/button-with-confirmation.hbs}
-<button type="button" {{on "click" this.launchConfirmDialog}}>
-  {{this.text}}
-</button>
+```gjs {data-filename=app/components/button-with-confirmation.gjs}
+import Component from '@glimmer/component';
 
-{{#if this.isConfirming}}
-  <div class="confirm-dialog">
-    {{yield this.confirmValue}}
+export default class ButtonWithConfirmationComponent extends Component {
+  submitConfirm = async() => {
+    if (this.args.onConfirm) {
+      // call `onConfirm` with a second argument
+      await this.args.onConfirm(this.confirmValue);
+    }
 
-    <button type="button"
-      class="confirm-submit"
-      {{on "click" this.submitConfirm}}
-    >
-      OK
-    </button>
-    <button type="button"
-      class="confirm-cancel"
-      {{on "click" this.cancelConfirm}}
-    >
-      Cancel
+    this.isConfirming = false;
+  };
+
+  <template>
+    <button type="button" {{on "click" this.launchConfirmDialog}}>
+      {{this.text}}
     </button>
-  </div>
-{{/if}}
+
+    {{#if this.isConfirming}}
+      <div class="confirm-dialog">
+        {{yield this.confirmValue}}
+
+        <button type="button"
+          class="confirm-submit"
+          {{on "click" this.submitConfirm}}
+        >
+          OK
+        </button>
+        <button type="button"
+          class="confirm-cancel"
+          {{on "click" this.cancelConfirm}}
+        >
+          Cancel
+        </button>
+      </div>
+    {{/if}}
+  </template>
+}
+
 ```
 
 With this modification, we can now use the component in `SendMessage` to wrap a
 text input element whose `value` attribute is set to `confirmValue`:
 
-```handlebars {data-filename=app/components/send-message.hbs}
-<ButtonWithConfirmation
-  @text="Click to send your message."
-  @onConfirm={{fn this.sendMessage "info"}}
-as |confirmValue|>
-  <Input @value={{confirmValue}} />
-</ButtonWithConfirmation>
+```gjs {data-filename=app/components/send-message.gjs}
+import Component from '@glimmer/component';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
+import { Input } from '@ember/component';
+
+export default class SendMessageComponent extends Component {
+  // ...
+
+  sendMessage = async (messageType, messageText) => {
+    // send message here and return a promise
+  };
+
+  <template>
+    <ButtonWithConfirmation
+      @text="Click to send your message."
+      @onConfirm={{fn this.sendMessage "info"}}
+    as |confirmValue|>
+      <Input @value={{confirmValue}} />
+    </ButtonWithConfirmation>
+  </template>
+}
 ```
 
 When the user enters their message into the input field, the message text will
@@ -417,32 +553,34 @@ with the provided `confirmValue`, thus invoking the `sendMessage` action in
 Actions can be invoked on objects other than the component directly from the
 template. For example, in our `SendMessage` component we might include a service
 that processes the `sendMessage` logic.
+We can tell the action to invoke the `sendMessage` action directly on the
+messaging service.
 
-```javascript {data-filename=app/components/send-message.js}
+```gjs {data-filename=app/components/send-message.gjs}
 import Component from '@glimmer/component';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
+import { Input } from '@ember/component';
 import { service } from '@ember/service';
 
 export default class SendMessageComponent extends Component {
   @service messaging;
 
-  // component implementation
-}
-```
-
-We can tell the action to invoke the `sendMessage` action directly on the
-messaging service.
+  // ... component implementation
 
-```handlebars {data-filename=app/components/send-message.hbs}
-<ButtonWithConfirmation
-  @text="Click to send your message."
-  @onConfirm={{fn this.messaging.sendMessage "info"}}
-as |confirmValue|>
-  <Input @value={{confirmValue}} />
-</ButtonWithConfirmation>
+  <template>
+    <ButtonWithConfirmation
+      @text="Click to send your message."
+      @onConfirm={{fn this.messaging.sendMessage "info"}}
+      as |confirmValue|
+    >
+      <Input @value={{confirmValue}} />
+    </ButtonWithConfirmation>
+  </template>
+}
 ```
 
-The interesting part is that the action from the service just works, because
-it's auto-bound to that service.
+The interesting part is that the action from the service just works, as long as
+it's bound to that service.
 
 ```javascript {data-filename=app/services/messaging.js}
 import Service from '@ember/service';
@@ -456,6 +594,18 @@ export default class Messaging extends Service {
 }
 ```
 
+or
+
+```javascript {data-filename=app/services/messaging.js}
+import Service from '@ember/service';
+
+export default class Messaging extends Service {
+  sendMessage = async (messageType, text) {
+    // handle message send and return a promise
+  }
+}
+```
+
 ## Destructuring Objects Passed as Action Arguments
 
 A component will often not know what information a parent needs to process an
@@ -464,20 +614,22 @@ action, and will just pass all the information it has. For example, our
 `SystemPreferencesEditor`, that a user's account was deleted, and passes along
 with it the full user profile object.
 
-```javascript {data-filename=app/components/user-profile.js}
+```gjs {data-filename=app/components/user-profile.gjs}
 import Component from '@glimmer/component';
 import { service } from '@ember/service';
-import { action } from '@ember/object';
 
 export default class UserProfileComponent extends Component {
   @service login;
 
-  @action
-  async deleteAccount() {
+  deleteAccount = async () => {
     await this.login.deleteUser();
 
     this.args.didDelete(this.login.currentUserObj);
-  }
+  };
+
+  <template>
+    {{! user profile }}
+  </template>
 }
 ```
 
@@ -485,23 +637,24 @@ All our `SystemPreferencesEditor` component really needs to process a user
 deletion is an account ID. For this case, the `fn` helper provides the value
 via partial application to allow a parent component to dig into the passed
 object to pull out only what it needs.
-
-```handlebars {data-filename=app/components/system-preferences-editor.hbs}
-<UserProfile @didDelete={{fn this.userDeleted this.login.currentUser.id}} />
-```
-
 Now when the `SystemPreferencesEditor` handles the delete action, it receives
 only the user's account `id` string.
 
-```javascript {data-filename=app/components/system-preferences-editor.js}
+```gjs {data-filename=app/components/system-preferences-editor.gjs}
 import Component from '@glimmer/component';
-import { action } from '@ember/object';
+import { fn } from '@ember/helper';
+import UserProfile from 'my-app/components/user-profile';
 
 export default class SystemPreferencesEditorComponent extends Component {
-  @action
-  userDeleted(idStr /* , native clickEvent */) {
+  // ...
+
+  userDeleted = (idStr /* , native clickEvent */) => {
     // respond to deletion
-  }
+  };
+
+  <template>
+    <UserProfile @didDelete={{fn this.userDeleted this.login.currentUser.id}} />
+  </template>
 }
 ```
 
@@ -518,45 +671,52 @@ adding JavaScript code to those child components.
 For example, say we want to move account deletion from the `UserProfile`
 component to its parent `SystemPreferencesEditor`.
 
-First we would move the `deleteUser` action from `user-profile.js` to
-the parent `system-preferences-editor.js`.
+First we would move the `deleteUser` action from `user-profile.gjs` to
+the parent `system-preferences-editor.gjs` and pass the local `deleteUser` action into the `UserProfile` as that component's `deleteCurrentUser` argument.
+
 
-```javascript {data-filename=app/components/system-preferences-editor.js}
+```gjs {data-filename=app/components/system-preferences-editor.gjs}
 import Component from '@glimmer/component';
 import { service } from '@ember/service';
-import { action } from '@ember/object';
+import { fn } from '@ember/helper';
+import UserProfile from 'my-app/components/user-profile';
 
 export default class SystemPreferencesEditorComponent extends Component {
   @service login;
 
-  @action
-  deleteUser(idStr) {
+  deleteUser = (idStr) => {
     return this.login.deleteUserAccount(idStr);
-  }
-}
-```
+  };
 
-Then our `SystemPreferencesEditor` template passes its local `deleteUser`
-action into the `UserProfile` as that component's `deleteCurrentUser` argument.
-
-```handlebars {data-filename=app/components/system-preferences-editor.hbs}
-<UserProfile
-  @deleteCurrentUser={{fn this.deleteUser this.login.currentUser.id}}
-/>
+  <template>
+    <UserProfile
+      @deleteCurrentUser={{fn this.deleteUser this.login.currentUser.id}}
+    />
+  </template>
+}
 ```
 
 The `deleteUser` action is prepended with `this.`, since
 `SystemPreferencesEditor` is where the action is defined now. If the action
 was passed from a parent, then it might have looked like `@deleteUser` instead.
 
-In our `user-profile.hbs` template we change our action to call
+In our `UserProfile` component we change our action to call
 `deleteCurrentUser` as passed above.
 
-```handlebars {data-filename=app/components/user-profile.hbs}
-<ButtonWithConfirmation
-  @text="Click OK to delete your account."
-  @onConfirm={{@deleteCurrentUser}}
-/>
+```gjs {data-filename=app/components/user-profile.gjs}
+import Component from '@glimmer/component';
+import { service } from '@ember/service';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
+
+export default class UserProfileComponent extends Component {
+  // ...
+
+  <template>
+    <ButtonWithConfirmation
+      @text="Click OK to delete your account."
+      @onConfirm={{@deleteCurrentUser}}
+    />
+  </template>
 ```
 
 Note that `deleteCurrentUser` is now prepended with `@` as opposed to `this.`
diff --git a/guides/release/in-depth-topics/patterns-for-components.md b/guides/release/in-depth-topics/patterns-for-components.md
index 077e61a07c..1942261fa1 100644
--- a/guides/release/in-depth-topics/patterns-for-components.md
+++ b/guides/release/in-depth-topics/patterns-for-components.md
@@ -13,7 +13,7 @@ provided.
 For instance, if you wanted to create a tooltip icon that had a standard icon
 and class, you could do it like so:
 
-```javascript {data-filename=app/components/tooltip.js}
+```gjs {data-filename=app/components/tooltip.gjs}
 import Component from '@glimmer/component';
 
 export default class TooltipComponent extends Component {
@@ -24,20 +24,24 @@ export default class TooltipComponent extends Component {
   get tooltipClass() {
     return this.args.tooltipClass + ' tooltip';
   }
-}
-```
 
-```handlebars {data-filename=app/components/tooltip.hbs}
-<div class={{this.tooltipClass}}>
-  <i class={{this.icon}}></i>
-  {{@content}}
-</div>
+  <template>
+    <div class={{this.tooltipClass}}>
+      <i class={{this.icon}}></i>
+      {{@content}}
+    </div>
+  </template>
+}
 ```
 
 Now when called like so:
 
-```handlebars
-<Tooltip @content="I'm a tooltip!"/>
+```gjs
+import Tooltip from 'my-app/components/tooltip';
+
+<template>
+  <Tooltip @content="I'm a tooltip!"/>
+</template>
 ```
 
 The result will be:
@@ -65,14 +69,16 @@ The positioning of `...attributes` matters, with respect to the other attributes
 in the element it is applied to. Attributes that come _before_ `...attributes`
 can be overridden, but attributes that come _after_ cannot:
 
-```handlebars
-<p
-  data-overridable="you can override me"
-  ...attributes
-  data-non-overridable="but you can't override me!"
->
-  ...
-</p>
+```gjs
+<template>
+  <p
+    data-overridable="you can override me"
+    ...attributes
+    data-non-overridable="but you can't override me!"
+  >
+    ...
+  </p>
+</template>
 ```
 
 There is one exception to this, which is the `class` attribute. `class` will get
@@ -80,10 +86,12 @@ merged, since its more often the case that users of the component want to _add_
 a class than completely override the existing ones. For `class`, the order of
 `...attributes` will determine the order of merging. Putting it before:
 
-```handlebars
-<p ...attributes class="friend-greeting">
-  Hello {{@friend}}, I'm {{this.name}}!
-</p>
+```gjs
+<template>
+  <p ...attributes class="friend-greeting">
+    Hello {{@friend}}, I'm {{this.name}}!
+  </p>
+</template>
 ```
 
 Results in:
@@ -96,10 +104,12 @@ Results in:
 
 And putting it after:
 
-```handlebars
-<p class="friend-greeting" ...attributes>
-  Hello {{@friend}}, I'm {{this.name}}!
-</p>
+```gjs
+<template>
+  <p class="friend-greeting" ...attributes>
+    Hello {{@friend}}, I'm {{this.name}}!
+  </p>
+</template>
 ```
 
 Results in:
@@ -117,134 +127,181 @@ The most frequently used of these is `aria-describedby` and `aria-labelledby`.
 
 In these cases, make sure to declare _all_ of the relevant values in the correct order.
 
-```handlebars
-<MyInput @input-label="Password" aria-describedby="text-help-0 text-help-1" />
+```gjs
+import MyInput from 'my-app/components/my-input';
+
+<template>
+  <MyInput @input-label="Password" aria-describedby="text-help-0 text-help-1" />
+</template>
 ```
 
 To learn more about `aria` roles and accessibility in Ember, check out the [Accessibility Guide](../../reference/accessibility-guide/).
 
-## Contextual Components
+## Conditional Component Rendering
 
-The [`{{component}}`](https://api.emberjs.com/ember/release/classes/Ember.Templates.helpers/methods/component?anchor=component)
-helper can be used to defer the selection of a component to runtime. The
-`<MyComponent />` syntax always renders the same component, while using the
-`{{component}}` helper allows choosing a component to render on the fly. This is
-useful in cases where you want to interact with different external libraries
-depending on the data. Using the `{{component}}` helper would allow you to keep
-different logic well separated.
+Sometimes you want to defer the selection of a component to runtime. Suppose you have a blog post model that contains a string `postType` indicating that the post is either a "root" or a "reply".
+Below is an example of choosing different components for
+displaying different kinds of posts.  First, define your two components:
 
-The first parameter of the helper is the name of a component to render, as a
-string. So `{{component 'blog-post'}}` is the same as using `<BlogPost />`.
 
-The real value of [`{{component}}`](https://api.emberjs.com/ember/release/classes/Ember.Templates.helpers/methods/component?anchor=component)
-comes from being able to dynamically pick the component being rendered. Below is
-an example of using the helper as a means of choosing different components for
-displaying different kinds of posts:
+```gjs {data-filename=app/components/root-post.gjs}
+<template>
+  <h3>Hello from root!</h3>
+  <p>{{@post.body}}</p>
+</template>
+```
 
-```handlebars {data-filename=app/components/foo-component.hbs}
-<h3>Hello from foo!</h3>
-<p>{{this.post.body}}</p>
+```gjs {data-filename=app/components/reply-post.gjs}
+<template>
+  <h3>Hello from reply!</h3>
+  <div>{{@post.author}}</div>
+</template>
 ```
 
-```handlebars {data-filename=app/components/bar-component.hbs}
-<h3>Hello from bar!</h3>
-<div>{{this.post.author}}</div>
+Then, you can choose which to render based on the data:
+
+```gjs {data-filename=app/templates/index.gjs}
+import RootPost from  'my-app/components/root-post';
+import ReplyPost from 'my-app/components/reply-post';
+
+// returns either RootPost or ReplyPost (default: RootPost)
+function getPostComponent(postType) {
+  return postType === 'reply' ? ReplyPost : RootPost;
+}
+
+<template>
+  {{#each this.myPosts as |post|}}
+    {{!-- Post is either RootPost or ReplyPost --}}
+    {{#let (getPostComponent post.postType) as |Post|}}
+      <Post @author={{post.author}} @body={{post.body}} />
+    {{/let}}
+  {{/each}}
+</template>
 ```
 
-```handlebars {data-filename=app/templates/index.hbs}
-{{#each this.myPosts as |post|}}
-  {{!-- either foo-component or bar-component --}}
-  {{component post.postType post=post}}
-{{/each}}
+This is great when `RootPost` and `ReplyPost` take the same arguments, like `author` and `body` in the above example. But what if the components accept different arguments? One way would be to move the selection conditional into the template, like so:
+
+```gjs {data-filename=app/templates/index.gjs}
+import RootPost from 'my-app/components/root-post';
+import ReplyPost from 'my-app/components/reply-post';
+
+const eq = (a, b) => a === b;
+
+<template>
+  {{#each this.myPosts as |post|}}
+    {{!-- Post is either RootPost or ReplyPost --}}
+    {{#if (eq post.postType "reply")}}
+      <ReplyPost
+        @author={{post.author}}
+        @body={{post.body}}
+        @replyTo={{post}}
+      />
+    {{else}}
+      <RootPost
+        @author={{post.author}}
+        @body={{post.body}}
+        @category={{post.topic}}
+      />
+    {{/if}}
+  {{/each}}
+</template>
 ```
 
-or
+## Contextual Components
 
-```handlebars {data-filename=app/templates/index.hbs}
-{{#each this.myPosts as |post|}}
-  {{!-- either foo-component or bar-component --}}
-  {{#let (component post.postType) as |Post|}}
-    <Post @post={{post}} />
-  {{/let}}
-{{/each}}
-```
+The built-in [`{{component}}`](https://api.emberjs.com/ember/release/classes/Ember.Templates.helpers/methods/component?anchor=component)
+helper allows us to partially apply some component arguments.
+
+The first parameter of the helper is a component to render. So `{{component BlogPost}}` is the same as using `<BlogPost />`.  Any named arguments are passed as arguments to the component, so `{{component BlogPost author="Sam"}}` is the same as `<BlogPost @author="sam" />`.
+
+The `component` helper is often used when yielding components to blocks. For example the layout for a SuperForm component might be implemented as:
 
-Or, for example the layout for a SuperForm component might be implemented as:
+```gjs {data-filename=app/components/super-form.gjs}
+import { hash } from '@ember/helper';
+import SuperInput from 'my-app/components/super-input';
+import SuperTextarea from 'my-app/components/super-textarea';
+import SuperSubmit from 'my-app/components/super-submit';
 
-```handlebars {data-filename=app/components/super-form.hbs}
-<form>
-  {{yield (hash
-    Input=(component "super-input" form=this model=this.model)
-    Textarea=(component "super-textarea" form=this model=this.model)
-    Submit=(component "super-submit" form=this model=this.model)
-  )}}
-</form>
+<template>
+  <form>
+    {{yield (hash
+      Input=(component SuperInput form=this model=this.model)
+      Textarea=(component SuperTextarea form=this model=this.model)
+      Submit=(component SuperSubmit form=this model=this.model)
+    )}}
+  </form>
+</template>
 ```
 
 And be used as:
 
-```handlebars {data-filename=app/templates/index.hbs}
-<SuperForm @model={{this.post}} as |f|>
-  <f.Input @name="title" />
-  <f.Textarea @name="body" />
-  <f.Submit />
-</SuperForm>
-```
+```gjs {data-filename=app/templates/index.gjs}
+import SuperForm from 'my-app/components/super-form';
 
-When the parameter passed to `{{component}}` evaluates to `null` or `undefined`,
-the helper renders nothing. When the parameter changes, the currently rendered
-component is destroyed and the new component is created and brought in.
+<template>
+  <SuperForm @model={{this.post}} as |f|>
+    <f.Input @name="title" />
+    <f.Textarea @name="body" />
+    <f.Submit />
+  </SuperForm>
+</template>
+```
 
-Picking different components to render in response to the data allows you to
-have a different template and behavior for each case. The `{{component}}` helper
-is a powerful tool for improving code modularity.
+The `{{component}}` helper is a powerful tool for improving code modularity.
 
 ### Contextual helpers & modifiers
 
 We can even use helpers and modifiers in the same way. Let's extend the SuperForm component:
 
-```handlebars {data-filename=app/components/super-form.hbs}
-<form>
-  {{yield (hash
+```gjs {data-filename=app/components/super-form.gjs}
+import { hash } from '@ember/helper';
+import SuperInput from 'my-app/components/super-input';
+import SuperTextarea from 'my-app/components/super-textarea';
+import SuperSubmit from 'my-app/components/super-submit';
+import superIsValid from 'my-app/helpers/super-is-valid';
+import superErrorFor from 'my-app/helpers/super-error-for';
+import superAutoResize from 'my-app/modifiers/super-auto-resize';
 
-    Input=(component "super-input" form=this model=this.model)
-    Textarea=(component "super-textarea" form=this model=this.model)
-    Submit=(component "super-submit" form=this model=this.model)
+<template>
+  <form>
+    {{yield (hash
 
-    is-valid=(helper "super-is-valid" form=this model=this.model)
-    error-for=(helper "super-error-for" form=this model=this.model)
+      Input=(component SuperInput form=this model=this.model)
+      Textarea=(component SuperTextarea form=this model=this.model)
+      Submit=(component SuperSubmit form=this model=this.model)
 
-    auto-resize=(modifier "super-auto-resize")
+      is-valid=(helper superIsValid form=this model=this.model)
+      error-for=(helper superErrorFor form=this model=this.model)
 
-  )}}
-</form>
+      auto-resize=(modifier superAutoResize)
+
+    )}}
+  </form>
+</template>
 ```
 
 And be used as:
 
-```handlebars {data-filename=app/templates/index.hbs}
-<SuperForm @model={{this.post}} as |f|>
+```gjs {data-filename=app/templates/index.gjs}
+import SuperForm from 'my-app/components/super-form';
+
+<template>
+  <SuperForm @model={{this.post}} as |f|>
 
-  {{! Invoke a contextual component }}
-  <f.Input @name="title" />
+    {{! Invoke a contextual component }}
+    <f.Input @name="title" />
 
-  {{! Invoke contextual helpers }}
-  {{#unless (f.is-valid "title")}}
-    <div class="error">This field {{f.error-for "title"}}</div>
-  {{/unless}}
+    {{! Invoke contextual helpers }}
+    {{#unless (f.is-valid "title")}}
+      <div class="error">This field {{f.error-for "title"}}</div>
+    {{/unless}}
 
-  {{! Invoke a contextual modifier on a contextual component invocation }}
-  <f.Textarea @name="body" {{f.auto-resize maxHeight="500"}} />
+    {{! Invoke a contextual modifier on a contextual component invocation }}
+    <f.Textarea @name="body" {{f.auto-resize maxHeight="500"}} />
 
-  <f.Submit />
-</SuperForm>
+    <f.Submit />
+  </SuperForm>
+</template>
 ```
 
 These APIs open the doors for the creation of new, more powerful UI abstractions.
-
-## Learn More
-
-To keep this guide concise, we built a separate site for [component patterns in Ember](https://emberjs-1.gitbook.io/ember-component-patterns/).
-This project also addresses anti-patterns and accessibility for components.
-
-[![ember-component-patterns](/images/ember-component-patterns.png)](https://emberjs-1.gitbook.io/ember-component-patterns/)
diff --git a/guides/release/in-depth-topics/rendering-values.md b/guides/release/in-depth-topics/rendering-values.md
index c3b04407f7..9f6f875aa3 100644
--- a/guides/release/in-depth-topics/rendering-values.md
+++ b/guides/release/in-depth-topics/rendering-values.md
@@ -4,88 +4,129 @@ In Ember, rendering occurs via syntax, rather than by value -- so _anything_ can
 
 For Modifiers, there is a specific syntax that only modifiers may reside in
 
-```handlebars
-<div {{someModifier}}>
+```gjs
+<template>
+  <div {{someModifier}}>
+</template>
 ```
 or via property on some object
 
-```handlebars
-<div {{this.property.someModifier}}>
+```gjs
+<template>
+  <div {{this.property.someModifier}}>
+</template>
 ```
 or via an argument passed to a component
 
-```handlebars
-<div {{@someModifier}}>
+```gjs
+<template>
+  <div {{@someModifier}}>
+</template>
 ```
 
-Modifiers can be curried with the `modifier` helper:
+Modifiers can be curried with the `modifier` helper keyword:
 
-```handlebars
-{{! In a component called "Example" }}
-{{yield (modifier someModifier "arguments" "here")}}
+```gjs
+<template>
+  {{! In a component called "Example" }}
+  {{yield (modifier someModifier "arguments" "here")}}
+</template>
+```
 
-{{! Usage: }}
-<Example as |theModifier|>
-  <div {{theModifier}}>
-</Example>
+```gjs
+<template>
+  {{! Usage: }}
+  <Example as |theModifier|>
+    <div {{theModifier}}>
+  </Example>
+</template>
 ```
 
 
 ## Helpers
 
 For Helpers, there is a specific syntax that only helpers may reside in
-```handlebars
-{{ (theHelper) }}
+```gjs
+<template>
+  {{ (theHelper) }}
+</template>
 ```
 or nested in a sub-expression
-```handlebars
-{{yield (hash key=(theHelper) key2=(theHelper with args)) }}
+```gjs
+import { hash } from '@ember/helper';
+
+<template>
+  {{yield (hash key=(theHelper) key2=(theHelper with args)) }}
+</template>
 ```
 or via property on some object
-```handlebars
-{{ (this.property.theHelper) }}
+```gjs
+<template>
+  {{ (this.property.theHelper) }}
+</template>
 ```
 or via an argument passed to a component
-```handlebars
-{{ (@theHelper) }}
+```gjs
+<template>
+  {{ (@theHelper) }}
+</template>
 ```
 
-Helpers can be curried with the `helper` helper:
-```handlebars
-{{! In a component called "Example" }}
-{{yield (helper someHelper "arguments" "here")}}
+Helpers can be curried with the `helper` helper keyword:
+```gjs
+<template>
+  {{! In a component called "Example" }}
+  {{yield (helper someHelper "arguments" "here")}}
+</template>
+```
 
-{{! Usage: }}
-<Example as |theHelper|>
-  {{ (theHelper) }}
-</Example>
+```gjs
+<template>
+  {{! Usage: }}
+  <Example as |theHelper|>
+    {{ (theHelper) }}
+  </Example>
+</template>
 ```
 
 ## Components
 
 For Components, there is a specific syntax that only components may reside in
-```handlebars
-<AComponent />
+```gjs
+<template>
+  <AComponent />
+</template>
 ```
 or via a property on some object
-```handlebars
-<this.someComponent />
+```gjs
+<template>
+  <this.someComponent />
+</template>
 ```
 or via an argument passed to a component
-```handlebars
-<@someComponent />
+```gjs
+<template>
+  <@someComponent />
+</template>
 ```
 
-Components can be curried with the `component` helper:
-```handlebars
-{{!
+Components can be curried with the `component` helper keyword:
+```gjs
+<template>
+  {{!
   In a component called "Example".
   Note that components may only receive named arguments
-}}
-{{yield (component someComponent foo="arguments" bar="here")}}
+  }}
+  {{yield (component someComponent foo="arguments" bar="here")}}
+</template>
+```
 
-{{! Usage: }}
-<Example as |theComponent|>
-  <theComponent />
-</Example>
+```gjs
+<template>
+  {{! Usage: }}
+  <Example as |theComponent|>
+    <theComponent />
+  </Example>
+</template>
 ```
+<!-- eof - needed for pages that end in a code block  -->