Fork me on GitHub

is it possible to load! mutiple entities in one network request? I thought I remembered seeing that in past versions of fulcro, but I don't see any mention of it now. I'd like to make a query like: [{:entity/one [:prop1 :prop2]} {:entity/two [:prop3 ]} etc] in one network request.


based on the mutation that load! produces it looks like i can use! and provide my own :query


now i'm thinking the easier way is to make up a new pathom resolver and component for this collection of props under a new keyword

👍 4

@U051V5LLP So, load combining is slated on the TODO list, and really is relatively trivial. I can tell you how to add the feature if you want to give it a go.


It goes roughly here You have to understand a little aobut the tx processing system. I have to give the illusion of running individual loads and mutations one at a time (you can have a separate error action on any one of them). The combine-sends here actually re-combines any tx that was split internally to get that granularity. I.e. [(f) (g) (h)] turns into 3 processing nodes, and combine puts them back together for network comms, and then later steps split out the result and dispatch. Technically, anything that is on the network queue can be trivially combined IF we expand the network protocol to allow it to send a request with multiple things. Right now we send a single vector (which has loads or mutations), BUT we could send a map (for easy detection) that has the key :txes which holds a vector of requests (a vector of vectors). Then you could flush then entire network queue in one request. The only change needed is that the middleware on the server needs to be able to accept that. For bw compat, it needs to be a config option on Fulcro app so it isn’t the default.


cool cool - i figured as much, I saw the tx-processing-readme 🙂 Sure, I'd be open to trying my hand at it


Then the server processing is just a mapv of calls to the parser


great…I’d love to have that


make sure that errors in the server processing are isolated per parse, of course, or you could cause cascading failure that should not happen.


NOTE: You need to make a nested vector because the responses are maps…so if your queue had 3 txes that all called f you can’t combine them unless the response can be a vector of responses, each a map with key 'f.


but like I said…overall it is a trivial extension, and there is nothing about the rest of the layers that will care. Remotes just handle raw EDN. Oh, well, the response handler fn will have to be wrapped of course.


as I do in the current combine-sends for recombining mutations into a tx


There is also a helper in That can dump out the current tx processing state. That can be useful for seeing what’s in there…just pepper it around in the tx-processing ns code. Make sure you remove it so that pprint doesn’t end up in cljs builds 🙂


ok awesome, thanks so much for the info, I'll let you know if I get stuck

Jakub Holý (HolyJak)15:05:27

I guess it would help if experienced Fulcro devs could comment and help make the case for Fulcro?


I am an experienced fulcro dev, but @U0CKQ19AQ is way more eloquent and experienced than me. So if it matters, might be better for him to respond.


I’m looking at the repo and I still have no idea what the project is for lol.


Oh I see, it’s Roam but open source?


Yeah I have no idea what is a good fit for a project like that

Jakub Holý (HolyJak)15:05:27

I guess it would help if experienced Fulcro devs could comment and help make the case for Fulcro?


Hello, How do I inspect props? i trying to passing props down but it’s not working would like to see what they are.


At the moment I just do (dom/p (str props)) on whatever element i’m intrested in. Is there a nicer way?


I usually add a console log with them.

👍 4

Thanks that works well! Should of thought of that :man-facepalming::rolling_on_the_floor_laughing:


Happens to the best of us 😉


Just tried ‘(dom/pre (with-out-str (cljs.pprint/pprint props)))’ which worked nicely too


i have been using this helper when debugging props:

(defn get-props-keys [c]
  (->> (comp/get-query c)
    (map :dispatch-key)))

(defn table [header-cells rows]
  (dom/table :.ui.celled.table.striped.yellow {:key "table"}
      (dom/tr nil (map #(dom/th #js{:key (str %)} %) header-cells)))
      (map (fn [[k v]]
             (dom/tr #js{:key (str k)}
               (dom/td #js{:key "key"} (str k))
               (dom/td #js{:key "val"} (pr-str v))))

(defn props-data-debug
  "show table of fields for a component with value ."
  [com show?]
  (let [props (comp/props com)
        ident (comp/get-ident com)
        prop-keys (get-props-keys com)
        rows (map #(vector % (props %)) prop-keys)]
    (when show?
      (dom/div nil
        (dom/h2 {:key "first"} "ident: " (pr-str ident))
        (table ["prop" "value"] rows)))))

Jakub Holý (HolyJak)16:05:27

Nice! I've noticed you use #js even though Fulcro dom works without it, is it for performance reasons?


yea, it's a habit , definitely not necessary here


assumes you're using semantic css