Clojurians Log v2
re-frame
The re-frame-10x UI freezes when I reload the browser page, I don’t remember it doing it before upgrading to the latest versions of re-frame (1.2.0) and re-frame10x (1.1.4), though its possible its due to some other issue…
If I clear out the reframe-10x items in LocalStorage, it creates a new 10x UI. But I wonder what I might be doing wrong that this behavior is happening.
Using shadow-cljs 2.14.5. I don’t have a literal main but I do have:
:builds {:app {:target :browser
:output-dir "resources/public/js/compiled"
:asset-path "/js/compiled"
:modules {:app {:init-fn visx.dashboard.core/init}}
:devtools {:http-root "resources/public"
:http-port 8280
:preloads [day8.re-frame-10x.preload]}
:dev
{:compiler-options
{:closure-defines
{re-frame.trace.trace-enabled? true
day8.re-frame.tracing.trace-enabled? true}}}
...Not sure if it might be related to the shadow-cljs config. The instructions mentions module not modules or might there be something I need to put in the init code for some shadow-cljs lifecycle?
config looks fine. it is :modules, where each entry in that maps defines a module
That shouldn't happen @rberger. Do you have a minimal reproduction ?
Let me see if I can reproduce it outside our relatively huge and not public webapp. Its consistently failing there of course :-)
I need to send a few dozen requests to the server, but I would not like to do it at once, but divide it into packets
How can I e.g send e.g. 4 simultaneous requests and the next one only after all the previous ones have succeeded. How can I do this with re-frame-http-fx?
I tried using async-flow, but it seems overly complicated in this case and maybe there is a simpler way?
> implementing your own effect handler is somewhat tedious
Not at all, given that it will be a thin wrapper around :http-xhrio. You don't have to reimplement the whole wheel, just add a couple of atoms to track the queued requests and the in-flight requests, and that's it.
@emccue I have currently created a similar ugly creation to yours, but I don't like it at all. As I mentioned, I tried to simplify it by using async-flow, but it made things even more complicated. Rewriting http-xhrio in my own fashion seems cool and minimizes the amount of code I need to write, because it's only a few lines
I would probably create a new effect handler, similar to :dispatch-debounce.
Unfortunately, I can't quite picture it. After sending a request via :http-xhrio the next queued events are immediately processed, including the next :http-xhrio. I would have to throw calback to :on-success, or make some kind of counter and call the event in a loop until the counter is released
Am I thinking right?
No. You would create your own version of :http-xhrio that's based on that but has rate limiting added on top.
ah, I misread, now it's clear
thanks! I'll try it this way
In general, this is another time when 5 minutes don't pass between my question and your answer. On the re-frame and reagent channel you are a one man army serially solving other people's problems. Appreciation. 🙃
Try 1.1.7 please. It fixes several bugs. @rberger
(1.1.7 of re-frame-10x)