New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persist the ref across all transactions in ptransact! #98
Conversation
(let [ast-nodes (:children (query->ast tx)) | ||
{calls true reads false} (group-by #(= :call (:type %)) ast-nodes) | ||
first-call (first calls) | ||
dispatch-key (:dispatch-key first-call) | ||
get-remote (or (some-> (resolve 'fulcro.client.data-fetch/get-remote) deref) (fn [sym] | ||
(log/error "FAILED TO FIND MUTATE. CANNOT DERIVE REMOTES FOR ptransact!") | ||
:remote)) | ||
remote (get-remote dispatch-key) | ||
remote (or (get-remote dispatch-key) :remote) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this fixes the issue when the mutation doesn't have a remote
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
um...why would we want to add a remote if there is not a remote?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because otherwise, the whole process stops, the chaining depends on a remote call to happen so the post-mutation
is triggered to call the next mutation. Without this change, let's say you have 2 mutations on the list, the first one doesn't have a remote, what happens is that second never gets called, and an error is fired because of an attempt to call something without a remote (don't call exactly what now). This remote is not the real one from the mutation, this is for the one triggered by load-action
that triggers the next mutation, makes sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, thanks for the reminder...I'll look at it later tonight or tomorrow.
released in beta8-SNAPSHOT |
When there is a series of transactions on
ptransact!
, the series of mutations will want to change the state at the level of the ident that triggered the error. While I was trying to write a generic error story I quickly realize that I would have to send the ref over and over, adding a lot of complexity on my code (might requiring macros to make something reusable across my components). This PR fixes that story by re-attaching theref
on the follow-up mutations after the first. I tested this change on a project of mine that uses and also with the mutation merge on demos.Also fixes issue that prevents
ptransact!
to run the next mutation when the previous doesn't have a remote call.