any suggestions on implementing typeahead? I have used typeahead.js in non-reactjs based projects. Checking to see if there is an "idomatic" solution

Sometimes, with in lein figwheel REPL, I do (require '[re-frame.core :as r]) (r/subscribe [:my-sub]) and that subscribe returns nil, instead of a reaction. Then some time later the problem goes away. Any idea what causes this? (The REPL is connected to the browser, since (js/console.log "hello world") does print to the browser console.)

Ah, I think I know: multiple figwheels on same port…

I have to make two calls to the server from my re-frame app. First one gets a token that I have to use in the next call. Here's what I'm doing. Step 1: Send GET "/token" to server. Step 2: Process the response in a handler like so, #(dispatch [:save-token]). This should save the token in the app-db Step 3: SEND POST "/something" to server using the token that was just saved in the app-db by suscribing to it. All this works fine but because dispatch in step 2 is asynchronous, there's a chance that by the time I call the POST, the token has not been saved in the app-db. What's the best practice to handle this?

@edwthomas: Can you elaborate on how step 3 is triggered? A view fires a POST when its subscription to the token in app-db activates?

(Sorry, I completely edited my previous comment because I realized I didn't understand step 3 as much.)

(The way I do this is put the POST inside the :save-token handler.)

@fasiha: No worries. The view does not know anything about tokens. At least that’s how I want it. All the view wants is to POST some info to the server but the server expects each POST to include a unique token. Moving the POST inside the :save-token handler will work. I was just wondering if there was an accepted way of handling this use case. I thought it would be cleaner to keep the logic of getting a token separate from the actual POST.

@fasiha: but your solution will definitely work. in fact, the more I think of it, it might be the way to go. nothing architecturally wrong with that approach.

Would it be correct to say the view dispatches a handler that sends the POST in your case? (In my mind, a POST is sent in response to some user event, e.g., a button click—so that button's onClick would dispatch a handler which then does the POST. If that's the case, one can easily imagine that the server hasn't yet responded with the token by the time the user clicks the button [or whatever triggers the POST].)

(In which case, that is an interesting and tricky question)

(The most braindead thing would be the handler that wants to POST checks app-db to ensure it has a token, and if it didn't, to do nothing. Maybe set a flag in app-db that eventually becomes a "couldn't submit to server" flash)

(More complicated would be something where, the handler wanting to post but finding no token can put whatever it wants to POST in app-db (possibly even a function). Then in the handler that receives the token and puts it in app-db would check to see if there were any POSTs queued up while waiting for the token and execute them then.)

Correct. The view dispatches a handler that sends the POST. The complicated solution you listed might be a bit overkill for this purpose. I might just follow your original suggestion for now and see how that looks 🙂

Maybe others have ideas on what to do if right now a handler needs a value in app-db that may or may not have arrived.

@edwthomas: we have two approaches in our app - one is to stay away from the app-db until the results of both network ops have arrived, the other is to trigger the second network op in the handler which saves the result of the first

@mccraigmccraig: thanks. the second was what @fasiha suggested. definitely seems like the simplest way to go about it.

@mccraigmccraig: what if the second network op is triggered by a user, which might come in before the first network op returns? Maybe I'm needlessly worrying about this—I'm recognizing that this might happen in my apps. No way around needing more coordination in that case right 😕

@fasiha: i'm pragmatic - that's why we have two solutions in our app, for different circumstances 🙂 - in that particular case i've used a core.async solution in the past, where you can specify that a request is a singleton and that first or last requests win out (i.e. if first-request wins out it doesn't make the later request, and if last-request wins out it drops the earlier request)

although i'm in the middle of a solution atm which is making all our networking activity explicit in app-db, and that includes singleton request support too

@fasiha: type-ahead searches are particularly bad for the out-of-order response problem you are describing... a 1 char search often has many more results than a 2 char search, so the 2-char results can arrive before the 1-char results and the 1-char results then replace the 2-char results unless you have taken care