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

Don't create a client by default in the context provider #227

Closed
jackfranklin opened this issue Apr 15, 2019 · 9 comments · Fixed by #420
Closed

Don't create a client by default in the context provider #227

jackfranklin opened this issue Apr 15, 2019 · 9 comments · Fixed by #420
Labels
future 🔮 An enhancement or feature proposal that will be addressed after the next release

Comments

@jackfranklin
Copy link

I just got caught out by realising I wasn't wrapping my component in a <Provider> that provides our own GraphQL client because the default context value is a urql client.

I get why this is a good default out the box for getting started, but I'd love to disable that so that we can ensure all our components are wrapped with a provider that exposes our custom client.

Is that possible to do, or to configure somehow ? If we can agree I'm happy to do the work to make the PR :)

@kitten
Copy link
Member

kitten commented Apr 15, 2019

I assume this means #225 is resolved?

I'll discuss this with @andyrichardson. I think we went with the defaults for shorter demos / getting started examples initially

@jackfranklin
Copy link
Author

@kitten yes it does, just left a comment there 👍

@andyrichardson
Copy link
Contributor

@jackfranklin is there a reason the default client is causing problems?

The default is only used when no value is passed to the Provider.

@kitten
Copy link
Member

kitten commented Jun 1, 2019

We could issue a one-time warning in development if the default provider is used? This way we can keep examples short but inform users that they're using the default client

@andyrichardson
Copy link
Contributor

There isn't much value in having a default client. Let's type the client argument of the Provider as required.

I don't think many will encounter this issue (the docs clearly document the Provider usage) so adding in runtime checks is probably more effort than its worth.

@kitten
Copy link
Member

kitten commented Jun 1, 2019

@andyrichardson I think we were more talking about the client context itself 😅 not the Provider prop. We have a default client on our context which means our examples are valid and functional even when the provider isn't set.

That being said, also not that valuable apart from when someone just copies a snippet and expects it to work without any provider and client which it is unlikely to

Edit: that being said btw, we can flag this for removal but that's a breaking change so we should maybe queue it up for v2

@kitten kitten added the future 🔮 An enhancement or feature proposal that will be addressed after the next release label Jun 4, 2019
@PascalPixel
Copy link
Contributor

We're trying to use urql with Storybook and trying to keep the concepts for React/GQL as simple as possible for our backend devs, so not using a Provider wrapper component or Context would make things simpler...

Would it be possible not to use a high level Provider component or use context and just pass the client to useQuery and useMutation directly and import them somehow?

For example:

import { useQuery as useQueryX, useMutation as useMutationX, createClient } from 'urql'

const client = createClient({
  url: 'http://localhost:1234/graphql', // Your GraphQL endpoint here
});

export const useQuery = (query='') => {
  return useQueryX(query, client)
}

export const useMutation = (query='') => {
  return useMutationX(query, client)
}

@nephix
Copy link

nephix commented Sep 11, 2022

So how can we turn the warning off? And why is there still a defaultClient without an option to disable it?

@sleekyom
Copy link

sleekyom commented Apr 4, 2023

I have the same warning to when running my test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future 🔮 An enhancement or feature proposal that will be addressed after the next release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants