Incubator 0.0.11 on Clojars. Contains a new ptransact! that is just like Fulcro’s, but can compose the special mutations used with pmutate!. This unifies the API.

Ooops…0.0.11 has a stray debug stmt left in it. Released 0.0.11-1 to fix that.

What pattern can I use to invoke a mutation/load when I have multiple components that update their state as done? (image a component per model object which has a ui/is-done? flag)

I want to fire the mutation when every component has ui/is-done? be truthy

@pvillegas12 how are the components updating their state?

is it ui interactions? is the state you’re referring to app-state or component local state?

@pvillegas12 You’d build the check into the mutation that is modifying the flag. That is the “event” you care about: the done flag changed…if all of them are true (which you check inside of the action of the mutation at every invoke of that mutation), then you issue your load-action. The remote side of the mutation can just always return remote-load..which is a no-op if no loads are queued.

The load is queued after a file-upload mutation @tony.kay, will ptransact! give the load mutation the right @state? The loading relies on the server-persisted file-id

transaction elements will see the state as it evolves, yes

I would have to wrap the df/load-action into a mutation to be able to see the updated state then

yeah…you running one mutation to trigger multiple uploads? Or one mutation per upload?

I run a mutation to do the file upload

either way: [(upload) (upload) (upload) (load-stuff)] with ptransact! should actually work fine

Then, I need to perform a computation on the server regarding that uploaded file

(I could also perform it on the server after uploading the file :))

what’s the computation, out of curiosity

It takes the file and applies a transducer transformation to convert the file into a generalized accounting object

ah, ok

and the client needs to know the result of that?

correct, I was thinking of loading the blob and putting it unnormalized in the fulcro db

you could use a “mutation returning”

the file upload could actually return the result

and it would auto-merge

but then you’ll still want ptransact to update the UI after that

Right, the downside is I don’t want to complect file uploading with performing the computation (which could be expensive depending on file size)

your perogative 🙂

So, as long as the upload returns the tempid remapping for the file-id, the next mutation will see it correctly in state…AND if it was in a parameter and is a tempid, the tempid remapping will also “fix it” in the network queue

so parameters to mutations that follow will be correct as well

@tony.kay with a ptransact! I’m trying to do (get @state :file/by-id) but I still see the fulcro tempids

(performing that within the load mutation)

The file upload mutation is returning {'upload { :fulcro.client.primitives/tempids ... }}

are you seeing the tempids correct in inspect afterwards?

can you add log statements and verify the load is running after?

Is you remote-load in the remote side of the loading mutation conditional? That can cause mis-detection

Tempids are correct in inspect afterwards and the remote load is unconditional

Have to check the logging

@tony.kay the mutations run in the correct order. I am using a custom response middleware

(def file-response-middleware
  "Middleware for converting the file upload server's response to something usable
   on the client (mainly tempid remapping). The server middleware will respond with 
   tempid remapping (we send a tempid with the upload). If there is an error, we'll 
   also see it here, but instead of letting it leak to the API error handling
   routines of Fulcro we instead just update app state with the result."
  (->
   (fn [{:keys [body error] :as resp}]
     (let [ast     (prim/query->ast1 (:transaction resp))
           id      (get-in ast [:params :value :db/id])
           real-id (get-in body ['upload ::prim/tempids id])]
       (println real-id)
       (cond-> (assoc resp
                      :error :none

                      :transaction [{(file-path real-id) [:db/id :status]}])
         (= error :network-error)      (body-response body id :network-error)
         (= error :http-error)         (body-response body id :network-error)
         (and real-id (= error :none)) (body-response body real-id :complete))))
   (net/wrap-fulcro-response)))

So, ptransact! is just a transform function…it isn’t a low-level primitive. Basically it turns your mutations into a sequence of loads with post-mutations

where it is “fake” loading to get the built-in post mutation behavior

so it turns your sequential looking transaction into a nested one…like this: https://github.com/fulcrologic/fulcro/blob/develop/src/test/fulcro/client/primitives_spec.cljc#L939

and deferred transaction is just this: https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/data_fetch.cljc#L414

the special loading keyword on that load action is coded into the internals, but it basically forces your mutation to look like a load to Fulcro…the remainder of the tx is moved to the post mutation

but the way it detects which things to defer is by running the mutations and seeing which ones claim to be remote

perhaps that will help you figure out what’s wrong…I’m not aware of a tempid remapping bug