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
Fix templates and book to recommend Pathom setting for always returning :tempids #484
Comments
This is close to what we want (if we expand the default exclusion list):
|
Some questions, @awkay, to determine whether adding
(For mutations, we could perhaps offer a function you can hook into the app's |
Honestly I do not remember/know. In terms of what needs to be in the query: remember that if there is a mutation join that Fulcro uses that for merge as well, so if the key is not in the outgoing query Fulcro itself will filter it. To be honest I'm torn on how much pathom-specific stuff to include, since that is an external lib that is in the process of changing how it works. I'd probably tend to leave the pathom-specific keys out altogether and document that you might want to customize that part for your app. |
No need for :tempids in mutation queries?!According to my experiment, we do not need to add
(Pathom 2.3.1, Fulcro 3.5.2) |
Hm. I have seen this mess up in RAD, so I know it doesn't work through the stack. It could be that Fulcro's the one filtering the tempids? Does the remap work in case (2)? |
It does. I will try this with RAD demo itself.
|
Confirmed that in RAD Demo I need to add :tempids to mutation joins otherwise tempids are not returned by Pathom. Need to explore. |
Oh, I see why getting back tempids worked in my first test. I had this in my parser config: {::p/env {::pc/mutation-join-globals [:tempids], ...}} @awkay wouldn't adding the Pathom config ☝️ be a simpler solution than modifying the global-eql-transform in Fulcro? It would require more work from the user, namely to copy a "recommended" Pathom setup - but I expect that most users do that anyway? But it seems that neither fulcro-template nor fulcro-rad-demo do this for some reason? Above you wrote
Does that mean that is You also wrote
I guess it means you would after all prever not including |
Yes, I was not aware of this option in Pathom. It would be better to just recommend that and fix the templates. In terms of the errors: Fulcro does not require Pathom, and how you deal with errors on Pathom is also pretty configurable. I'm fine with setting up the templates to glue together error handling in some "useful" manner but given that Pathom 3 might even change this key I really don't want to chase Pathom on this in Fulcro's code. |
Then I guess we should close this issue as "won't fix"? |
Yeah, let's open up the templates and fix them, and also document it in the tempids section of the book. Let's just track it with this issue, since all the history is here. |
Fix fulcrologic/fulcro#484 for fulcro-template Now even if mutation has a mut. join that does not specify `:tempids`, these will be returned anyway.
Instead of manually adding :tempids to mutations on the client side, we can leverage Pathom's config to do it automatically on the server side. Fixes fulcrologic/fulcro#484 for RAD.
The last part of fixing fulcrologic/fulcro#484
Instead of manually adding :tempids to mutations on the client side, we can leverage Pathom's config to do it automatically on the server side. Fixes fulcrologic/fulcro#484 for RAD.
...in the same way as fulcro-rad does, so that it is easier to get hold of these e.g. inside `remote-error?` Related to fulcrologic/fulcro#484
Add :tempids to mutation join queries by default so that all users do not need to do that themselves (and '* if there was no query before to preserve Pathom's behavior of everything the whole mutation output if the user did not ask for anything in particular).
Add ::p/errors to all queries and mutations - most users of Fulcro use Pathom and need this and an extra keyword will not harm those who don't (and they can always remove it via a custom global transform).
Also expand the default elision list to RAD's (for the sake of simplicity, include also the *.rad.* ones, they are just keywords so do not create any dependency on RAD and will make its life easier).
Consequences
The text was updated successfully, but these errors were encountered: