post your code, we will help

this is on the electric ui layer which event hauling idioms aren’t very natural yet, we’re working on a better idiom, for now we have to teach you the tricks

this is a missionary issue, ap macroexpansion is not electric-friendly. The coroutine state is emitted as a mutable array and interpreted as electric code, the array does not depend on any reactive value so it's not reconstructed, the same state is incorrectly reused for all ap runs.

thanks, sounds like I can't accidentally trigger this behavior outside of this case

(y/reductions (fn [play? _] (when play? (sound/play ..)) (not play?)))

also, I don't understand the question. Are you asking if this is still functional if it's orchestrating side effects?

just thinking about how un-clojurey it feels. you think it's better to emit a boolean than to not emit?

the reductions I posted rids you of the eduction. One step less

clojure doesn't solve IO. Missionary does, in a functional way. y/reductions is a flow (a recipe to orchestrate IO) and flows compose correctly wrt IO

ah true, thanks. that makes it feel a lot better

I think this has to be the idiomatic way in electric

(let [typed (Typing. (:text ctx))
            idx (new (y/reductions (fn [acc _] (inc acc)) 0 typed))]
        (when (odd? idx) (sound/play sound/DialogueBoop :rate 0.65 :volume 0.6)))

you could stay in electric completely if you wish to

> not sure if there's a way to know when a flow has terminated generally You can run a clj fn when the flow is about to unmount with e/on-unmount

missionary flows can terminate, what is the requirement? discrete flows terminate a bit more natively than continuous flows though, bc signals broadly are defined for all time

well, that may not strictly be true because a child flow (continuous or discrete) can terminate and invoke cancellation effects as peter alluded, but then it can reboot. Cancellation on missionary propagates as an exception (causing siblings and parents to cancel per supervision)

i think continuous flows always cancel by exception? as opposed to discrete flows which can complete? possibly continuous flows can also complete its just weird and rare, more of an optimization to say “this signal is invariable and the current value is final”

observe self-termination is not possible now, but may be in the future if needed. As a workaround you can push a sentinel value and add an eduction stage with take-while.

The notifier/terminator are not called because you're calling the flow with new. This is electric specific, missionary is unaware of that

Passing notifier/terminator explicitly is expert mode, you should not do that unless you're learning internals

I figure electric supplies its own notifier/terminator to the flow with new, but I was hoping it would compose with your own instead of just overriding them

new when called on a missionary flow doesn’t propagate parameters like that

what new does under the hood is bind the arguments in dynamic scope as %0 %1 etc and then joins the flow. an e/fn compiles down to a flow that optionally reads from %0 etc.

if you want to manually wire notify and terminate you should invoke the flow as a function per the missionary api

if you want to escape from electric context to intercept notify/terminate at some point in the electric program- i actually don’t know how to do that, the idea confuses me actually

(flow n t) => iterator => flow => electric?