examples: add note about potential for memory leaks with nested signals (#1675)

examples/counters/src/lib.rs

@@ -88,9 +88,17 @@ fn Counter(
         set_value(event_target_value(&ev).parse::<i32>().unwrap_or_default())
     };
 
-    // just an example of how a cleanup function works
     // this will run when the scope is disposed, i.e., when this row is deleted
-    on_cleanup(|| log::debug!("deleted a row"));
+    // because the signal was created in the parent scope, it won't be disposed
+    // of until the parent scope is. but we no longer need it, so we'll dispose of
+    // it when this row is deleted, instead. if we don't dispose of it here,
+    // this memory will "leak," i.e., the signal will continue to exist until the
+    // parent component is removed. in the case of this component, where it's the
+    // root, that's the lifetime of the program.
+    on_cleanup(move || {
+        log::debug!("deleted a row");
+        value.dispose();
+    });
 
     view! {
         <li>

examples/counters_stable/src/lib.rs

@@ -91,6 +91,18 @@ fn Counter(
             .set(event_target_value(&ev).parse::<i32>().unwrap_or_default())
     };
 
+    // this will run when the scope is disposed, i.e., when this row is deleted
+    // because the signal was created in the parent scope, it won't be disposed
+    // of until the parent scope is. but we no longer need it, so we'll dispose of
+    // it when this row is deleted, instead. if we don't dispose of it here,
+    // this memory will "leak," i.e., the signal will continue to exist until the
+    // parent component is removed. in the case of this component, where it's the
+    // root, that's the lifetime of the program.
+    on_cleanup(move || {
+        log::debug!("deleted a row");
+        value.dispose();
+    });
+
     view! {
         <li>
             <button data-testid="decrement_count" on:click=move |_| set_value.update(move |value| *value -= 1)>"-1"</button>