Fork me on GitHub

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?


Thanks, this is fun!

Dustin Getz17:06:54

missionary object lifecycle is m/observe, you can weave it in at any point

Dustin Getz17:06:32

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

👍 2
Dustin Getz17:06:48

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

👍 1
Dustin Getz12:06:37

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)

Dustin Getz12:06:12

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.

🙂 1

Haha! I made button text change on click. 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 with nicer code and implemented the first two "challenges". Cool stuff.