Coming soon ! the next release will deprecate reactor signal! stream! and provide sharing operators for tasks, discrete and continuous flows that won't require a reactor context, disposed based on reference counting. More details here https://github.com/leonoel/missionary/issues/70

Hey @U053XQP4S thanks! I have seen that discussion but wondered if there is a current workaround of some sort 🙂 its great to know its coming though 🎉

currently there's no equivalent, you can share signals and streams with the constraint of staying in the same reactor context

Okay, good to know. Thanks. I do have a (rather weird) workaround for now and I guess I’ll have to leave it at that until the reactor context is gone 🙂

are you interested in beta-testing this feature ? it's close to done, I can push it on a branch

I could try to integrate it into this usecase but i’m not sure how valuable feedback I can give given that I’m only dabbling on a mini-sideproject in my freetime

why is the reactor context requirement a problem for you @U6JS7B99S?

@U09K620SG I would have liked to use a flow a bit like an event emitter where anyone getting the hands on the flow can start listening to values flowing through

Its surely possible that my understanding of flows in missionary is not good enough yet and I have overseen something crucial

I think your app likely can be refactored to meet the reactor requirement

I “kind of” did. I am trying to create an adopted version of potok with missionary. It works within itself through a reactor but I would have liked to make the global state a flow-alike as well such that a store-external handler can listen in and react to state updates by pushing in new events. For now I can get by fine with not exposing the flow at all and allow the “listen in” only through watch events which works fine as the watch happens within the reactor. It works fine for now, I was more wondering if there could be a way in the current state to make the main state a shared flow as well.