Roadmap for v4

[micimize]

There are a handful of open PRs and issues that I think should be parceled together for the next major version:

• feat: drop Link layer in favor of package:gql_link and package:gql_exec #564 & Drop string documents #565 (outsource links to gql)
• many caching fixes:
  • AST-based normalization / denormalization #471 (outsource normalization)
  • State of inMemoryCache is not always persisted/restored correctly #423 (the cache is kinda broken)
• many of the items enumerated by @klavs in Further modularization of this project #563 (comment)

The main question is should we make a v4 branch or something to avoid every merge auto-publishing a breaking change? Or, should we rework CI such that master is the main development branch, and have master, beta, stable? Or should we just temporarily disable CI and then re-enable after achieving a stable API?

@HofmannZ @eusdima @mainawycliffe

[mainawycliffe]

Since we will most likely be introducing breaking changes, version 4 makes sense. Yeah, we can disable the ci temporarily and enable it ones we have an idea of what exactly we are testing and how to deal with it.

[teknolojia]

can we get cookie storage in v4?

[micimize]

@teknolojia we can make cookie support a higher priority, yes

[micimize]

I've decided to move working on graphql_flutter to the top of my priority queue, particularly working on v4.

To support development please sponsor me or the graphql-flutter open collective if you can.

[klavs]

FYI, @iscriptology just ported websocket link from graphql_flutter to gql_link.
I'm currently working on an ErrorLink with an example HttpAuthLink implementation.

For full feature parity, gql_link is missing file upload. (Because that's not a standardized feature of GraphQL).

Other than that, I feel that gql_link is soon to be ready for v4-alpha to be tested in the wild.

[micimize]

Merged #564 & #565 and will be treating modularization as the v4 branch.

Some related todos for myself

• Update docs and examples
• Grok gql's error system and it's integration with ours
• // TODO: handle Link exceptions
• Bring Links up to par with what package:graphql has gql-dart/gql#57
• Fix widget issues like Prevent query from running again if not necessary #352, [v4] Confirm removing keys from widgets is safe #651
• Fix subscription widget Rework Subscription widget/api #300
• Generalize fetchMore api Decouple fetchMore logic from ObservableQuery #646

[micimize]

Considering adding default json.encode logic / options to the roadmap (#642)

[micimize]

@teknolojia v4 uses gql_link, for which there is gql_dio_link. dio has a cookie manager plugin for dart:io contexts and regular cookie support in the browser. Would that be enough for your session management?

http also has the withCredentials config in the browser, but seems fairly lacking in cookie support

[micimize]

I've been making slow and steady progress here – got the starwars example running again today, and have been adding better docstrings. Will probably start diffing against beta to avoid clobbering recent changes and then publish an alpha version for people to start using tomorrow.

some things I might consider working on after a stable release candidate is ready:

• significantly overhauling the flutter api (possibly with flutter_hooks)
• I'm following this discussion on embedded api docs – would be pretty cool if we could get working in-browser examples, but

[JigneshWorld]

I got opportunity to play with v4 on flutter web.

For Authorization Token, I came to know that AuthLink is caching the token internally.
For some reason, I want to send a new token after some requests like the user logged out and new user logged in.

If there any possible way or workaround to update that new token on AuthLink and subsequent request called will be using the new token?

Reference: https://github.com/zino-app/graphql-flutter/blob/modularization/packages/graphql/lib/src/links/auth_link.dart

[LasseRosenow]

@JigneshPatel23

There is an open isssue regarding this: #688

[LasseRosenow]

How do I correctly reset the cache in v4?

Right now I am doing this:

GraphQLProvider.of(context).value.cache.store.reset();

But I get a warning saying: The member 'store' can only be used within instance members of subclasses of 'package:graphql/src/cache/cache.dart'.

[micimize]

@lazylazyllama there isn't a better way right now – we should probably implement apollo's client.resetStore and refetch all live queries.

If you want to work around the warning I think you could do something like

extension on GraphQLCache {
  void resetStore() => store.reset();
}

[micimize]

based on #704 (comment) we really need gql-dart/gql#119 solved for backwards compatibility

[24601]

Is there a roadmap/design for Local State Management? I have tried searching issues and don't see much, but would like to see where the thoughts are on this to see how we can consider contributing.

[micimize]

@24601 direct cache access can be used for local state management – we don't have any real examples yet but basically you can cache.writeQuery and writeFragment to write arbitrary queries to the cache that are then normalized.

@SanjiKir indicated he was using it in the discord. I think having some docs/examples of usage for it and typePolicies (also from normalize) would be a pretty beneficial contribution

[SanjiKir]

@micimize I wasn't using it as a local state magement. I believe these are 2 different paradigms and we shouldn't mix data layer and app state layer together. What I do is I write to the store on mutation response (if it's a new entity created, then gql will not write it to the query) so I don't have to refetch the query. And sometimes I use readQuery to get some data for my app state to work with, but I treat it as a data layer data, which can be changed at a million of places, whereas my app state can and should be changed only using an application itself.

[PhoenixPan]

@lazylazyllama there isn't a better way right now – we should probably implement apollo's client.resetStore and refetch all live queries.

If you want to work around the warning I think you could do something like

extension on GraphQLCache {
  void resetStore() => store.reset();
}

I am getting the same warning on the store given the extension method...should I put the extension somewhere particular? I am on graphql_flutter: ^4.0.0-alpha.2

[micimize]

@PhoenixPan you're right. I've just published 4.0.0-alpha.7 which makes the store public and adds an experimental client.resetStore that also refetches queries by default.

[HofmannZ]

🎉 This issue has been resolved in version 4.0.0-beta.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[micimize]

closed with #648

[HofmannZ]

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