Fork me on GitHub
#fulcro
<
2018-10-29
>
tony.kay01:10:54

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.

bananadance 3
aw_yeah 1
tony.kay15:10:23

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

👍 1
pvillegas1218:10:00

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)

pvillegas1218:10:29

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

currentoor19:10:32

@pvillegas12 how are the components updating their state?

currentoor19:10:41

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

tony.kay19:10:47

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

pvillegas1222:10:42

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

tony.kay22:10:19

transaction elements will see the state as it evolves, yes

pvillegas1222:10:58

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

tony.kay22:10:29

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

pvillegas1222:10:38

I run a mutation to do the file upload

tony.kay22:10:49

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

pvillegas1222:10:50

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

pvillegas1222:10:09

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

tony.kay22:10:24

what’s the computation, out of curiosity

pvillegas1222:10:56

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

tony.kay22:10:16

and the client needs to know the result of that?

pvillegas1222:10:31

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

tony.kay22:10:27

you could use a “mutation returning”

tony.kay22:10:36

the file upload could actually return the result

tony.kay22:10:11

and it would auto-merge

tony.kay22:10:43

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

pvillegas1222:10:10

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

tony.kay22:10:36

your perogative 🙂

🙂 1
tony.kay22:10:08

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

tony.kay22:10:28

so parameters to mutations that follow will be correct as well

👍 1
pvillegas1222:10:35

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

pvillegas1222:10:44

(performing that within the load mutation)

pvillegas1222:10:34

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

tony.kay22:10:33

are you seeing the tempids correct in inspect afterwards?

tony.kay22:10:49

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

tony.kay22:10:05

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

pvillegas1222:10:03

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

pvillegas1222:10:16

Have to check the logging

pvillegas1223:10:26

@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)))
Is there something here that might cause the behavoir I’m seeing?

tony.kay23:10:54

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

tony.kay23:10:18

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

tony.kay23:10:20

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

tony.kay23:10:39

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

tony.kay23:10:17

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

tony.kay23:10:28

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