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.
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.
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).
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.
is it acceptable to delay initial events until the next animation frame ?
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!
I would love to see a JWM use case !