React hooks RFC

[Pagebakers]

Right now for each operation a method is generated in the web client and in the hooks implementations for React and Next.js. This creates a lot of overhead, and the generated code can't be code-splitted. Which could be a big deal in bigger projects, because you need to load the entire client in your client bundles.

There are a couple of ways that we could potentially improve this.

Using keys as method accessors instead of actual methods.

const client = new WunderGraphClient<Role, Operations>(config)

client.query('Weather', { input: { forCity: 'Berlin'  })
// we can possibly even infer the types without breaking the current client api.
client.query({
  operationName: 'Weather'
}, { input: { forCity: 'Berlin'  })

const hooks = createWunderGraphHooks<Role, Operations>({ client })

// Similar markup as React Query
const { data } = hooks.useQuery(['Weather', { input: { forCity: 'Berlin' }])

Another solution for hooks to make them tree shakeable is generating individual functions for each operation. This could also be a wrapper around hooks.useQuery(...).

import { useWeatherQuery } from 'generated/hooks'
const { data } = useWeatherQuery({ input: { forCity: 'Berlin' } })

This will keep the client and hooks lightweight in the production bundle, but still have full TypeSafety in development.

[jensneuse]

I think I like variant 1 more, as you don't always have to add imports for a new hook.

[StarpTech]

Hi, so this RFC is about code-splitting the client? I don't see an issue with generating a method per operation. It's overhead but not much for 99% of cases. But from React Developer's perspective, I like variant 2 because it is very explicit and feels like "real" code generation :) We also need an imperative way to call the API. Currently, we do it like this

const {refetch} = useQuery.Weather({ lazy: true })
refetch()

I'd prefer variant 1 for the base client implementation and variant 2 for the new react interface.

[jantimon]

TL,DR: 👍 smaller bundles, better performance, better caching, faster compile times

I really like that idea - right now the Wundergraph Hooks API feels like it was not build with medium to large applications in mind.

Dead code elimination is a great tool for performance and also a great DX as you can rely on the compiler to optimize the code automatically.

Large applications often use hashes in their names for example weather-ea4f9.js and user-f628ea.js. This pattern allows cdn and long term client side caching. Unfortunately the current approach which generates all queries in one single file is not ideal for it. Any change to a query would cause a hash change for all chunks which use a wondergraph hook.

The same issue slows also down bundle during dev and production builds as a change of any query would force the bundler to rebuild all files..

There are some edge cases which disables dead code elimination once you use common chunks optimizations and lazy loaded chunks. Splitting the generated code into several would also solve those issues.

import { useWeatherQuery } from 'generated/hooks/useWeatherQuery'

const { data } = useWeatherQuery({ forCity: 'Berlin' })

Furthermore we could split input and options for an additional minification bonus.

A generated hook file might look like this:

export const useWeatherQuery = (input, options) => useInternalQuery('weather', input, options)

Splitting operations into files could also allow future performance gains for the wundergraph compiler as it allows parallel and incremental code generation.

[Pagebakers]

Great feedback @jantimon.

I think it would make sense, we could have a configuration option just like graphql-code-gen where you can specify to generate a single file with all hooks or create individual hook files. This way we can accommodate projects of any size and also be ready for parallel/incremental code gen. 👌