missionary

euccastro 2026-04-30T12:34:49.684079Z

If you wrap with m/observe something single-threaded that emits more than one value before m/observe returns (e.g., a window that emits a creation event and a resize event), we deadlock, since any consumer of the flow hasn't had a chance to consume the first one yet. What would be the idiomatic/recommended way to work around this? Or should I just not use m/observe in this case? After initialization, it is desired that consumers do backpressure the producer (window), with no buffering in between.

leonoel 2026-05-01T11:31:47.762859Z

I'm facing a cruel dilemma on this issue. Intuitively your first attempt should work, but the only way would be to allow m/observe to buffer arbitrarily many values. It would be strictly more powerful but also more dangerous.

euccastro 2026-05-01T14:29:18.928069Z

Yes, I explicitly wanted no buffering in m/observe. I'm playing with missionary & HumbleUI, just to learn about both. So far I have a basic event -> state -> view -> render pipeline working (and some component work which I excluded from this demo because it's not using missionary yet).

🧐 1
euccastro 2026-05-01T14:46:00.087649Z

I kind of like the single-state-atom approach because of REPL ergonomics, although I realize that managing the view tree as a signal DAG would be more illuminating to learn missionary. Maybe I could combine both with view components being signals derived from partial subscriptions (cursors?) to the atom. I guess I'll try that when the current approach starts causing performance issues.

leonoel 2026-04-30T14:56:32.123159Z

is it acceptable to delay initial events until the next animation frame ?

euccastro 2026-04-30T16:13:02.297899Z

I thought I could not do that with the library I'm using (JWM), but I figured that the events were actually coming from the call that makes the window visible, which is distinct from creation, and it can indeed be delayed. Thank you!

leonoel 2026-04-30T16:50:45.880439Z

I would love to see a JWM use case !