Local state management

[ghost]

Hello,

Is there a local state? Something like apollo-link-state? 😇

Thanks!
Maxim

[kitten]

Hiya, there's no additional package yet that implements it, but there very well could be in the future.

While it's unlikely that we'll pick this effort up ourselves and put it on our road map, we'd be happy to support anyone else who want to make this happen 👍

We're currently working on more documentation regarding how to write exchanges.

[deadcoder0904]

@kitten Was thinking about this too. Did someone take it up? And is there a way to see different community-made exchanges?

[JoviDeCroock]

Hey @deadcoder0904

We have: https://github.com/FormidableLabs/urql/blob/master/docs/guides.md as guides to help you out with writing exchanges.
For now exchanges made by us and the community are kept on the readme.
https://github.com/FormidableLabs/urql#-add-on-exchanges

There could be more but not that I know of at this moment.

[ahmedosama5200]

I am trying to choose a client for my react app. is this feature not yet implemented ?

[ghost]

@ahmedosama5200 Go Zustand https://github.com/pmndrs/zustand or React Query https://github.com/tannerlinsley/react-query

[ahmedosama5200]

I am aiming for a more full-featured graphql-specific client. I know apollo but thinking about using urql

[ghost]

@ ahmedosama5200 URQL has no local state (as far as I know), but only cache.
Look here for more details https://react-query.tanstack.com/comparison and https://rtk-query-docs.netlify.app/introduction/comparison/

[JoviDeCroock]

Hey @ahmedosama5200

Currently we don't have a first-party integration for client-side extensions to the server-based schema, we haven't prioritized this since we have yet to see a good use case for this.

We currently advise on React-state or one of the many local-state libraries out there in the wild.

That being said it's always possible to implement this with an exchange as explored in #462, our extensibility pattern called exchanges allows for almost anything.

[kitten]

It's also worth noting (to lift this from our other responses) that we don't believe in local state management in GraphQL clients or expressed in GraphQL itself.

Ultimately urql, like react-query which operates under a similar philosophy, is a server-state client, so to speak.

It's advantageous to use GraphQL to your advantage to model data requirements and to fulfil them with a client. For more complex use cases we've got Graphcache, our normalised cache, for this task. Local state is better expressed in existing React hooks tools or libraries that do focus on local state, like Zustand for instance.

If you combine server state and client state (or even UI state and server state) there's IMO not much to gain but much to lose in terms of coupling and "muddying" the otherwise clean nature of server state flowing down your element tree.

[ahmedosama5200]

Apollo and urql seem very similar to me. I feel like I already know urql because I know apollo except for little terminology(links become exchanges and so on), so migrations between the two, anytime down the road, will be easy, I guess

I think my algorithm will go like this:

• if I need complex state management, I will go for URQL + redux (or mobx)
• If I need simple state management, I will go for apollo with its built-in state management

[villesau]

@kitten what is "the preferred urql way" to populate client state via urql? Let's say a form or something that is managed via redux and populated via urql from the server. Now I've resorted to some useEffect trickery, but would be cool if urql would provide some callbacks for this purpose too useEffect feels like a fragile workaround.

[RIP21]

TBH this is the only thing that is a bit sad. That you cannot just use data from urql easily in your external things like react-hooks-form and whatnot without useEffect sync code or some other hacks.

A good example would be starting a query, suspending the tree, and then getting a bunch of calculated fields and other things from the data from the query. Obviously, we need to strive to have all the calculations serverside, but sometimes some small silly things are fine to calculate on the client.

It may also be useful in the scenario of rerender optimization too, as components can subscribe only to changes of the subset of the data from the query at any level using some useSelector or so instead of using prop drilling or silly useMyQuery wrappers of useQuery here and there to get it anywhere in the tree. Plus, any changes to the query will cause a rerender, while useSelector and other libs like Jotai and their selectAtom optimize that and rerender only in case value changes. (still waiting for useFragment sorcery in URQL that will probably enable that)

It's obviously hard to incorporate correctly into Redux and whatnot, knowing, more or less, how URQL is working internally.

In a sense that current React bindings are tracking currently listened-to operations via provided hooks, and refetch them in case let's say refocus exchange is used, etc.

Having some urql to Redux bindings would need to incorporate all these things, so all the useUrqlSelector etc. will be smart enough to subscribe, unsubscribe, and do other things URQL default React bindings do (like suspense) which are quite hard to achieve.

Primitive bindings to Redux and whatnot should be not so hard to implement, but correct and full-featured bindings are gonna be tricky 100% (saying that as an author of jotai-urql) same applies to xstate and others.