Fork me on GitHub

Thanks again @currentoor took me a minute to get my head around it. But this is just what I needed


Happy to help!


I can’t seem to get fulcro inspect working correctly, I have an old untangled app that has been converted to to fulcro "2.5.8-SNAPSHOT". I have fulcro-inspect in my dependencies fulcro.inspect.preload in my preloads (along with devtools.preload and dirac.runtime.preload. Is there something else I need to for fulcro inspect to detect I’m building a Fulcro app?


Thanks I’ll give that a shot!


Hmm that’s unchecked for me in canary


anyone have a sense of how to integrate pessimistic mutations with loads dispatched from within a mutation? I want to trigger some load in my ok-action (on success). my remote call is already wrapping env via (pessimistic-mutation env) and wrapping that result with remote-load doesn’t seem to work. doing (pessimistic-mutation (remote-load env)) doesn’t either


ideally your mutation would use a mutation join (returning) and just get the data instead of adding on another load. Then your ok action can even do additional merge-related logic on the received data.


If you really have to do it in this chained way, then you can save a ref to the reconciler on startup (it might be in env as well) and issue a load from within the mutation.


thanks for the response. do mutation joins work with pessimistic mutations? haven’t tried that yet


totally missed that section of the docs, appreciate the help as always 😅


encountering a weird bug where occasionally prop changes aren’t reflected in a component. I’m swapping the client-side state atom and can verify that the changes are inserted in the proper manner into the client db. 75% of the time everything is propagated and refreshed correctly. I’m using a pessimistic mutation that in turn dispatches other mutations, which might be causing some of the weirdness. for reference my ui and associated mutations look like this:

(fp/defsc SignUp [this props]
  {:initial-state (fn [params]
                    {:page :sign-up
                     :sign-up-form-data (fs/add-form-config SignUpForm (fp/get-initial-state SignUpForm {}))})
   :query         [:page
                   [:current-user '_]
                   {:sign-up-form-data (fp/get-query SignUpForm)}]}
  (let [user-authenticated? (get-in (fp/props this) [:current-user :user/authenticated?])
        sign-up-form-data (:sign-up-form-data props)]
    (if user-authenticated?
        (fp/transact! this `[(fr/route-to {:handler :organization-creation})])
      (sign-up-form sign-up-form-data))))

(defmutation users/create-user [_]
  (action [env] true)
  (ok-action [env]
             (let [{:keys [reconciler ref state]} env
                   mutation-result-path (conj ref ::pm/mutation-response)
                   mutation-result (get-in @state mutation-result-path)
                   result-data (dissoc mutation-result ::pm/key)
                   {:keys [user/id]} result-data]
               ; result data is a user object like {:user/id #uuid :user/authenticated? true}
               (swap! state
                      (fn [state]
                        (-> state
                            (assoc-in [:users/by-id id] result-data)
                            (assoc :current-user [:users/by-id id])
                            (update-in ref #(dissoc % ::pm/mutation-response)))))
               (fp/transact! reconciler ref `[(forms/reset-sign-up-form {})])))
  (error-action [env] ...)
  (remote [env] (pm/pessimistic-mutation env)))

(defmutation forms/reset-sign-up-form [_]
  (action [env]
          (let [{:keys [state ref]} env]
            (swap! state
                   (fn [s]
                     (-> s
                         (fs/pristine->entity* ref)
                         (fs/clear-complete* ref)
                         (assoc-in (conj ref :form/is-loading?) false)
                         (assoc-in (conj ref :sign-up-form.account-creation-attempt/account-exists-for-email?) false)))))))
what’s weird is that after both mutations run and the current-user is verified to be set at the root of the app db with the proper value, about 25% of the time that entry disappears from the props of the SignUp component – there’s no more current-user in the props. clearly doing something wrong here and maybe creating a race condition somehow. thanks in advance for any help


@mss frame refresh is limited to 60fps…if you swap on the atom after a tx, then the refresh logic in fulcro may skip your frame


You should also use ptransact! or setTimeout inside of transactions…directly nesting transact! isn’t supported


which is why the helper function exists for composition…you should have a reset-sign-up-form* that could just be used in the threading of the ok-action’s swap


Sames goes for load inside of a mutation…best “delay” it until the current tx is done


that makes perfect sense, thanks for the feedback