There’s also re-frame-http-fetch or something like that

uses the fetch-api where cors is just a boolean away

I see I see!

The value of a sub is an arbitrary data. Before downloading it, you'd have to serialize it somehow.

And you can't write an algorithm that can serialize every possible JS value.

Okay, so in that sense the way about it is to put it as text into a div and copy that? o:

The "traces" tab allows you to: 1. Switch the output to show only subs 2. Filter those subs 3. Press the "Print" button to output the value to the browser's JS console

In the JS console, you can do whatever you want to it. To make it more comfortable, you can right click the printed value and press "Store object as global variable".

Goes well together with cljs-devtools and dirac.

Alas, the "subs" tab doesn't offer that "Print" button.

Created https://github.com/day8/re-frame-10x/issues/316

Not sure what I was doing wrong but couldn't use the print button in the traces tab. But it did however display out all the details for me to copy (unlike when I was looking at app-db tab where the last few values ended being left as ...

But thanks 🙂

Whoops right, it goes to the js console

If I understand you correctly, it was probably @U3JH98J4R

@U4YGF4NGM refresh my memory a bit?

I think i know what you are asking for, but i want to make sure before i go off

something about how you organize your events/effects, where instead of writing the effects in an event as data you use helper functions to construct the effects:

(rf/reg-event-fx
  ::something
  (fn [{:keys [db]} [_ foo bar]]
    (-> (do-thing {} foo)
        (do-another-thing bar)
        (do-one-last-thing))))

yeah so the first bit is every event handler is a reg-event-fx for consistency

and we only ever return :db and :fx

for :fx, we have namespaces dedicated to them that look basically like this

(rf/reg-fx
  ::alert
  (fn [contents]
    (js/alert contents)))

(defn alert [contents]
  [[::alert contents]])

(defn alert-uppercase [contents]
  (alert (string/upper-case contents)))

so each "effect" is a function you call that returns a vector of vectors

{:fx (alert "abc")}

and if you want to combine fx, we have a helper function that concats them together

{:fx (fx/in-order
         (alert "abc")
         (http-req {...}))}

then if we have some process that we want to re-use in multiple handlers that will update state and perform some effects, we make a function

(defn do-thing [db]
  {:db (inc db}
   :fx (alert-fx/alert "abc")})

and we have another helper that lets us compose functions that have the signature db -> {:db, :fx}

(rf/reg-event-fx
  ::abc
  (fn [{:keys [db]} [_ abc]]
    (let [process (compose-effect-fns
                             do-thing
                             (fn [db] {:db (* db 2)}))]
       (process db))))

and for new stuff we aren't allowing dispatches within a handler - keeping dispatches to only stuff the user did or reactions to outside processes

beyond that nowadays its gotten to

(defevent abc
  [a b c]
  :handler
  (fn [{:keys [db]}]
    {:db (* db a b c)
     :fx (alert-fx/alert "AAA")}))

how do you handle like, "do a network request and then update the app-db"?

which produces a constant event:abc equal to ::abc , a function abc, which when called will produce a vector you dispatch and a function handler:abc which is your re-frame handler

do you mean app-db updates you do as soon as you launch the request or when it comes back

(defevent successfully-did-thing
  [response]
  :handler
  (fn [{:keys [db]}]
    {:db (* db 2)}))

(defevent failed-to-do-thing
  [error]
  :handler
  (fn [{:keys [db]}]
    {:db (/ db 5)}))

(defevent do-thing
  [user-id]
  :handler
  (fn [{:keys [db]}]
    {:db (+ db 1)
     :fx (http-fx/request 
           {:uri "..." 
            :params {... user-id ... }
            :on-success successfully-did-thing
            :on-failure failed-to-do-thing})}))

(we re-wrote the normal :http-xhrio to support some stuff like functions for on-success, but same concept)

does that make sense?

@U3JH98J4R That's at least the third time I see how you write extensively on this topic. Have you considered making a blog post or at least a detailed gist about it? Would be easier to share, publicly improve upon, and discuss in a persistent manner that's not possible on this Slack.

eh? its a pattern we still haven't worked out all the issues with and are using as a tool to patch up a large codebase. The ideal end point might be a library other than re-frame because it explicitly goes against what I think is intended design

plus its literally just the way elm does stuff being forced onto re-frame - not without reason, but certainly without elegance

but yeah next time it comes up I'll try to make a gist

also i don't have a blog to put it on - i know that makes me a heretic

a gist or something durable would be great for me! thanks for taking the time to write this down

bouncing around meetings rn but I will digest and maybe ask a couple more qs in a bit

> https://gist.github.com/bowbahdoe/7fd8714cd910d43eb3229f967d95cbc6

mind if I post this in a work slack?

go ahead

do tell me any feedback though