Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-06-22

Channels

#re-frame
<
2021-06-22
>
rberger02:06:29

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}}}
...

rberger02:06:38

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?

thheller06:06:34

config looks fine. it is :modules, where each entry in that maps defines a module

superstructor09:06:20

That shouldn't happen @rberger. Do you have a minimal reproduction ?

rberger17:06:27

Let me see if I can reproduce it outside our relatively huge and not public webapp. Its consistently failing there of course :-)

superstructor21:06:01

Try 1.1.7 please. It fixes several bugs. @rberger

superstructor21:06:13

(1.1.7 of re-frame-10x)

rberger00:06:20

@superstructor FIXED in re-frame-10x new version 1.1.7!!! Yay Thanks!!!!

superstructor03:06:57

Welcome :thumbsup: Thanks for the report @rberger

ribelo19:06:02

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?

p-himik19:06:07

I would probably create a new effect handler, similar to :dispatch-debounce.

ribelo19:06:40

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

ribelo19:06:51

Am I thinking right?

p-himik20:06:57

No. You would create your own version of :http-xhrio that's based on that but has rate limiting added on top.

ribelo20:06:29

ah, I misread, now it's clear

ribelo20:06:57

thanks! I'll try it this way

👍 2
ribelo20:06:53

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. 🙃

🙂 4
emccue03:06:37

might sound dumb, but track the requests in your state

emccue03:06:18

and when each one finishes, see if its the last one to finish and then fire off the http request if so

emccue03:06:18

(defn maybe-send-e [db]
  (if (= #{:a :b :c :d}
         (:process-state db))
    {:db db
     :fx [[:http-xhrio ...]]}
    {:db db
     :fx []}))

(rf/reg-event-fx
  ::start
  (fn [{:keys [db]} _]
    {:fx [[:http-xhrio [:on-success [::got-a]]
          [:http-xhrio [:on-success [::got-b]]
          [:http-xhrio [:on-success [::got-c]]
          [:http-xhrio [:on-success [::got-d]]]}))

(rf/reg-event-fx
  ::got-a
  (fn [{:keys [db]} [_ a]
    (-> db
        (update :process-state conj :a)
        (assoc :somewhere a)
        (maybe-send-e))))

emccue03:06:37

and then make sure to also handle on-failures

emccue03:06:40

that would be the explicit way if the requests had some data dependency

emccue03:06:53

it sounds like your main concern is rate limiting so that might miss the mark somewhat, but implementing your own effect handler is somewhat tedious so that would be the explicit way without making a new mechanism

p-himik09:06:54

> 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.

ribelo18:06:31

@U3JH98J4R 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

rberger00:06:20

@superstructor FIXED in re-frame-10x new version 1.1.7!!! Yay Thanks!!!!