Fork me on GitHub

@thedavidmeister Hi. I've been trying to follow your progress on the keyed-for-tpl. I think I am having issues in this area and could use your feedback. I am doing a relatively simple todo list, using a vector of (item) maps to model the state. I want to filter and sort the list N different ways with a bunch of fiddly UI toggle buttons and dropdowns. I have modeled the state so far with a set of cascading formula cells like so.

(defc items [{item1 attrs} {item2 attrs} {item3 attrs}])
(defc= truthy-items
  (keep-boolean-true-items items))
(defc= filtered-items
  (keep-some-other-test truthy-items))
(defc= categorized-items 
  (test-items-for-category filtered-items))
(defc sorting-key foo)
(defc= sorted-items
  (sort-by sorting-key categorized-items))

(for-tpl [x sorted-items]
   (elem @x)
I cant help but think I am being massively inefficient. And indeed my list is now almost grinding to a halt, like when I try to change a category view (5-10s pause, almost unusable on phone)


Is this generating new iterations of the list in memory for every possible state combination of the upstream cells?


Also, I implemented some functions to shift the position of items around in the base state vector. And this is really slow. I think your keyed-tpl might help me greatly. But I wonder if there's a more general pattern to model this kind of UI state change that i'm missing?