From 98e463052a0bcf988c9f80e5082052f0a37bf985 Mon Sep 17 00:00:00 2001
From: Tommy Carter <tommyjr@gmail.com>
Date: Tue, 15 Jul 2025 12:01:49 -0500
Subject: [PATCH 1/9] Updated autotracking in depth to use gjs

---
 .../in-depth-topics/autotracking-in-depth.md  | 145 ++++++++++++------
 1 file changed, 98 insertions(+), 47 deletions(-)

diff --git a/guides/release/in-depth-topics/autotracking-in-depth.md b/guides/release/in-depth-topics/autotracking-in-depth.md
index 0ff6f514ce..925b2f4da8 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 '../components/hello.gjs';
+
+<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>
 }
 ```
 
@@ -246,27 +292,29 @@ 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';
+
+// TODO: Q: Is this the right way to do stateful route components???
+//       Do we still need to use the RouteTemplate wrapper from 'ember-route-template'?
+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 +410,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 +432,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
 ```
 

From 0518d16855212b21550f9bd7467b68ae88d1793f Mon Sep 17 00:00:00 2001
From: Tommy Carter <tommyjr@gmail.com>
Date: Fri, 18 Jul 2025 07:30:07 -0500
Subject: [PATCH 2/9] Updated patterns for components to use gjs

---
 .../patterns-for-components.md                | 283 +++++++++++-------
 1 file changed, 169 insertions(+), 114 deletions(-)

diff --git a/guides/release/in-depth-topics/patterns-for-components.md b/guides/release/in-depth-topics/patterns-for-components.md
index 077e61a07c..7fa29a4b98 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 '../components/tooltip.gjs';
+
+<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,179 @@ 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 '../components/my-input.gjs';
+
+<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 '../components/root-post.gjs';
+import ReplyPost from '../components/reply-post.gjs';
+
+// 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 '../components/root-post.gjs';
+import ReplyPost from '../components/reply-post.gjs';
+
+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 SuperInput from './super-input.gjs';
+import SuperTextarea from './super-input.gjs';
+import SuperSubmit from './super-input.gjs';
 
-```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 '../components/super-form.gjs';
 
-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 SuperInput from './super-input.gjs';
+import SuperTextarea from './super-input.gjs';
+import SuperSubmit from './super-input.gjs';
+import superIsValid from '../helpers/super-is-valid.js';
+import superErrorFor from '../helpers/super-error-for.js';
+import superAutoResize from '../modifiers/super-auto-resize.js';
 
-    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 '../components/super-form.gjs';
+
+<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/)

From 0b29b30be4026634ee98ca03a4881a7bec2d4205 Mon Sep 17 00:00:00 2001
From: Tommy Carter <tommyjr@gmail.com>
Date: Tue, 29 Jul 2025 09:47:12 -0500
Subject: [PATCH 3/9] Updated patterns for actions to use gjs

---
 .../in-depth-topics/patterns-for-actions.md   | 580 +++++++++++-------
 1 file changed, 370 insertions(+), 210 deletions(-)

diff --git a/guides/release/in-depth-topics/patterns-for-actions.md b/guides/release/in-depth-topics/patterns-for-actions.md
index d753a80d61..34e20b222b 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 functionaly equivalent and are used interchangably 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 './button-with-confirmation.gjs';
+
+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 './button-with-confirmation.gjs';
 
 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 './button-with-confirmation.gjs';
+
+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 './button-with-confirmation.gjs';
+
+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 './button-with-confirmation.gjs';
+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 './button-with-confirmation.gjs';
+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 './user-profile.gjs';
 
 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 './user-profile.gjs';
 
 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 './button-with-confirmation.gjs';
+
+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.`

From a0ae294275c4e764d5710fe87590e24908a14b7f Mon Sep 17 00:00:00 2001
From: Tommy Carter <tommyjr@gmail.com>
Date: Tue, 29 Jul 2025 10:11:43 -0500
Subject: [PATCH 4/9] Updated rendering values to use gjs - WIP, imports

---
 .../in-depth-topics/rendering-values.md       | 124 +++++++++++-------
 1 file changed, 79 insertions(+), 45 deletions(-)

