Roadmaps!

[vicary]

You may know me as a low-key maintainer, that I have been putting this on maintenance mode for a while.

With a nod from @PabloSzx, we are now open to sponsors!

It means a few things,

1. More dedicated time on this project
2. More directional decisions can be made by the team
3. We get to buy coffee from sponsors! ☕️

There are long due features, bug fixes, and a lot of maintenance work to be done.

Yes I hear you! All of you!

To keep things super transparent, I am sharing the roadmap in my mind. The items will be slowly convert into tracking issues as I work on them.

Don't be shy to share your thoughts to shape the future of gqty!

---

1. Document the usage of cache.clear()
2. Auto-detects Bun in CLI

3. 2032

4. 2001

5. 1754

6. 2008

7. A smooth DX
   1. Development mode:
      1. [ ] @gqty/cli should perform a version check on installed versions of gqty and @gqty/* and prompt for an upgrade in needed.
      2. [x] autocodegen via watch and/or polling
      3. [ ] Static query generation (like inline snapshots in jest)
   2. monorepo examples
8. A mocking solution

   1. 876

   2. 1276

   3. 1281

      1. Depends on scoped query
   4. Mockable fetcher
   5. Mockable cache
9. Transactional snapshots for manual cache changes, for mutation errors when used with optimist response.
10. Custom scalar resolvers, working in tandem with scalarTypes.

11. 448

12. Expand frameworks support
    1. React Native (Hermes) #1179
    2. preact
    3. deno (fresh/preact)

    4. 1185

    5. vue

    6. 1758

    7. astro
13. Embrace React 18
    1. [x] Improving support for the render-as-you-fetch pattern (i.e. rework useTransactionQuery)
       1. (docs) useQuery({ prepare, suspense: true }) = suspense on first render
    2. [x] Server components
    3. [ ] SSR with Suspense renderToPipeableStream
    4. [ ] Use isPending in useTransition for the isLoading state, reducing unnecessary Suspense.

14. 1602

15. Refactoring
    1. [ ] Refactor CLI watcher into testable modules
16. Next majors (soon™)
    1. [package/core] Modular design, pluggable components:
       1. Functional programming: A proxy with a chain of resolvers, all the way to fetcher.
       2. query fetcher
          1. Defaults to fetch(), can be replaced with urql or apollo client
          2. static queries
          3. persisted queries
          4. file uploads
          5. query batching
          6. variable hashing #700
       3. query selector
       4. query builder
       5. caching
       6. suspense fallbacks
    2. [package/react] Refactor with use() and cache().

[bkniffler]

Hey @vicary. We really love gqty and we're happy to support the project! Is there some sort of timeline for your roadmap / new releases? Thanks :)

[vicary]

@bkniffler I am in the middle of integrating everything into useQuery to make room for features in the roadmap, which unfortunately lead to an early refactoring. It is taking longer than I wanted to, but I am powering through it.

Let me know if you need a quick fix on anything, I'll prioritize.

[bkniffler]

Our biggest issues are around the react client. We very much prefer using the transaction useTransactionQuery hook compared to useQuery, just due to having more control.

The issues we encountered https://github.com/gqty-dev/gqty/pull/1163 (fixed) https://github.com/gqty-dev/gqty/issues/1179#issuecomment-1439829140 (we're using the workaround I posted there)

We're also using our own useTransactionSubscription looking similar to this:

export const useV2TransactionSubscription = <T, TVar>(
  fn: (sub: gqlV2.Subscription, variables: TVar) => T,
  variables?: TVar
) => {
  const { subscribe } = useContext(context);
  const [data, setData] = useState<T>();
  const [error, setError] = useState<any>();
  useEffect(() => {
    const r = subscribe(
      (s) => fn(s, variables as any),
      (data) => setData(data),
      (error) => setError(error)
    );
    return () => {
      r();
    };
  }, [JSON.stringify(variables)]);

  return { data, error };
};

Maybe you could consider getting a similar subscription transaction hook into this repo?

[vicary]

@bkniffler The upcoming new useQuery() will support all options in useTransactionQuery(), with the only difference being whether you use a separate function or render in place.

Which feature gives you more control? I'll try to retain that in future iterations.

EDIT: Does useQuery({ prepare }) also do the job?

[bkniffler]

The current useQuery is a bit too magical and we've had a few cases where we tried to access properties but wouldn't be able to (from within a callback for example). useTransactionQuery and being forced to make all queries in the callback fn forces us to access everything we need in a single spot, which is more to our taste. prepare/prepass is useful, but I think we'd stick to transactions.

[bkniffler]

btw, we use gqty on our backend also, and useTransactionQuery is very similar to resolve+query. It imposes the same mental model in both parts of our stack.

[bkniffler]

https://user-images.githubusercontent.com/4349324/220785288-2ebbcd42-b4dd-4c15-bd09-7a25fda9ec27.mov

While attempting to do some performance optimization, we've also noticed many parts of our app rerender if we open a drawer. We isolated the rerendering being due to a query on the drawer. Is it possible that a query in a deep component might trigger rerender due to cache on a higher component if it made a similar query?

[vicary]

useTransactionQuery

I will keep the API of useTransactionQuery() as a wrapper over useQuery({ prepare }) in the upcoming version, in the upcoming release they should behave exactly the same.

Backend usage

Do you mean SSR? When JSX is not in the equation, useTransactionQuery() may throw a promise, which users may find surprising at times. I would prefer the core resolved in these cases.

Re-rendering

Queries are automatically subscribed to cache change. When the cache is updated as a result of a fetch, other components with useQuery() calls reaching the same value will also re-render.

You should be able to avoid re-rendering of a parent container by moving useTransactionQuery() calls further down into child components.

[vicary]

@noverby This should be already pinned in GitHub, do you mean pinning it in Discord?

[tyler-mitchell]

On the new documentation site it mentions "State Management - Coming Soon". Is there any more information on what that might bring?

[vicary]

@tyler-mitchell The idea is to expand the current optimistic cache into a reactive store. We are currently weighing between different implementations, the goal is to allow easy implementation for UI frameworks (React, Svelte... etc.) with the same core feature set.

[bkniffler]

Appreciate the roadmap, but it looks like gqty development keeps on stalling unfortunately :(

Wondering if trying to support all kinds of UI frameworks is making it much harder, building an optimistic cache is very ambitious, it took apollo a lot of effort, and its taken urql much (much!) longer.

Why not try and laser focus on gqty as a graphql interface / transformer, making it agnostic to the framework. E.g. we're using it with react-query and it works really well. Would split the project up into a core project, an optimistic cache and community driven framework specifc libraries be an option @vicary?

Really appreciate the effort and I'm happy to continue fund (I know its not nearly enough to make a living).

// edit: Didn't see there is still development in a branch: https://github.com/gqty-dev/gqty/tree/feat/scoped-query. Please bear with me

[vicary]

@bkniffler V3 is entering beta. I would make a stable release and move on to other features when we have solid production use cases, so you and others have a certain level of confidence.

My own team is leading with a few client projects using V3, they are going live next month or two. So you may expect a stable release of V3 coming shortly afterwards. 😄

Please do feel free to comment on the release planning, or really anything else.