migrate from `graphql-codegen` to `client-preset`

[esizer]

👋 Introduction

Currently, we are using the plugin typescript-urql to generate hooks and types for urql. However, graphql-codegen is now recommending the use of client-preset.

REF: https://www.the-guild.dev/graphql/codegen/plugins/typescript/typescript-urql

🕵️ Details

The library owners say that client-preset offers a better developer experience as well as smaller bundle size. It may be within our interest to migrate away from typescript-urql.

❗ Problem

This preset marks a fundamental shift in how data flows from the API to components. This will drastically change how we work with data coming from the API. You can read more at the following resource to get a better understanding of how this changes out approach to consuming our API.

• Unleash the power of Fragments with GraphQL Codegen

Acceptance Criteria:

• [ ] Migrate from typescript-url to client-preset
• [ ] useFragment is renamed to getFragment to be used as a non-hook

[tristan-orourke]

Also, maybe a different preset would allow us to put graphql operations in the same files as the components which call them, instead of in their own operations files: https://the-guild.dev/graphql/codegen/plugins/presets/gql-tag-operations-preset

[petertgiles]

split in two, first one issue 13 , second one spike three days

[petertgiles]

Eric believes it is not possible to break up this issue any smaller. We'll just have to make space for it in a sprint to complete it.

[mnigh]

Not sure if this is blowing out the scope but it would be great to have consistent naming conventions, hopefully following the examples used in the official docs:

• queries and mutations: pascal case (upper camel case)
• fragments: camel case

[esizer]

Should we convert this to a discussion to determine next steps? @tristan-orourke