diff --git a/guides/release/in-depth-topics/rendering-values.md b/guides/release/in-depth-topics/rendering-values.md
index c3b04407f7..d103d4216b 100644
--- a/guides/release/in-depth-topics/rendering-values.md
+++ b/guides/release/in-depth-topics/rendering-values.md
@@ -4,88 +4,122 @@ 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:
 
-```handlebars
-{{! In a component called "Example" }}
-{{yield (modifier someModifier "arguments" "here")}}
-
-{{! Usage: }}
-<Example as |theModifier|>
-  <div {{theModifier}}>
-</Example>
+```gjs
+// TODO: is this the correct import for modifier helper?
+import { modifier } from '@ember/modifier';
+// ...
+<template>
+  {{! In a component called "Example" }}
+  {{yield (modifier someModifier "arguments" "here")}}
+
+  {{! 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")}}
-
-{{! Usage: }}
-<Example as |theHelper|>
-  {{ (theHelper) }}
-</Example>
+```gjs
+// TODO: import for helper helper
+// ...
+<template>
+  {{! In a component called "Example" }}
+  {{yield (helper someHelper "arguments" "here")}}
+
+  {{! 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
-{{!
+```gjs
+// TODO: import for component helper
+<template>
+  {{!
   In a component called "Example".
   Note that components may only receive named arguments
-}}
-{{yield (component someComponent foo="arguments" bar="here")}}
-
-{{! Usage: }}
-<Example as |theComponent|>
-  <theComponent />
-</Example>
+  }}
+  {{yield (component someComponent foo="arguments" bar="here")}}
+
+  {{! Usage: }}
+  <Example as |theComponent|>
+    <theComponent />
+  </Example>
+</template>
 ```

From 5591df48ce92583ae3c4f922faa118f6eb55f528 Mon Sep 17 00:00:00 2001
From: Tommy Carter <tommyjr@gmail.com>
Date: Tue, 29 Jul 2025 10:37:47 -0500
Subject: [PATCH 5/9] Resolved TODO

---
 guides/release/in-depth-topics/autotracking-in-depth.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/guides/release/in-depth-topics/autotracking-in-depth.md b/guides/release/in-depth-topics/autotracking-in-depth.md
index 925b2f4da8..041b1a2ea0 100644
--- a/guides/release/in-depth-topics/autotracking-in-depth.md
+++ b/guides/release/in-depth-topics/autotracking-in-depth.md
@@ -297,8 +297,6 @@ import Component from '@glimmer/component';
 import { on } from '@ember/modifier';
 import { fn } from '@ember/helper';
 
-// TODO: Q: Is this the right way to do stateful route components???
-//       Do we still need to use the RouteTemplate wrapper from 'ember-route-template'?
 export default class ApplicationRouteComponent extends Component {
   updateName = (title, name) => {
     this.args.model.title = title;

From 23453dd9fada03826cd40746bf83166f911bf106 Mon Sep 17 00:00:00 2001
From: Tommy Carter <tommyjr@gmail.com>
Date: Wed, 30 Jul 2025 08:27:57 -0500
Subject: [PATCH 6/9] Removed imports; updated text to refer to
 helper/modifier/component helpers as keywords

---
 .../in-depth-topics/rendering-values.md       | 27 +++++++++++--------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/guides/release/in-depth-topics/rendering-values.md b/guides/release/in-depth-topics/rendering-values.md
index d103d4216b..6bebe61b79 100644
--- a/guides/release/in-depth-topics/rendering-values.md
+++ b/guides/release/in-depth-topics/rendering-values.md
@@ -24,16 +24,17 @@ or via an argument passed to a component
 </template>
 ```
 
-Modifiers can be curried with the `modifier` helper:
+Modifiers can be curried with the `modifier` helper keyword:
 
 ```gjs
-// TODO: is this the correct import for modifier helper?
-import { modifier } from '@ember/modifier';
-// ...
 <template>
   {{! In a component called "Example" }}
   {{yield (modifier someModifier "arguments" "here")}}
+</template>
+```
 
+```gjs
+<template>
   {{! Usage: }}
   <Example as |theModifier|>
     <div {{theModifier}}>
@@ -52,8 +53,6 @@ For Helpers, there is a specific syntax that only helpers may reside in
 ```
 or nested in a sub-expression
 ```gjs
-import { hash } from '@ember/helper';
-// ...
 <template>
   {{yield (hash key=(theHelper) key2=(theHelper with args)) }}
 </template>
@@ -71,14 +70,16 @@ or via an argument passed to a component
 </template>
 ```
 
-Helpers can be curried with the `helper` helper:
+Helpers can be curried with the `helper` helper keyword:
 ```gjs
-// TODO: import for helper helper
-// ...
 <template>
   {{! In a component called "Example" }}
   {{yield (helper someHelper "arguments" "here")}}
+</template>
+```
 
+```gjs
+<template>
   {{! Usage: }}
   <Example as |theHelper|>
     {{ (theHelper) }}
@@ -107,19 +108,23 @@ or via an argument passed to a component
 </template>
 ```
 
-Components can be curried with the `component` helper:
+Components can be curried with the `component` helper keyword:
 ```gjs
-// TODO: import for component helper
 <template>
   {{!
   In a component called "Example".
   Note that components may only receive named arguments
   }}
   {{yield (component someComponent foo="arguments" bar="here")}}
+</template>
+```
 
+```gjs
+<template>
   {{! Usage: }}
   <Example as |theComponent|>
     <theComponent />
   </Example>
 </template>
 ```
+<!-- eof - needed for pages that end in a code block  -->

From 55a2d5a876fc4e5a96bf812f0a58f02d65d0c013 Mon Sep 17 00:00:00 2001
From: Tommy Carter <tommyjr@gmail.com>
Date: Sun, 3 Aug 2025 00:05:35 -0500
Subject: [PATCH 7/9] Changed import paths - no extensions - no relative paths

---
 .../in-depth-topics/autotracking-in-depth.md  |  4 +--
 .../in-depth-topics/patterns-for-actions.md   | 18 +++++-----
 .../patterns-for-components.md                | 34 +++++++++----------
 3 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/guides/release/in-depth-topics/autotracking-in-depth.md b/guides/release/in-depth-topics/autotracking-in-depth.md
