This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-19
Channels
- # babashka (2)
- # babashka-sci-dev (15)
- # beginners (44)
- # clara (6)
- # clj-kondo (5)
- # clojure (39)
- # clojure-europe (5)
- # clojurescript (14)
- # data-science (5)
- # datahike (6)
- # datalevin (7)
- # graalvm (2)
- # helix (3)
- # humbleui (8)
- # minecraft (1)
- # missionary (10)
- # nbb (8)
- # nrepl (2)
- # portal (11)
- # shadow-cljs (3)
- # tools-deps (6)
- # xtdb (10)
Woo hoo! I just wanted to share my first program with missionary. This is pretty cool and I'm excited to build on this. I'm also interested in any feedback. e.g. If I don't dispose the reactor, does it leak? If I replace the dom node, does it get garbage collected because there are no references? Is there some kind of onUnMount that I can hook into in order to call dispose when the node gets dropped from the dom? (I guess that's not a question for missionary) Also, is it actually beneficial to update at the granularity of a single attribute? I don't have a use case that could answer this by telling me what I actually need to accomplish; I'm just playing around. Is it "wrong" to create a reactor for a single attribute?
missionary object lifecycle is m/observe, you can weave it in at any point
you want a single global reactor. Think of m/signal! as allocating a shared node in a DAG and the reactor as a shared memory heap for the DAG state so nodes can be shared in efficient dataflow diamond structures. Booting a reactor returns a disposal callback. IIUC (from quick skim) what you're doing here is not benefitting from the reactor/signal – you're basically running flows for side effect, which you can do by invoking the flows directly like I did on line 10 of my snippet
The big idea here is you want to express your reactive view as a DAG, and then keep the DAG running to perform incremental point effects to the DOM as the DAG reflows in response to any input events (like atom updates, user interactions, dom events). To bridge a foreign input event into the DAG use m/observe. When the DAG is eventually disposed, a cancellation signal will propogate through the supervision tree and the m/observe destructor callback will be invoked, cleaning up the atom registration
m/observe is also the mechanism to wrap each dom element. Instead of subscribing to an atom, create and mount the dom element, and unmount in the cancellation handler. Thousands of m/observe calls is fine. Any object/resource that requires disposal (supervised object lifecycle) should be wrapped in observe. Photon-dom is syntax around approximately this pattern (i believe we are doing something fancier now but it started that way)
I edited the m/observe gist above to explicitly name the constructor/mount and destructor/unmount
Thank you for the comments, they have been extremely helpful. Sorry for leaving you hanging; I was hoping that I'd have some new and improved code to share but I'm still working on it.
Haha! I made button text change on click. https://gist.github.com/rgkirch/ece8292e103c9a75c7ce0110253ea56d Can I test if a value is a flow?
Never mind, I don't need to test if a value is a flow. I updated the https://gist.github.com/rgkirch/ece8292e103c9a75c7ce0110253ea56d with nicer code and implemented the first two https://eugenkiss.github.io/7guis/tasks/ "challenges". Cool stuff.