I am playing with v3 dir_tree tutorial, modify the example, and hit performance issue. I added a button to collapse and expand a directory, the response time seems like linear to the number of children. 100 children ~ 1000ms here is the minimal case
(e/defn Children []
(dom/ul
(e/for [i (e/diff-by identity (range 100))]
(dom/div
(dom/span (dom/text i))))))
(e/defn Dir []
(let [!expand? (atom false) expand? (e/watch !expand?)]
(dom/div
(dom/button
(dom/On "click" #(swap! !expand? not) nil)
(dom/text (if expand? "collapse" "expand")))
(when expand?
(dom/div
(dom/props {:class "ml-2"})
(Children))))))it is of course linear because you are asking the computation to add or remove N children on click
the real problem is that 10ms per new child is too slow, it is supposed to be faster, we're looking into it. Our virtual scroll demos (e.g. Explorer) currently have an optimization to conserve DOM nodes, the collection size is fixed to the viewport size. We don't think it should be necessary to optimize, we will be investing more here shortly
I will say as a design goal we are very focused on handling very large enterprise collections (e.g. N=500-50k) which have mandatory virtual scroll, so while it would be nice if the sub-500 use case was fast enough without virtual scroll, it is not a hard requirement, as they can just be lifted into the same virtual scroll pattern too