Reflux.all() also needs Reflux.waitFor()? about refluxjs

[jessegrosjean]

One more bit of motivation…

This would also make writing tests easier. Right now it gets quite complex if I want to test the emitted value of the AggregateStore. In my test I'd like to do something like:

1. Add event listener to AggregateStore.
2. Perform Action
3. Validate results of AggregateStore emitted event

But this gets pretty tricky because depending on how many Store1, Store2, etc stores the action effects AggregateStore will emit a new event for each one. So the tests that I'm writing are getting complex and brittle… IE only check the third event emitted. With waitFor functionality I think this wouldn't be a problem because the AggregateStore would only emit once per action.

[spoike]

Thanks!

We have a couple of enhancements in the tracker that may be of use for you, but currently aren't implemented yet:

• There is the #29 that is about adding more strategies for joining the listeners.
• Another is the #52 that lets you also use streams together with baconjs and rxjs which would allow you to do this as well.

I'd like in the end refluxjs to support the different join strategies one way or another.

Here is a visual representation of different join patterns from bacon.js and if I read your request right I believe you're looking for the combine join, i.e. it will trigger on any change to either listener/stream.

I don't know when we will implement this, and I understand the need for it and hope for it to reach a release soon (wether or not I have time to implement it).

[spoike]

As a side note: Flux's Dispatcher.waitFor is a nice thing to have, however I really want this to be more composable which is why I'm eschewing that. Hence the use of Reflux.all that will "compose" a listenable that may be reused.

[jessegrosjean]

Been doing a lot of reading on FRP stuff which was all new to me. And yes I think Bacon style combine is what I want.

In particular with Bacon's atomic/glitch free updating. If I'm understanding things correctly I think my original example is already doing a "combine" manually with listeners. But in FRP terms that problem I'm describing is that it's not "atomic/glitch free". Anyway thanks for the lib and pointers.

[jessegrosjean]

#24 Got me reading more about FPR's.

What about using Bacon.js as the internal dispatch mechanism for reflux? The idea would be to keep the reflux API the same, so no one would need to learn Bacon. But have reflux do its internal dispatch with Bacon. I think that would solve my particular issue (since Bacon does atomic/glitch free propagation) and also make things like Reflux.all much easier to implement since you could just do a zip.

This might be to big of a dependency, or I might have no idea what I'm talking about… But I'd be curious to hear your thoughts. In general flux seems much inspired by FPRs… I'm wondering why the dispatcher doesn't use a "real" on internally.

[spoike]

As of right now, I won't add BaconJS. I'm not counting on anyone using BaconJS together with reflux so adding that dependency is a bit too much.

You could:

1. Switch the eventemitter3 (through Reflux.EventEmitter) with an EventEmitter-like object that uses BaconJS internally
2. Monkeypatch Reflux.all by doing BaconJS stuff instead

... or you could just fork reflux and replace the dispatch mechanism with baconjs and call it bacon-reflux. The name sounds nasty but I'd be endorsing it. ;-)

[jessegrosjean]

bacon-reflux … I think this must be destiny. My company name is "Hog Bay Software". I'll report back with any successes.

[jessegrosjean]

I've managed to get a basic system up and running. Ignoring the fact that it includes Bacon.js the implementation is very short and simple, but with lots of comparability of actions options and atomic glitch free event propagation.

With one problem… It works if I set everything up ahead of time. Ie each model calls listen to once. But I'm having a hard time figuring out how to modify the Bacon stream that I've constructed to take into consideration additional calls to listenTo, etc.

I've boiled down the problem to this description in the baconjs group:

https://groups.google.com/forum/#!topic/baconjs/W9kuhlV3YdU

If anyone has a suggestion on how to get around this then I can post a version of bacon-reflux.

[spoike]

Yes, I believe I am totally salivating over this briny project, soon cannot boar anymore!

So I tweeted and I hope the community will agree with this porky issue and help us piglets out.

[cocodrino]

@jessegrosjean did you check https://github.com/baconjs/bacon.js/#bacon-update ??

that allow a kind of mutability in your code, only need change 0 by an array, hitUfoMotherShip would be instead an Stream([function,"Add"]) or Stream([function,"remove"])...when that stream is applied your "score" (in your case your arrayFunctions) will change show the new state...so nice and clean

I'm pretty sure than this would be accomplished using only folding (baconjs is "scan") but would be necessary check the whole code and make a changes...
.

I recommend you ask directly to raimohanska here instead of ask in the google group..the google group has not so much activity and would need wait a couple of months for a first answer...

[cocodrino]

btw my answer is for your second example published in the google group...how add or remove elements from an stream...I just see a tweet and I really don't know much about reflux ...so I don't know what you wish achieve...

[jessegrosjean]

@spoike @cocodrino Thanks for your help. I got my bacon.js solution to the point where it was good enough to use in my app, but found in the end that the benefits were not worth the extra complication. Fun learning project! But harder to debug. I've just posted what I'm now using now:

https://groups.google.com/forum/#!topic/reactjs/wgRH1pYkpqk

It's a Reflux inspired wrapper around Facebook's standard dispatcher. It gets me the waitFor that I wanted but without having to use all those constants and switch statements. Thanks again for all of your help!

[dtinth]

I just implemented Reflux.waitFor() which is available in reflux-waitfor npm package. (It does not depend on Bacon.js.)

This way, the store will be listening to the action directly, instead of listening to other stores (like original Flux). Now, in your store’s action handler, it can ask Reflux that the action be delivered to some other store (synchronously) first:

  Reflux.listenTo(Store1)
  Reflux.listenTo(Store2)

This way, you can also keep your codebase closer to the the original Flux pattern.