Opps, hostile design

text/1060-tracked-promise.md

@@ -346,6 +346,7 @@ Doing so would allow more separation of loading / error UI, such as portaling lo
 
 #### creating reactive promises
 
+We can use `TrackedPromise` to turn not-async APIs into reactive + async behaviors -- for example, if we want to make a promise out of `setTimeout`, and cause an artificial delay / timer behavior:
 
 ```gjs
 import Component from '@glimmer/component';
@@ -354,38 +355,30 @@ import { TrackedPromise } from '@ember/reactive';
 
 export default class Demo extends Component {
   @cached
-  get state() {
+  get () {
     return new TrackedPromise((resolve => {
-
+       setTimeout(() => {
+        resolve();
+       }, 5_000 /* 5 seconds */);
     }));
-    let id = this.args.personId;
-    let fetchPromise = 
-      fetch(`https://swapi.tech/api/people/${id}`)
-        .then(response => response.json());
-
-    return trackPromise(fetchPromise);
   }
 
-  // Properties can be aliased like any other tracked data
-  get isLoading() {
-    return this.requestState.isPending;
+  get showSubscribeModal() {
+    return this.requestState.isResolved;
   }
 
   <template>
-    {{#if this.isLoading}}
-       ... loading ...
-    {{else if this.requestState.value}}
-       <pre>{{globalThis.JSON.stringify this.requsetState.value null 2}}</pre>
-    {{else if this.requestState.error}}
-       oh no!
-       <br>
-       {{this.requestState.error}}
-    {{/if}}
+     {{#if this.showSubscribeModal}}
+        <dialog open>
+          Subscribe now!
+
+          ...
+        </dialog>
+     {{/if}}
   </template>
 }
 ```
 
-
 ## Drawbacks
 
 I think not doing this has more drawbacks than doing it. A common problem we have is that we have too many packages and too many ways to do things. Our users long for "the ember way" to do things, and a comprehensive reactive library full of vibrant, shared utilities is one such way to bring back some of what folks are longing for.