Finish up How We Teach This: Guides: Core Concepts

Author: chriskrycho

text/0000-template-imports.md

@@ -632,18 +632,13 @@ Once `<template>` is implemented and tooling is sufficiently stable, we will upd
 
 #### Core Concepts: Components
 
-This entire section will also need to be substantially reworked. Once again, I am here summarizing the changes rather than trying to rewrite the guide in place. Each section represents a page to be changed; if a section is not mentioned, it needs few or no changes.
+This entire section will also need to be substantially reworked. Once again, I am here summarizing the changes rather than trying to rewrite the guide in place. Each section represents a page to be changed; if a section is not mentioned, it needs no substantive changes—likely only switching over to using the `<template>` wrapper.
 
 At some point in the course of this discussion, we should call out (e.g. with a “Zoey says” block) that users should treat `<template>` the same way they treat a costly function which produces a result for the life of the whole app, and should therefore avoidng using `<template>` in function bodies rather than hoisting them, etc. This cannot be a hard and fast rule about where `<template>` definitions live, because there are plenty of ways to do it safely, and what’s more we *need* to do it in test modules.
 
 The point is simply to align people’s mental model for `<template>` with *other* costly operations, since these concerns are not specific to component creation.
 
 
-##### Templates are HTML
-
-The point of this will remain the same—modulo changes for route templates; presumably we will have a top-level `<template>`, but do not need to explain that it is a component until the next page. We'll be using `.gjs` instead of `.hbs`.
-
-
 ##### Introducing Components
 
 Unsurprisingly, this is the section which will see the most sweeping changes.
@@ -677,16 +672,9 @@ First, the motivation for introducing a backing class shifts slightly: we have t
 Second, having made the motivation clear, we can show the `<template>` in the body of the class and explain that it is exactly the same as a standalone template component, except that it now has access to the backing class for local state, "actions", etc.
 
 
-##### Looping Through Lists
-
-This section will just need to update each of the component examples it provides to use the new syntax with a wrapper `<template>`, and in the case where the component is class-backed, move it into the backing class body.
-
-
 ##### Template Lifecycle, DOM, and Modifiers
 
-Once again, many of the changes here will be mechanical: just using the new syntax. However, this also provides another opportunity to discuss (and demonstrate) the value of local-only vs. exported functionality. Both of the main custom modifier examples here currently show highly-reusable examples of modifiers which *should* be exported and should indeed probably live in their own modules. Accordingly, we might find an example which shows the value of having a locally-scoped modifier—e.g. something which manages the details of an `iframe`.
-
-<!-- TODO: the rest of the Core Concepts updates -->
+Once again, many of the changes here will be mechanical: just using the new syntax. However, this also provides another opportunity to discuss (and demonstrate) the value of local-only vs. exported functionality. Both of the main custom modifier examples here currently show highly-reusable examples of modifiers which *should* be exported and should indeed probably live in their own modules. Accordingly, we might find an example which shows the value of having a locally-scoped modifier—e.g. something which manages the private details of an `iframe`.
 
 
 ### API Docs