Finish up How We Teach This: Guides: Core Concepts

text/0000-template-imports.md

@@ -632,7 +632,7 @@ 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.
 
@@ -677,16 +677,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