Clojurians Log v2

@pedroteixeira If you get blocked, it means you didn’t call a callback on ok or error. Requests are serialized by default and the next one doesn’t go until the first is done.

@bbktsk I’ll take a look when I get some time.

@tony.kay Thanks, I appreciate it.

@bbktsk Yeah, that is a crappy API you’re using…I assume the names are guaranteed unique, or there is no solution. I agree with your solution to this case: use the app state, which you can get from the app that you can save when you mount (in an atom). The networking start is passed the app, so you could also close over it there in an atom.

you’ve already noticed that the built-in implementation implies that it keeps app around for you, which is incorrect

@tony.kay Thanks, will do that. Also, related question: what about situations when send needs to add some authorization headers (based on data in the app state) to every request to the server? Since send receives the query only, I can either include auth as a parameter to every remote query or do the same thing as above, save the app state somewhere? I see that the cookbook has a section about this, but so far there’s only the title.

@tony.kay hey Tony, did you had the chance to make the update on spec version? I'm trying to bump my deps but seems like we still stuck with the old clojure.spec thing, I can make a PR updating it in case you didn't started that yet

Me again 8( Got a problem with my mutation that loads additional data from remote server. The mutation uses df/load-action and when I run it for the first time, it works. However, when executed second time on a different instance of the same class, I get Uncaught Error: Index out of bounds, coming from http://om.next.Reconciler.om$next$protocols$IReconciler$reconcile_BANG_$arity$2 (next.cljc?rel=1497706647138:2534) . I tried a couple of different approaches (e.g. load-field-action), but it’s still the same. I guess that the first mutation breaks something somehow, but I have no idea what. The only clue I have is that before I run it for the first time, the :om.next/tables key in the app state contains names of my tables. After I run it, it’s just an empty set. Apart from this and the change done by the mutation, the app state before and after is exactly the same. I know this is pretty useless description of the problem, I’m just hoping that “empty om.next/tables” will ring a bell to somene…

Hmmm. That’s odd. It seems to be working now, after I switched to df/read-field-action again, out of pure desperation. I’ll try to put together a minimal example, to find out what I was doing wrong.