Skip to content
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

Add useDynamicMutation hook #130

Merged
merged 2 commits into from
Nov 22, 2019

Conversation

Schmavery
Copy link
Collaborator

Wrote up some code for the useDynamicMutation idea in #128
Updated the examples to show usage but had some trouble running them (webpack acting up) so it would be great if someone can double-check that it works, otherwise I'll figure it out some other time.


let executeMutation =
React.useCallback1(
varsObj => executeMutationJs(Some(varsObj##variables)),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A nit on naming here. This is the Js.t created by calling .make() on the graphql_ppx_re module, yeah? Could we use the same nomenclature we do in useMutation and name this request?

Suggested change
varsObj => executeMutationJs(Some(varsObj##variables)),
request => executeMutationJs(Some(request##variables)),

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The type is slightly different (explained below), which is why I went with a different name. Doesn't bother me to change it though, if you think it's clearer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah that makes sense. I really wish we could destructure "open" objects like this so it'd be more like:

{ variables } => executeMutationJs(Some(variables))

Still I do find request a little easier to understand. This object passed to this callback is the result of calling .make() on that graphql_ppx_re module, and we have been calling that request throughout the codebase. Even tho we're restricting its type a bit more, it's more or less the same thing.

Copy link
Contributor

@parkerziegler parkerziegler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Schmavery this is really excellent. @robinweser is this an API you'd be happy with? I really like it, and I like that it keeps us out of functor usage – I think that's a huge benefit of reason-urql. A few smol comments you can take / leave. Thanks so much! I'll leave this open if you want to make those changes, otherwise feel free to merge at your leisure.

@parkerziegler
Copy link
Contributor

Also, I applied the patch locally and it works great. Yeah, webpack acts up a lot in those examples. I'm thinking I should move to a yarn workspaces setup so we can get rid of the dependency duplication and have more reliable local dev.

@Schmavery
Copy link
Collaborator Author

Updated the variable name and comments, will merge tomorrow morning if there are no more concerns by then (or feel free to beat me to it).

@robinweser
Copy link
Contributor

This looks brilliant! Happy to test it out :)

@parkerziegler
Copy link
Contributor

Looks great to me @Schmavery. I'll write up some docs for it this afternoon and get this released today or tomorrow! Thanks so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants