Describe changes to guides for components w/behavior

Author: chriskrycho

text/0000-template-imports.md

@@ -496,15 +496,23 @@ Once this is implemented and tooling is sufficiently stable, we will update the
 - Update the introductory examples, which start with pure HTML, to add a wrapping `<template>` tag, and update the prose to describe that `<template>` marks this as Ember/Glimmer’s special superset of HTML. Note that all you need to do to have a working Ember component is to wrap your HTML in `<template>`.
 
 - Introducing components will see the most changes, unsurprisingly:
-	- Note that we have already seen components in practice, because the templates we used with our routes were also components.
+    - Note that we have already seen components in practice, because the templates we used with our routes were also components.
 
-	- While we *conventionally* use `<CapitalizedComponents />` (and historically *had* to because that was the decision for how the resolver would work), that’s no longer a hard constraint. If someone does `const foo = <template>...</template>`, they will be able to invoke that as `<foo />` elsewhere. The notes in this section as well as about `LinkTo` will need to be updated to describe this as a helpful convention.
+    - While we *conventionally* use `<CapitalizedComponents />` (and historically *had* to because that was the decision for how the resolver would work), that’s no longer a hard constraint. If someone does `const foo = <template>...</template>`, they will be able to invoke that as `<foo />` elsewhere. The notes in this section as well as about `LinkTo` will need to be updated to describe this as a helpful convention.
 
-	- After introducing `<Jumbo />` with updated use of a wrapping `<template>`, discuss *importing it* into the route (component) template which uses it. This is a good place to describe how `.gjs` can use JS features, and hint that we’ll see more of this later; it is also a good opportunity to note that we *could* have defined `<Jumbo />` locally, but that we moved it to a separate file because we’re sharing it across multiple different components.
+    - After introducing `<Jumbo />` with updated use of a wrapping `<template>`, discuss *importing it* into the route (component) template which uses it. This is a good place to describe how `.gjs` can use JS features, and hint that we’ll see more of this later; it is also a good opportunity to note that we *could* have defined `<Jumbo />` locally, but that we moved it to a separate file because we’re sharing it across multiple different components.
 
-	- Our discussion of the testing will need to be updated to include importing the components under test, and to use `<template>` rather than `hbs` strings for the `render` calls.[^testing-rfc]
+    - Our discussion of the testing will need to be updated to include importing the components under test, and to use `<template>` rather than `hbs` strings for the `render` calls.[^testing-rfc]
 
-	- We can simply *remove* the discussion of namespaced components, in favor of simply describing the use of normal JS imports to accomplish the same goal. However, here we can also note that JavaScript modules are a great way to organize groups of related components, and show how we might use namespace-style imports (`import * as Rental from '';` and then `<Rental.Image />` within a `<template>`) for this kind of organization.[^namespace-deprecation]
+    - We can simply *remove* the discussion of namespaced components, in favor of simply describing the use of normal JS imports to accomplish the same goal. However, here we can also note that JavaScript modules are a great way to organize groups of related components, and show how we might use namespace-style imports (`import * as Rental from '';` and then `<Rental.Image />` within a `<template>`) for this kind of organization.[^namespace-deprecation]
+
+- The discussion of adding behavior to components will need to be updated as follows:
+
+    1. Show that when we generate a class for an existing component, it  adds the `Component` import, creates a wrapping class, and moves the template into the body of that class. Here, teach the mental model that a `<template>` which is part of a class body has access to the instance properties on the backing class.
+
+    2. When discussing use of values from `ENV`, instead of providing a getter on a backing class, start by creating a `TOKEN` constant in module scope, and show that it is available to access in the template. In the following section, which shows args being used in the template, simply use that `TOKEN` value in the template directly, `access_token={{TOKEN}}`.
+
+    3. When refactoring to use a getter for `src`, use the value as `${TOKEN}`. Note explicitly how there is a symmetry between JS and templates: you can use whichever approach is clearer for a given context.
 
 <!-- TODO: the rest of the pedagogy updates -->