This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-08-05
Channels
- # admin-announcements (2)
- # beginners (20)
- # boot (13)
- # cider (36)
- # cljs-dev (11)
- # clojure (31)
- # clojure-berlin (3)
- # clojure-czech (2)
- # clojure-dev (2)
- # clojure-japan (9)
- # clojure-russia (16)
- # clojurebridge (3)
- # clojurescript (182)
- # cursive (8)
- # datascript (2)
- # datomic (35)
- # editors (33)
- # hoplon (18)
- # ldnclj (11)
- # off-topic (6)
- # re-frame (3)
- # reagent (39)
@micha: thanks for clarification about hoplon alpha4! @micha, @alandipert: what the great discussion! My use case for dynamic cells is that: say, I have very complex SPA, with many “screens” having lot of derived data. And I really don't want to keep all derived data in memory and recalculate it on source data change for every screen when user is only on one screen at the moment. I want to do it only for current screen, which has its own limited scope about what cells are used by it. Some cells are screen-specific, some are common for entire app, some for group of screens.
@ul: thanks for clarifying, sounds like what we want also
i think we just figured out how to make cells auto-GC!
@alandipert: do not tease! tell!
there will be a global weakmap of cell -> [sinks, sources]
that’s basically it
so now instead of cells storing sinks and sources independently, they all appear in the weakmap
from which cells disappear automatically when GC'd
there appear to be workable shims available, so it should still work with ie9+
an implication is it’s not possible to see the whole graph necessarily anymore
i suppose it might never have been, if you created disparate subgraphs
anyway because the weakmap isn’t enumerable a cell must be had in order to look into the map
well, the javelin graph was already global in the sense that cells are ordered globally for propagation
so in that way it was already smelly