index 041b1a2ea0..322fe78141 100644
--- a/guides/release/in-depth-topics/autotracking-in-depth.md
+++ b/guides/release/in-depth-topics/autotracking-in-depth.md
@@ -33,7 +33,7 @@ export default class HelloComponent extends Component {
 ```
 
 ```gjs {data-filename=app/templates/application.gjs}
-import '../components/hello.gjs';
+import 'my-app/components/hello';
 
 <template>
   <Hello @name="Jen Weber">
@@ -283,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() {
diff --git a/guides/release/in-depth-topics/patterns-for-actions.md b/guides/release/in-depth-topics/patterns-for-actions.md
index 34e20b222b..c2a7461e13 100644
--- a/guides/release/in-depth-topics/patterns-for-actions.md
+++ b/guides/release/in-depth-topics/patterns-for-actions.md
@@ -165,7 +165,7 @@ delete their profile:
 
 ```gjs {data-filename=app/components/user-profile.gjs}
 import Component from '@glimmer/component';
-import ButtonWithConfirmation from './button-with-confirmation.gjs';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
 
 export default class UserProfileComponent extends Component {
   <template>
@@ -188,7 +188,7 @@ that manages the user's login and information.
 ```gjs {data-filename=app/components/user-profile.gjs}
 import Component from '@glimmer/component';
 import { service } from '@ember/service';
-import ButtonWithConfirmation from './button-with-confirmation.gjs';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
 
 export default class UserProfileComponent extends Component {
   @service login;
@@ -213,7 +213,7 @@ to it as an argument:
 ```gjs {data-filename=app/components/user-profile.gjs}
 import Component from '@glimmer/component';
 import { service } from '@ember/service';
-import ButtonWithConfirmation from './button-with-confirmation.gjs';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
 
 export default class UserProfileComponent extends Component {
   @service login;
@@ -387,7 +387,7 @@ child. For example, if we want to use the button to send a message of type
 ```gjs {data-filename=app/components/send-message.gjs}
 import Component from '@glimmer/component';
 import { fn } from '@ember/helper';
-import ButtonWithConfirmation from './button-with-confirmation.gjs';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
 
 export default class SendMessageComponent extends Component {
   sendMessage = async (messageType) => {
@@ -521,7 +521,7 @@ text input element whose `value` attribute is set to `confirmValue`:
 
 ```gjs {data-filename=app/components/send-message.gjs}
 import Component from '@glimmer/component';
-import ButtonWithConfirmation from './button-with-confirmation.gjs';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
 import { Input } from '@ember/component';
 
 export default class SendMessageComponent extends Component {
@@ -558,7 +558,7 @@ messaging service.
 
 ```gjs {data-filename=app/components/send-message.gjs}
 import Component from '@glimmer/component';
-import ButtonWithConfirmation from './button-with-confirmation.gjs';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
 import { Input } from '@ember/component';
 import { service } from '@ember/service';
 
@@ -643,7 +643,7 @@ only the user's account `id` string.
 ```gjs {data-filename=app/components/system-preferences-editor.gjs}
 import Component from '@glimmer/component';
 import { fn } from '@ember/helper';
-import UserProfile from './user-profile.gjs';
+import UserProfile from 'my-app/components/user-profile';
 
 export default class SystemPreferencesEditorComponent extends Component {
   // ...
@@ -679,7 +679,7 @@ the parent `system-preferences-editor.gjs` and pass the local `deleteUser` actio
 import Component from '@glimmer/component';
 import { service } from '@ember/service';
 import { fn } from '@ember/helper';
-import UserProfile from './user-profile.gjs';
+import UserProfile from 'my-app/components/user-profile';
 
 export default class SystemPreferencesEditorComponent extends Component {
   @service login;
@@ -706,7 +706,7 @@ In our `UserProfile` component we change our action to call
 ```gjs {data-filename=app/components/user-profile.gjs}
 import Component from '@glimmer/component';
 import { service } from '@ember/service';
-import ButtonWithConfirmation from './button-with-confirmation.gjs';
+import ButtonWithConfirmation from 'my-app/components/button-with-confirmation';
 
 export default class UserProfileComponent extends Component {
   // ...
diff --git a/guides/release/in-depth-topics/patterns-for-components.md b/guides/release/in-depth-topics/patterns-for-components.md
index 7fa29a4b98..31c2db9668 100644
--- a/guides/release/in-depth-topics/patterns-for-components.md
+++ b/guides/release/in-depth-topics/patterns-for-components.md
@@ -37,7 +37,7 @@ export default class TooltipComponent extends Component {
 Now when called like so:
 
 ```gjs
-import Tooltip from '../components/tooltip.gjs';
+import Tooltip from 'my-app/components/tooltip';
 
 <template>
   <Tooltip @content="I'm a tooltip!"/>
@@ -128,7 +128,7 @@ 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.
 
 ```gjs
-import MyInput from '../components/my-input.gjs';
+import MyInput from 'my-app/components/my-input';
 
 <template>
   <MyInput @input-label="Password" aria-describedby="text-help-0 text-help-1" />
@@ -161,8 +161,8 @@ displaying different kinds of posts.  First, define your two components:
 Then, you can choose which to render based on the data:
 
 ```gjs {data-filename=app/templates/index.gjs}
-import RootPost from '../components/root-post.gjs';
-import ReplyPost from '../components/reply-post.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) {
@@ -182,8 +182,8 @@ function getPostComponent(postType) {
 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 '../components/root-post.gjs';
-import ReplyPost from '../components/reply-post.gjs';
+import RootPost from 'my-app/components/root-post';
+import ReplyPost from 'my-app/components/reply-post';
 
 const eq = (a, b) => a === b;
 
@@ -217,9 +217,9 @@ The first parameter of the helper is a component to render. So `{{component Blog
 The `component` helper is often used when yielding components to blocks. For example the layout for a SuperForm component might be implemented as:
 
 ```gjs {data-filename=app/components/super-form.gjs}
-import SuperInput from './super-input.gjs';
-import SuperTextarea from './super-input.gjs';
-import SuperSubmit from './super-input.gjs';
+import SuperInput from 'my-app/components/super-input';
+import SuperTextarea from 'my-app/components/super-textarea';
+import SuperSubmit from 'my-app/components/super-submit';
 
 <template>
   <form>
@@ -235,7 +235,7 @@ import SuperSubmit from './super-input.gjs';
 And be used as:
 
 ```gjs {data-filename=app/templates/index.gjs}
-import SuperForm from '../components/super-form.gjs';
+import SuperForm from 'my-app/components/super-form';
 
 <template>
   <SuperForm @model={{this.post}} as |f|>
@@ -253,12 +253,12 @@ The `{{component}}` helper is a powerful tool for improving code modularity.
 We can even use helpers and modifiers in the same way. Let's extend the SuperForm component:
 
 ```gjs {data-filename=app/components/super-form.gjs}
-import SuperInput from './super-input.gjs';
-import SuperTextarea from './super-input.gjs';
-import SuperSubmit from './super-input.gjs';
-import superIsValid from '../helpers/super-is-valid.js';
-import superErrorFor from '../helpers/super-error-for.js';
-import superAutoResize from '../modifiers/super-auto-resize.js';
+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';
 
 <template>
   <form>
@@ -281,7 +281,7 @@ import superAutoResize from '../modifiers/super-auto-resize.js';
 And be used as:
 
 ```gjs {data-filename=app/templates/index.gjs}
-import SuperForm from '../components/super-form.gjs';
+import SuperForm from 'my-app/components/super-form';
 
 <template>
   <SuperForm @model={{this.post}} as |f|>

From dc2903a2c92c9957b7d686fe85a24f0c6b6ac340 Mon Sep 17 00:00:00 2001
From: Tommy Carter <tommyjr@gmail.com>
Date: Sun, 3 Aug 2025 00:31:06 -0500
Subject: [PATCH 8/9] spelling

---
 guides/release/in-depth-topics/patterns-for-actions.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guides/release/in-depth-topics/patterns-for-actions.md b/guides/release/in-depth-topics/patterns-for-actions.md
index c2a7461e13..81976a38d8 100644
--- a/guides/release/in-depth-topics/patterns-for-actions.md
+++ b/guides/release/in-depth-topics/patterns-for-actions.md
@@ -68,7 +68,7 @@ import { action } from '@ember/object';
   }
 ```
 
-These two are functionaly equivalent and are used interchangably throughout these guides.
+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:
 

From f54089710e3a8ab9a212e99367a1ae5d7a3e54b2 Mon Sep 17 00:00:00 2001
From: Tommy Carter <tommyjr@gmail.com>
Date: Tue, 5 Aug 2025 15:38:11 -0500
Subject: [PATCH 9/9] Added hash helper when used

---
 guides/release/in-depth-topics/patterns-for-components.md | 2 ++
 guides/release/in-depth-topics/rendering-values.md        | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/guides/release/in-depth-topics/patterns-for-components.md b/guides/release/in-depth-topics/patterns-for-components.md
index 31c2db9668..1942261fa1 100644
--- a/guides/release/in-depth-topics/patterns-for-components.md
+++ b/guides/release/in-depth-topics/patterns-for-components.md
@@ -217,6 +217,7 @@ The first parameter of the helper is a component to render. So `{{component Blog
 The `component` helper is often used when yielding components to blocks. 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';
@@ -253,6 +254,7 @@ The `{{component}}` helper is a powerful tool for improving code modularity.
 We can even use helpers and modifiers in the same way. Let's extend the SuperForm component:
 
 ```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';
diff --git a/guides/release/in-depth-topics/rendering-values.md b/guides/release/in-depth-topics/rendering-values.md
index 6bebe61b79..9f6f875aa3 100644
--- a/guides/release/in-depth-topics/rendering-values.md
+++ b/guides/release/in-depth-topics/rendering-values.md
@@ -53,6 +53,8 @@ For Helpers, there is a specific syntax that only helpers may reside in
 ```
 or nested in a sub-expression
 ```gjs
+import { hash } from '@ember/helper';
+
 <template>
   {{yield (hash key=(theHelper) key2=(theHelper with args)) }}
 </template>