[nested-v-grid] Add cache-eviction test

Author: kimo-k

src/re_com/nested_v_grid/util.cljc

@@ -140,7 +140,7 @@
                                (vswap! sum-size + leaf-size)
                                leaf-size))))]
     (walk [] header-tree {:hide? hide-root?})
-    (vswap! size-cache assoc :depth @depth)
+    (cache! :depth @depth)
     {:sum-size        (or cached-sum-size @sum-size)
      :spans           @spans
      :positions       @sums

test/re_com/nested_grid_test.cljs

@@ -1,7 +1,8 @@
 (ns re-com.nested-grid-test
   (:require
    [cljs.test :refer-macros [is are deftest]]
-   [re-com.nested-v-grid.util :as ngu]))
+   [re-com.nested-v-grid.util :as ngu]
+   [snitch.core :refer-macros [*let]]))
 
 (def main-keys [:header-paths :keypaths :sizes :sum-size :positions])
 
@@ -94,6 +95,8 @@
          Once calculated, walk-size keeps this total-size in a cache,
          keyed by the branch node's identity.
 
+         This cache of total-sizes is similar to a range tree.
+
          When a branch-node is cached, the traversal does not descend into it.
          One exception is when the branch-node's total-bounds intersect the window-bounds.
          In that case, a descent is needed - not to calculate sizes,
@@ -185,3 +188,68 @@
     [:a [:b [:d] :c]]                [:root [:a [:b [:d]] [:c]]]
     [:a [:b [:c [:d]]]]              [:root [:a [:b [:c [:d]]]]]
     [:a [:b [:c [:d]] [:e [:f]] :g]] [:root [:a [:b [:c [:d]] [:e [:f]]] [:g]]]))
+
+(deftest cache-eviction
+  (let [a {:id :a :size 10}
+        b {:id :b :size 10}
+        new-b {:id :b :size 11}
+        c {:id :c :size 10}
+        parent      [a]
+        old-subtree [b c]
+        new-subtree [new-b c]
+        old-tree   (conj parent old-subtree)
+        new-tree   (conj parent new-subtree)
+        size-cache (volatile! {})
+        {:keys [keypaths header-paths]} (ngu/window {:header-tree old-tree
+                                                     :size-cache  size-cache})]
+    (is (= [{:id :a} {:id :b} {:id :c}] (nth header-paths 2)))
+    (is (= [1 1] (nth keypaths 2)))
+    (is (contains? @size-cache old-subtree))
+    (ngu/window {:header-tree new-tree
+                 :size-cache  size-cache})
+    (is (and (contains? @size-cache old-subtree)
+             (contains? @size-cache old-tree)
+             (contains? @size-cache new-subtree)
+             (contains? @size-cache new-tree))
+        "From a CS perspective, the size-cache works like a segment tree.
+       An internal node's interval is the union of the intervals of its
+       children (wikipedia). Changing any node means changing all of its
+       parent nodes.
+
+       More concretely, if any node of a header-tree changes identity,
+       that node, and all its ancestors, will then miss the cache.
+       That's because nodes contain their children, similar to hiccups.
+       It is necessary to invalidate them in the cache,
+       since all their sizes must be recalculated.
+
+       This scheme of implicit cache-invalidation is how `nested-grid`
+       can handle reactive updates to the header-tree without doing expensive
+       searches or complex state management. The user can simply pass in
+       a new header-tree, and `nested-grid` implicitly \"knows\" which
+       nodes have changed.
+
+       However, after an update, the old identities of that node and its ancestors
+       remain in the cache, unless we remove them.
+       Stale identities accumulate, especially when resizing,
+       where these identities change on every render.
+       This behaves like a memory leak.
+
+       `nested-grid` can't afford to check for stale values
+       by searching or diffing the whole tree
+       (if it could, then we wouldn't need virtualization).
+       That means that whatever actor is responsible for updating the header-tree
+       must also manage these stale cache values.")
+
+    (vswap! size-cache ngu/evict! old-tree [1 1])
+
+    (is (and (not (contains? @size-cache old-subtree))
+             (not (contains? @size-cache old-tree))
+             (contains? @size-cache new-subtree)
+             (contains? @size-cache new-tree))
+        "`re-com.nested-grid.util` provides an `evict!` function for this purpose.
+       When passed the cache, a tree and a keypath to a header-spec,
+       `evict!` removes that node, and all its ancestor nodes, from the cache.
+
+       Since `nested-grid` provides its own resize-buttons, it does this eviction
+       just before calling the `on-resize` handler. That means `nested-grid`'s built-in
+       resize behavior automatically prevents the \"memory leak\".")))