would one more C computation triggered in such case?

Short answer: yes. Longer answer: this is about ordering ...

In a perfect world, all necessary A and B computation is done before C

But it is possible that A might be done, then C. Then B, then C again.

So, yes, it is possible that C might be done twice. But more importantly, it means that C might be recomputed with a "glitch" - A is updated, but B is not.

Of course, in the vast majority of cases this is simply not an issue. BUT if you have a C which depends on two dependent inputs, then you need to at least be aware of this.

I have a had a hard question for me to answer today: why it is wrong to dispatch inside a subscription? It feels wrong to me but why? Is it that wrong? I could not come up with an answer. The use case is pagination: the code to review subscribed to :page in app-db and it was triggering a network call with the new page. Then another part was subscribing (inside the same subscritpion) to the data in order to "wait" for the call to succeed

Has anyone here used re-frame+ReactNative? In production? How performant? Would you recommend it?

@mikethompson: so (continuing with C depending on A & B), what i was observing was more than just an ordering problem - (i don't understand the problem yet, but it behaved as if) C ran after A was updated, but the dependency on B was never observed - so when B later updated C was not re-run... making C explicitly deref B whatever the content of A fixes the problem

@richiardiandrea: yeah, something is wrong if you are dispatching inside of subscriptions because it means you want to "change the world" from within a subscription. Subscriptions facilitate the transfer of the state, they never try to change it. Only events change the world (their handlers actually). So, instead, figure out what event (button press, mouse click, websocket update, etc) is the trigger for this update. That's the change-the-world moment (event handler), not subscription which just simply transports state.

I need to trigger a dispatch when a subscription changes since the dispatch needs the changed value. Doing it in the let of a Form-2 isn’t an option since that only gets called once and at the time the value it nil. I’m currently doing it within the component’s fn with some checks to avoid multiple dispatches but obviously thats not ideal. Whats the best way of handling this?

@afhammad: take a look at https://github.com/Day8/re-frame/wiki/Subscribing-To-A-Database. You probably don’t want to be dispatching inside a subscription (see above for discussion about this)

The question you need to answer is “What is the source of change that is triggering me wanting to dispatch?”, and put your dispatch at that point. Subscriptions don’t change anything, they only reflect the state that already exists in app-db. So wherever app-db is being changed, that’s where your dispatch should go.

@danielcompton: hmm I see, in this particular case the source of change is the router, i guess I may need an intermediary “controller” to handle these dispatches so that my router doesn’t get messy

I’m not too familiar with using re-frame with a router so I can’t be too much help there, but that sounds about right.

Yeh it makes sense. I’ll read the wiki page first though. Thanks

@afhammad: in our app, we dispatch an event from the router, and then that event handler has this "controller" in the form of a multimethod. By default it just saves the current route in the db (to use it later) but for some routes it does additional updates in the db or dispatches other events

Thats helpful, thanks @nberger.

@mikethompson: thanks that was my instinct as well, thanks for confirming it...any performance issue I can point to?

what I percieved as a lack of reloading/refreshing on clicking the browser reload button was in fact something entirely different. I'm using boot for clojurescript development. I used (enable-console-print!) followed by (println "blah") statements. These fail to run on browser refresh/reload. Quite unexpected behaviour. Otherwise they run fine. Anyway, am now switching over to cljs-console which is better anyway.

Lesson learned: DONT have (enable-console-print) be in any tutorials anywhere anymore...

@fenton: i’ve never experienced that with lein, must be a boot thing?

@afhammad: i think so.

@fenton: I don't think this is specific to boot or leiningen. Also using enable-console-print! is just fine. I guess you removed it from a file that still had a println? (`enable-console-print!` is a per namespace thing)

@martinklepsch: no confirmed it with another programmer too... its just the reload/refresh of browser that causes the issue...other times it works ok.

if i reload browser, nothing prints, if i update the file, it all prints just fine.

@fenton: should this namespace trigger the bug? https://github.com/martinklepsch/println-bug/blob/master/src/cljs/println_bug/app.cljs

that is not printing "test" when the page is reloaded?

hmm: boot dev gives me an error on going to localhost:3000 Uncaught TypeError: Cannot read property 'appendChild' of null

hm, that works for me. Did you check the output of boot dev for warnings/other issues? (maybe you're serving something else on 3000?

@martinklepsch: coming now...

@martinklepsch: okay leave with me for now, I'll try to find what part of my project is causing this.

@fenton: is this still the appendChild error?

no error is gone when i re-ran boot dev

ah ok, great

so you see "test"?

yes

even on reload

I had the same problem in btw

@martinklepsch: created a pull request that demos the bug...basically move println into init function and add cljs-repl functionality

@fenton: thanks, repro case always helps a lot.