Application data flow/general questions

[justinwoo]

Oops, looks like there was a comment on the gist version that I didn't see...

Originally posted by @emmenko here: https://gist.github.com/justinwoo/08f9f8fcdcf865025f18#comment-1450079

---

Hi, interesting article. I've read about RxJS before but never got the time to use them (so my knowledge is a bit limited).

I have a couple of questions at this time:

• with the Dispatcher you can easily track what is flowing through your application because everything goes through the Dispatcher. How does it work with Rx?
• afaics Intents are like Actions and Models are like Stores and you basically subscribe directly the action into the store. So if multiple stores want to listen to the same action, can you subscribe it multiple times?
• in your example with multiple models, you aggregated them at the root level and pass them down the components via props, so when something changes the entire app re-renders. If I just want one component to subscribe to changes, I guess I just have to do it like in Flux and call setState, right?
  one app store
• I really would like to see an example that does some data fetching (which is at the end what you are going to do in your application)
• how about testing? Is it going to be easy or painful? And if so do you have any experience or tipps to share?

Thanks :)

PS: I will definitely give it a try! 👍

[justinwoo]

For logging all the intents that have been triggered in the application, the simplest thing I've done is to create a utility function that goes through the subjects object to subscribe to them (JSBin is down for me right now, I thought I had it up on JSBin).

Yeah, for any stream, you can attach however many observers you want, and it will return a subscription. Once you don't need it, you can always call subscription.dispose

If you want to have a single component subscribe to a stream, then yeah, you can attach an observer that calls setState. But I think if that stream is generated in the models, then you should just let it pass down. I usually have a few elements as pure rendering components, so shallow equality checks work out, and then you can debounce/throttle streams if you need to. I find some things are just very laggy though, no matter what I do (like window resizing in Chrome is always like 10fps for me, like on this webpage now, so I've given up on trying to make that work). I'm kind of hacky about how I use React since I really just want to use the DOM output though, here's how I'm creating and consuming streams to just trigger lifecycle events: https://github.com/justinwoo/godforsaken-dynamic-width-scroll-table/blob/master/lib/godforsaken-dynamic-width-scroll-table.js

Admittedly, my apps don't have very much data so I almost always just call methods on my model directly to set my application state. I don't think it's so great to conflate user intents and ajax requests though, but people have their own preferences.

I'm very lazy so my testing is usually at the function level to verify that functions that I have for working off of the app state to produce a new one produce the correct output, but I don't test my whole system other than having it go through browser testing. You could very easily test the streams by attaching observers with assertions if you wanted though.