DEV Community: Juan Pablo Djeredjian

How I use Claude Code to accelerate my software engineering job and improve my life

Juan Pablo Djeredjian — Mon, 26 Jan 2026 03:28:54 +0000

Claude Code has taken the software engineering world by storm and it's changing how the field looks in leaps and bounds. Prominent engineers are proudly saying that they're writing 0 lines of code already. Jaana Dogan, a Principal Engineer at Google working on Gemini, recently shared that she gave Claude Code a description of a distributed agent orchestrator problem, and it generated in about an hour what her team had been trying to build for the past year. She was careful to clarify: this was a proof-of-concept, not production-ready code. It still required validation, security reviews, performance testing. But still. An hour versus a year. Even with all the caveats, that's a staggering shift.

My feeling after working with Claude Code this year is actually: the upside is so huge that I'm surprised I'm not seeing it reflected in the amount of apps, features, and sheer progress in the software world. And I don't think we're in an early adoption phase anymore, as many argue. I think writing code has been commoditized already, and that just means the bottleneck has simply moved elsewhere: to generating new ideas, to testing and releasing, and above all, to distribution. The AI-generated apps might already be there, flooding the market; we're just not aware of them. They simply don't reach us.

And yet, while this is all exciting, it's also incredibly anxiety inducing. If you're a software engineer, you're probably feeling it too. Every week there's a new announcement, a new capability, a new "this changes everything" moment. And you're left wondering: am I keeping up? Am I falling behind? Will I still have a job in two years?

I don't have answers to those questions, I think nobody does yet for sure. But what I can tell you is how I've been using these tools to become significantly more productive, and how that productivity has actually made my job more enjoyable, not less. The more I use AI, the more I realize that the engineers who learn to collaborate effectively with these tools will have a massive advantage. That's what this post is about.

Section 1: Software Engineering

I'm not here to rehash Claude Code's features. Plenty of guides cover CLAUDE.md files, /commands, and skills. If you want a great starting point, Boris Cherny's thread (he created Claude Code) is excellent. His most striking revelation: "In the last thirty days, 100% of my contributions to Claude Code were written by Claude Code." And that includes 100% of the code written for the Claude Cowork project!

So, let me share what I've actually learned from almost a year of daily use. These aren't smart ways to use Claude's features, they're habits, workflows, and mental models that emerged from daily use. Things that simply weren't practical before Claude Code made them possible, but now are the very core of how I work as a software engineer.

Understand EVERYTHING

Joining a company used to mean months of gradual ramp-up. You'd slowly build mental models of different features, ask the same questions repeatedly, and forget half of what you learned. Today, there's no excuse for that.

With Claude Code, I send agents to investigate entire services, and point it to Jira tickets, GitHub PRs, Slack threads, whatever expands context. Then I have it produce an exhaustive, didactic guide in markdown and save it to a dedicated AI_DOCS/ folder in my repo.

Ask it to make extensive use of ASCII diagrams. Claude Code with Opus 4.5 really excels at this and is a wonder at explaining complex, multi-repo data flows and architectures.

Here's what I have Claude document for every major service:

Architecture overview
API endpoints and their purposes
Database collections and schemas
External service dependencies
Key files and their relationships

One of my guides distills dozens of conversations, PRs, and debugging sessions into a single source of truth. That's months of accumulated understanding I never have to rebuild.

The prompt pattern I use looks something like this:

Explore [SERVICE/FEATURE] and create comprehensive documentation:

1. Executive Summary - what is its core purpose?
2. Architecture - how is it structured? Include ASCII diagrams.
3. Data Flows - how does data move in and out? Visualize with diagrams.
4. API Routes - what endpoints does it expose?
5. Database - what does it store? Include schema overview.
6. External Dependencies - what other services does it call? How?
7. Key Files - where's the important logic?
8. Common Gotchas - what breaks? What's confusing? What's undocumented?
9. Common Operations - how do you test/deploy/debug it?

This is your treasure. Every time you revisit that system, debug something adjacent, or tackle a related feature, you have instant context, both for yourself and to feed back to Claude. The knowledge compounds instead of evaporating.

Give Claude access to every possible tool

Claude will be able to use all tools at your disposal faster, more efficiently and deeper than you. There are some tools which I think are essential, and you'd be shooting yourself in the foot by not having them.

💡 If both options exist, I prefer CLIs to MCPs (which fill up the context and can be slow). CLIs are extremely capable and fast and will give you the same features (or more) than its respective MCP.

Here's my essential toolkit:

GitHub CLI: For PRs, issues, checking CI status, everything. Claude can create PRs, review code, check workflow runs, all without leaving the terminal.
AWS CLI: For debugging Lambda logs, checking SQS queues, DynamoDB queries. Also Localstack for local dev, which uses the same CLI interface.
Logs (Datadog): We use Datadog, so I have Claude query logs directly. When debugging production issues, this is invaluable.
Database (mongosh): Give Claude access to staging, and if you can, read access to prod. If you can't, staging should suffice to answer questions like understanding schemas or checking data states.
Slack MCP: This one's super important. So much historical knowledge and context is trapped in Slack (Searchable Log of All Conversation and Knowledge!). The point is, your LLM needs to access this data in a way that doesn't require you to copy paste.
Atlassian MCP: For Jira tickets and Confluence pages. Here I do use an MCP because I found the API to be annoying to work with directly.

Make all knowledge LLM-consumable

Every startup has that ONE person who knows how feature X works, what that esoteric Clojure project does, or how to wire up Salesforce in local dev. In the past, you'd schedule a meeting, frantically take notes, maybe record it. Then good luck rewatching that hour-long video every time you needed to follow the steps.

Here's the trick: AI can extract that tribal knowledge and turn it into permanent, queryable documentation.

A Meeting Copilot summary won't cut it here. When you need extensive detail (steps to follow, historical decisions, specific commands), a summary loses too much. You need the raw material: video + transcript.

Here's what I do:

Record the knowledge transfer. Send a Meeting Copilot, or just screen-record while the expert walks you through the process.
Get video + transcript. You want both. The transcript captures what was said, but the screen shares show what was done.
Extract frames from the video. Claude can't process video directly (yet), but it can process images. I use ffmpeg to grab a frame every few seconds:

ffmpeg -i meeting_recording.mp4 -vf "fps=1/3" frames/frame_%04d.png

Point Claude at the frames + transcript. Ask it to create a detailed guide, using the frames as inline screenshots matched to the relevant steps.

The results are remarkable. Claude produced a step-by-step guide with screenshots accurately selected based on what was being discussed at each moment, pulling information from both the transcript and the shared screen.

Now you have a guide you'll never need to remake. But here's the real payoff: feed that guide back to Claude, and it can probably do the task for you.

This is what I mean by making knowledge LLM-consumable. Extract tribal knowledge once, and it becomes available to AI forever. The expert's time is captured, not lost.

Learn in context

Learning a new technology used to be tedious. Read the docs, try their toy examples, maybe spin up a starter boilerplate. But those never felt like real use cases. You'd understand the syntax without understanding how it fits into a real codebase with real constraints.

Claude Code flips this. Instead of learning in isolation, I learn in context: my actual app, my actual complexity, my actual requirements.

Here's what that looks like:

Ask Claude: "What would [technology X] give me in this app? What are the tradeoffs?"
Have it actually implement it
Ask it to swap in a competing option
Compare them side by side, in your codebase

A real example: I was building an app that needed agentic workflows and wanted to evaluate frameworks: OpenAI Agents SDK, Claude Agents SDK, Google ADK, and AWS Strands. I had Claude build a POC with the OpenAI SDK first, explaining the architecture and tradeoffs as it went. Once I understood how that worked, I opened multiple Claude terminals and asked it to rebuild the same functionality with each of the other frameworks, documenting the differences.

Within an afternoon, I had four working implementations and a clear sense of the tradeoffs. All in running code I could modify and extend.

Then I pushed further. I'd heard vaguely that Temporal could help with "long-running workflows" and human-in-the-loop patterns, but I didn't know how that would fit or help my app.

So I asked Claude: "What Temporal features could help me here?" It returned seven specific use cases, including the exact scenario I needed, each with proposal of parts of my codebase where it could help, with diffs and explanations for each.

But I didn't stop there. After going through the recommendations and understanding the proposals, I asked: "So, why is Temporal necessary? Can't I achieve this without it?" And it showed me a side-by-side comparison of both architectures, with side by side code samples pulled directly from the app I'd already built.

That's the difference. Real comparisons, in your code, for your use case. So you can learn and understand by making sense of new things in a context that actually matters and makes senses to you.

Use multiple AI tools together

Every model has blind spots. On any given run, one might miss an edge case, another might over-engineer, another might take a completely different architectural approach. When you run the same complex task through multiple models and compare their outputs, the differences themselves reveal tradeoffs you wouldn't have considered.

For any non-trivial task, I'll prompt:

Claude (via Claude Code)
Codex (OpenAI)
Gemini CLI (subsidized right now, basically free)

Then I compare their approaches. Sometimes one spots edge cases the others missed. Sometimes they propose completely different architectures. By combining insights from multiple outputs, I often end up with a more robust implementation than any single model would have produced alone.

I also do cross-model review. After one AI generates a plan or code, I have another review it:

Here is a plan that Claude generated for [TASK]:
[Paste the plan]

Please review this plan and identify:
1. Potential edge cases not covered
2. Security concerns
3. Performance implications
4. Missing error handling
5. Simpler alternative approaches

Think of it as an AI forum. You put models in healthy competition, letting them challenge and refine each other's thinking. The result is better than what any single model would produce, and you get there faster than going back and forth with just one.

Section 2: How to use Claude Code to improve your life

A few weeks ago I read Molly Cantillon's "The Personal Panopticon" and it broke something in my brain.

Her core insight is this: we are drowning in data about ourselves and yet we remain catastrophically blind. Our commitments exist in six different apps and cohere in none. Our finances are scattered across brokerages that refuse to talk to each other. Our goals live in some forgotten note from January. We have more information about ourselves than any human in history, and we can barely see any of it.

Her solution to this problem is simple: Build your own panopticon. Put yourself in the tower. Use Claude Code as the apparatus of sight, but point it inward.

She runs multiple Claude Code instances in parallel, each watching a different part of her life. Finances, health, email, personal projects. Her finances get synthesized overnight from multiple brokerages, cross-referenced with market data, and she wakes up to a brief. Her product metrics get pulled automatically and turned into actionable insights. Her email reaches inbox zero with auto-drafted replies she just reviews.

I'm not there yet. But I started building toward it.

I have a main folder with a CLAUDE.md file where I let Claude know basically everything about me, or tell it what external data sources to pull from to know:

Who I am: name, age, where I'm from, where I live
Family situation: married, one kid, another on the way
What I do for a living, what company I work for
What my skills and gaps are
How much I make per year
How much my wife makes per year
What our expenditures are (rent, utilities, subscriptions, everything)
What our assets are (savings, investments, property)
What my schedule looks like on an average day
General life objectives (retirement goals, travel plans, where we want to live long term)
Near term projects (learning a new skill, home renovation, job considerations)
Health information relevant to decisions
Important relationships and commitments

Yes, basically everything there is to know about me. I know how that sounds. But I've realized that the more Claude knows, the more useful it becomes. When I ask "should I take this job offer?" it doesn't give me generic advice about pros and cons. It knows my financial situation, my career trajectory, my family plans, my risk tolerance. It can actually reason about MY situation, not some hypothetical person's.

To start this out, I asked ChatGPT (which has the memory feature) to create a comprehensive personal profile guide to be consumed by Claude Code. Since ChatGPT already knew a lot about me from our conversations over the past year, it was able to compile a pretty good starting point. Then I reviewed it, added details, corrected things it got wrong, and now I keep it updated as things change.

Some real question Claude has helped me answer:

Financial planning: "Given our income, expenses, and the baby coming, can we afford to move to a bigger apartment?"
Schedule optimization: "I want to start running again but my mornings are packed. Look at my routine and suggest where."
Decision making: "My manager offered me this role change. Here's what I know about it. What am I not considering?"
Goal tracking: "It's been 3 months since I set these goals. Pull up the file and help me review progress."

And unlike a human advisor who you'd have to re-explain your whole situation to every single time, Claude just reads the file and has full context immediately.

I'm also starting to play with Clawdbot, a self-hosted assistant that connects Claude to my messaging apps. So instead of opening a terminal, I can just message my AI through WhatsApp or Telegram, from anywhere.

Cantillon ends her essay with: "The tools of synthesis belong to the individual now. Govern yourself accordingly."

I'm trying to.

Combining the power of React Query and GraphQL for data fetching and state management

Juan Pablo Djeredjian — Tue, 02 Nov 2021 19:53:32 +0000

On the first part of this series, we took a look at how, at my present company, we had the chance of starting a greenfield project, and could choose the libraries that we considered best for the jobs. We chose React Query to handle state management in our React app, and, because our backend team was delayed providing the API that was needed for the projects, we used a fake API to get the library working, and demo its functionality.

All was going according to plan until we had a meeting with the backend team, and Connor, one of the engineers, set us up for a surprise: "We have been thinking and discussing this for a while, and we consider that the best solution we can offer you is to build a GraphQL server you can use to query and mutate the data".

GraphQL? That was a first. Our company has many backend applications, some offering REST API services and other are message queues working with RabbitMQ, but GraphQL was definitely not under anyone's radar.

But as I started thinking about it, it slowly started having more and more sense. The frontend application we were building would need to display lots of data in many different shapes, with some pages showing tables with rows containing only a certain selection of properties of the data, other pages showing data summaries, and in most cases we would need to build advanced filtering functionality. GraphQL's ability to serve the exact data requested by the user would save us a huge effort of re-formatting it in the frontend, prevent us from over or under-fetching, and basically tailoring every request we made exactly to our needs.

It sounded good in theory... but we had already set up our up to use React Query as our data fetching library (and state management solution!), making requests to a REST endpoint. Would be need to throw everything away and start from scratch with something like Apollo?

It took only a small revisit to the React Query docs to realize that this wasn't the case. As we said on the first part of this series, React Query's fetching mechanisms are agnostically built on Promises, so it can be used with literally any asynchronous data fetching client, such as Axios, the native fetch and even GraphQL!

The library's docs recommended a mysterious tool for leveraging the combined power of React Query and GraphQL: GraphQL-Codegen. What was that? I had no idea at the moment, but it promised type safety, and code generation for "ready-to-use React Hooks, based on your GraphQL operations".

Digging a little deeper into the code generator's docs, we started to understand: "When we develop a GraphQL backend, there would be many instances where we would find ourselves writing the same things which are already described by the GraphQL schema [...] By analyzing the schema and parsing it, GraphQL Code Generator can output code at a wide variety of formats".

The best way to understand that is to take a look at an example of what GraphQL-Codegen does: it takes (reads!) our schema and produces -in our case- TypeScript types that we can use all across our applications, that we otherwise would have needed to write from scratch.

So, as the example in the docs show, provided we have the following GraphQL schema ir our app:

schema {
  query: Query
}

type Query {
  user(id: ID!): User!
}

type Mutation {
  updateUser(id: ID!, input: UpdateUserInput!): User
}

type User {
  id: ID
  name: String
  username: String
  email: String
}

input UpdateUserInput {
  name: String
  username: String
  email: String
}

Then GraphQL-Codegen will produce the following TypeScript types:

export type Maybe<T> = T | null;

/** All built-in and custom scalars, mapped to their actual values */
export type Scalars = {
  ID: string,
  String: string,
  Boolean: boolean,
  Int: number,
  Float: number,
};

export type Author = {
  __typename?: 'Author',
  id: Scalars['Int'],
  firstName: Scalars['String'],
  lastName: Scalars['String'],
  posts?: Maybe<Array<Maybe<Post>>>,
};

export type AuthorPostsArgs = {
  findTitle?: Maybe<Scalars['String']>
};

export type Post = {
  __typename?: 'Post',
  id: Scalars['Int'],
  title: Scalars['String'],
  author: Author,
};

export type Query = {
  __typename?: 'Query',
  posts?: Maybe<Array<Maybe<Post>>>,
};

OK! So far so good! But what exactly does this have to do with React Query?

To understand the real power of React Query + GraphQL + GraphQL-Codegen we need get our hands dirty.

Replacing our fake REST API with a fake GraphQL API

While the discussions continued with our backend of how their application would be structured, we decided to modify the proof of concept that we had already built (and saw in part 1 of this series) and re-write it to query and mutate data with GraphQL.

However, for that we had used the fake API service JSONPlaceholder. That would not help us anymore, as it provides a REST interface for fetching and updating mock resources. We needed a GraphQL API!

Enter GraphQLZero to the rescue: an online GraphQL API both powered by JSONPlaceholder and serving its same data, as well as providing the schemas! Exactly what we needed.

So taking as a starting point the demo we had built as seen in Part 1, we started by adding the GraphQL schema that we would feed the Code Generator, a simplified version of the schema provided by GraphQLZero. We thus created the schema.graphql file on inside a new /graphql directory:

# Example schema taken from https://graphqlzero.almansi.me/api and simplified
type Query {
  user(id: ID!): User!
}

type Mutation {
  updateUser(id: ID!, input: UpdateUserInput!): User
  deleteUser(id: ID!): Boolean
}

type User {
  id: ID
  name: String
  username: String
  email: String
}

input UpdateUserInput {
  name: String
  username: String
  email: String
}

input AddressInput {
  street: String
  suite: String
  city: String
  zipcode: String
}

You can take a look at the detailed docs on what GraphQL schemas are and how to write them, but as you can see from our file, we defined the schema for a User with a set of properties, as well as the Query to retrieve one or many of them, and Mutations to update and delete them.

Creating our GraphQL documents

The next step was to define our GraphQL documents. There are actually four types: [querys, mutations, fragments and subscription](https://graphql.org/learn/queries/)s, but for our use case we needed only queries -to fetch the data- and mutations -to update data-, as we had declared in our schema.graphql.

For each query and mutation that we want to perform in our application, we need to define an individual document that our GraphQL-Codegen can later understand and transform into usable TypeScript/React code.

Our simplest case is the query for retrieving an individual user: it retrieves the id and name of a User when the id is passed as a parameter. We therefore created our user.graphql document file and placed it in the new /graphql/queries path:

query getUser($id: ID!) {
  user(id: $id) {
    id
    name
  }
}

We needed also an additional query that retrieves multiple users, a UsersPage object type, with two sub-properties: firstly, a data object which consists of an array of Users, each of which will return the id and name properties; secondly, a meta object, which provides a totalCount property (total number of Users returned). We named this file users.graphql :

query getUsers($options: PageQueryOptions) {
  users(options: $options) {
    data {
      id
      name
    }
    meta {
      totalCount
    }
  }
}

Example of `mutation` document

What about updating User ? In order to do that, we need to describe a mutation that updates a User's properties, by passing as parameters the ID of the user to update, as well as the properties to update in the shape of UpdateUserInput input type.

To keep our /graphql directory organized, we created a further subdirectory called /mutations and saved our updateUser.graphql file there:

mutation updateUser($id: ID!, $input: UpdateUserInput!) {
  updateUser(id: $id, input: $input) {
    id
    name
  }
}

Everything seemed to be taking shape. We had now a new /graphql folder with the following tree:

├── graphql
│   ├── mutations
│   │   └── updateUser.graphql
│   ├── queries
│   │   ├── user.graphql
│   │   └── users.graphql
│   └── schema.graphql

Using GraphQL-Codegen to generate the code for us

So far so good. But all we have up until now are just a number of GraphQL documents with not much utility per se. How do we actually use them to retrieve and modify our data?

This is where GraphQL-Codegen comes into place: a tool that works as the "glue" between React-Query and GraphQL. We will use it to not only automatically generate TypeScript types based on the schema we described above, but also -and this is where it really shines- to generate ready-to-use React Hooks based on each of the documents we just wrote!

So, no more writing hooks to fetch or modify data by hand, just define a GraphQL document, run the code generator, and you'll have a hook at your disposal that leverages all the power of React-Query.

Let's get started with GraphQL-Codegen. Small note before though: the tool works for a wide array of languages and libraries, not only TypeScript and GraphQL. This is just one of the things it can do, and we are using this combination because this is how our app is written and what our backend looks like. But take a look at the docs to see all the possibilities it offers!

Getting started with GraphQL-Codegen

To get started, we first need to install graphql as well as three dev dependencies from @grapql-codegen : the cli for running our commands; typescript-operations , a plugin that generates the TS types out of our GraphQL schema and operations, and finally typescript-react-query , which generates the React Query with TS typings for us:

yarn add graphql
yarn add --dev @graphql-codegen/cli @graphql-codegen/typescript-operations @graphql-codegen/typescript-react-query

As a following step, let's create a script in our package.json file, that we can run to get our code automatically generated using our newly installed CLI:

"scripts": {
    "generate": "graphql-codegen"
}

And now we move forward to the most important step: configuring the codegen.yml file. This is the configuration file where we indicate GraphQL-Codgen what file it should create, where to generate it and point to which schemas and operations it should take into account. There is also a number of additional configuration options, some of which fit our use case.

Let's take a look at the finished file and then we can dive deeper into what it all means:

schema: "./graphql/schema.graphql"
documents: 
  - "./graphql/queries/**.graphql"
  - "./graphql/mutations/**.graphql"
generates:
  ./src/_generated.ts:
    plugins:
      - typescript
      - typescript-operations
      - typescript-react-query
    config:
      defaultScalarType: unknown
      skipTypename: true
      fetcher:
        endpoint: "https://graphqlzero.almansi.me/api"
        fetchParams:
          headers:
            content-type: "application/json"

schema: a path string to a local GraphQL schema file or a URL to a GraphQL schema provided externally. It should provide schemas for our data types as well as operations (Query and Mutation). This option also supports multiple schemas, that can be provided as an array of strings, and they will be merged. In our case, we point to our single schema.graphql file within our graphql directory.
documents: a path string that points to our GraphQL documents: query, mutation, subscription and fragment. Wildcards can be used to select all .graphql files under a directory: for our case, we will use an array to point to all *.graphql documents within our /graphql/queries and /graphql/mutations directories.
generates: a key-value map where the key represents an output path for the generated code and the value represents a set of options which are relevant for that specific file. We will generate our code directly within our /src folder.
- generates.plugins: a required list of plugins that the code generator needs to auto-generate types and hooks based on our schema and documents. For our React-Query use case we need the plugins which we have previously installed:
  - typescript
  - typescript-operations
  - typescript-react-query
- generates.config: a map used to pass additional configuration to the plugins. We are currently using:
  - generates.config.defaultScalarType: instructs the plugin to override the type that unknown scalars will have. Default value is any, but our config overrides it to unknown due to avoid having any types in our codebase.
  - generates.config.skipTypename: instructs the plugin not to add the __typename property to the generated types. Since we do not initially need to differentiate our objects types through their type, the default value is overriden to false.
  - generates.config.fetcher: customizes the fetcher function we wish to use in the generated file, and that will be responsible of making requests to our backend:
    - generates.config.fetcher.endpoint: since we will point to a unique endpoint exposed by our GraphQL server, we can configure it in this property. This prevents us from having to pass in the endpoint every time we use one of the generated React Hooks.
    - generates.config.fetcher.fetchParams: allows to set additional parameters to our fetcher function such as headers. We'll set the content-type header to application/json.

Notice that you can also configure codgen.yml to create multiple generated files with their own distinct schema, operations or config by structuring the file in an alternative way.

Let's go ahead and run our code generator by running:

yarn generate

If we take a look at the _generated.ts file created within /src we can first see how our fetcher function was automatically generated, already pointed at our pre-defined endpoint:

function fetcher<TData, TVariables>(query: string, variables?: TVariables) {
  return async (): Promise<TData> => {
    const res = await fetch("https://graphqlzero.almansi.me/api", {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify({ query, variables }),
    });

    const json = await res.json();

    if (json.errors) {
      const { message } = json.errors[0];

      throw new Error(message);
    }

    return json.data;
  }
}

It's also interesting to see how the generator creates TypeScript types based on our schema. For example:

export type Maybe<T> = T | null;

export type Scalars = {
  ID: string;
  String: string;
  Boolean: boolean;
  Int: number;
  Float: number;
};

export type Query = {
  user: User;
};

export type User = {
  email?: Maybe<Scalars['String']>;
  id?: Maybe<Scalars['ID']>;
  name?: Maybe<Scalars['String']>;
  username?: Maybe<Scalars['String']>;
};

We'll later use these types along our codebase. But more interestingly, let's see how our tool generated ready-to-use React hooks (based on the React-Query hooks!) that completely handle data fetching and updating.

For example, let's take a look at the useGetUserQuery hook, that we can use to fetch a single user by passing an ID to it:

import { useQuery, UseQueryOptions } from 'react-query';

export type GetUserQuery = {
  user: {
    id?: string | null | undefined,
    name?: string | null | undefined 
  }
};

export type GetUserQueryVariables = Exact<{
  id: Scalars['ID'];
}>;

export const GetUserDocument = `
    query getUser($id: ID!) {
      user(id: $id) {
        id
        name
      }
    }
`;

export const useGetUserQuery = <
  TData = GetUserQuery,
  TError = unknown
>(
  variables: GetUserQueryVariables,
  options?: UseQueryOptions<GetUserQuery, TError, TData>
) =>
    useQuery<GetUserQuery, TError, TData>(
      ['getUser', variables],
      fetcher<GetUserQuery, GetUserQueryVariables>(GetUserDocument, variables),
      options
    );

Notice how the generator first creates the types it needs based on the schema we provided, as well as on the query document. It then uses those types to create a hook that reutilizes React Query's useQuery and passes down the types as generics, the query parameters as variables, and the fetcher function we saw above, which is responsible for actually making the request.

Using our hooks to fetch data

We are now ready to leverage the combined power of React Query and GraphQL. For demonstration purposes, let's create a component that takes an id as input from the user of our app, calls the useGetUserQuery to fetch a User from our GraphQLZero API and display it on screen.

import React, { useState, ChangeEvent } from "react";
import { useGetUserQuery } from "./_generated";

export const UserDisplay = () => {

  const [userId, setUserId] = useState("1")
  const updateUserId = (event: ChangeEvent<HTMLInputElement>) => {
    setUserId(event.target.value);
  }

  const {
    isLoading,
    data,
    isError
  } = useGetUserQuery({id: userId})

  if (isError || !data) {
    return <span>Error. Please reload page.</span>;
  }

  const { user } = data;

  return (
    <section>
      <h3>Select a User ID between 1 and 10: </h3>
      <input type="number" min={1} max={10} value={userId} onChange={updateUserId}/>
      {isLoading ? 
        <p>Loading...</p>
      : (
        <div className="userRow">
          <h3>{user?.name}</h3>
          <p>User Id: {user?.id}</p>
        </div>
      )}
    </section>
  );
};

Notice how we use useGetUserQuery in a way that is analogous to the use of the common useQuery hook provided by the React Query library. In this case, we just pass the userId state as the id so that every time that it updates, the hook is re-run, and a request is made to our GraphQL backend with it as a parameter! Pretty amazing stuff.

Wrapping it up

We have now seen how we can leverage the combined power of React Query and GraphQL to easily and flexibly handle data fetching and updating. By simply defining our GraphQL schemas and documents and taking advantage of the fantastic GraphQL-Codgen tool, handling our data needs becomes a breeze that really accelerates the development experience, and pushes our codebases to be more maintainable with reusable types and React hooks.

If you have an app that consumes a GraphQL endpoint, be sure to give these tools a try.

Check out the finished demo app and clone the repo to play around with the code.

Thanks for reading!

Using React Query to solve state management in your React app

Juan Pablo Djeredjian — Fri, 15 Oct 2021 16:16:31 +0000

I recently got the opportunity (and the privilege!) of starting a greenfield project at my current company, involving an frontend application for an internal tool. The devs involved had the chance to choose the tech stack that we considered convenient, and we collaboratively wrote an RFC (Request for Comment) and presented it to the rest of the company to open up our choices to discussion.

One of the main points that came up -after settling for React, the lingua franca framework at our company- is how we would handle state management. Our main application uses Redux, but many other alternatives were brought up: MobX, using native hooks (a combination of useReducer + useContext), using Redux plus Redux Toolkit. I even got to know and proposed Recoil, a super exciting project -and definitely a library with one of the best presentation videos I've seen so far.

But our Staff Engineer Zac came up with a different idea. Enter React-Query.

React Query's novel approach to state management

"I haven't used it yet, but I love the different approach it takes to handle state within an application. It basically splits server side state out from client side state and automates a lot of stuff like re-fetching and caching", explained Zac.

The idea clicked with me instantly: most of the state that React apps keep in their store is just a reflection of data persisted remotely somewhere (a User, a list of Posts, Comments, or To-Dos, for e.g.). Only a minor part of it is client-side only, and it almost always corresponds to UI/UX information, like if whether a modal is open, a sidebar expanded, etc.

So the idea behind React Query is taking that majority of server-side state and handling it completely: fetching, re-fetching, storing, cacheing, updating and memoizing it in an all-in-one solution. This separations helps to reduce a lot of the boilerplate that inevitably arises with other combined client- and server-side state management tools (such as Redux).

The library also offers some advanced features like "optimistic updates", in which the library assumes an update to the data will be successful before actually receiving a response from the back-end, and allows to easily roll it back if it fails, making the app seem responsive as a breeze to the user.

Promising enough. We decided that we'd go with it during the Proof of Concept phase of the app and started writing code.

Writing the PoC with create-react-app

As we started working on the frontend way before our backend team had availability to build the services that would provide the data needed for the app, we decided to go forward with setting up our project with create-react-app with its TypeScript template and React Query using JSONPlaceholder as a fake API.

So, let's write some code!

First, we created a new app with create-react-app's CLI and installed react-query:

npx create-react-app react-query-demo --template=typescript
cd react-query-demo
yarn add react-query

The App.tsx component that comes by default looks so:

import React from 'react';
import logo from './logo.svg';
import './App.css';

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.tsx</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
      </header>
    </div>
  );
}

export default App;

Following React-Query's excellent documentation, we first modified that file by wrapping our app with the QueryClientProvider that comes included in the library and created a new component UserList where we will fetch our Users from our fake API.

import React from 'react';
import { QueryClientProvider, QueryClient } from 'react-query';

import './App.css';
import { UserList } from "./UserList"

const queryClient = new QueryClient();

const App = () => {
  return (
    <QueryClientProvider client={queryClient}>
      <div className="App">
        <header className="App-header">
          <h1>React Query Demo</h1>
        </header>
        <UserList />
      </div>
    </QueryClientProvider>
  );
}

export default App;

Let's unpack our changes in that component. We first instantiated a new queryClient instance with the QueryClient constructor that React Query provides. We then passed that instance to the QueryClientProvider with which we wrapped our whole app. This provides a context for our cached data and allows all components wrapped in it to use the querying and updating hooks that the library provides.

We also cleaned up our component a bit, changed the title and added our newly created UserList component, where things start to get real interesting. Let's take a look at it:

import React from "react";
import { useQuery } from "react-query";

interface User {
  id: number;
  name: string;
  username: string;
  email: string;
}

const USERS_KEY = "users";

export const UserList = () => {
  const {
    isLoading,
    data: users,
    isError,
    error
  } = useQuery<User[], Error>(
    USERS_KEY,
    () => fetch('https://jsonplaceholder.typicode.com/users')
  ).then(res => {
    if (!res.ok) {
      throw new Error('Network response failed')
    }
    return res.json()
  }));

  if (isLoading) {
    return <span>Loading...</span>;
  }

  if (isError) {
    return <span>Error: {error?.message}</span>;
  }

  return (
    <ul>
      {users?.map(({ name, username, email }: User) => (
        <div className="userRow">
          <h3>{name}</h3>
          <p>Username: {username}</p>
          <p>{email}</p>
        </div>
      ))}
    </ul>
  );
};

A lot more going on here, but this is where the juice of React Query really shows. Let's unpack all of it.

As we are using JSONPlaceholder's fake API to fetch a list of users, we first create the User interface, a simplified version based on the schema provided by the site. In our case, we will fetch an array of Users and display it to the user.

Within our component, we make use of the main tool that React-Query provides: the useQuery hook. The hook takes two arguments:

a unique query key which is used internally by React Query for "refetching, caching and sharing queries across the application". The library will store the data under this key, in a similar way as data for different reducers are kept under a key name in Redux. In our case, we set it to the USERS_KEY constant, which is simply a string of value "users".
a function that returns a promise that resolves the data, or throws an error.

The second argument highlights one of library's great advantages: since React Query's fetching mechanisms are agnostically built on Promises, it can be used with literally any asynchronous data fetching client, such as Axios, the native fetch and even GraphQL! (we'll expand on how to do this in a subsequent post).

For now, we are using fetch to request a list of Users from the https://jsonplaceholder.typicode.com/users endpoint. Notice that, when using fetch, we must also manually check if the request is successful, and throw an error is if it not, as the second parameter expects the fetcher function to throw when an error occurs, and fetch does not automatically do this. This wouldn't be necessary if we were using Axios, for example.

Note for TypeScript users: React Query allows you to provide, via Generics, the result and error types of its hooks. This is especially useful when creating your own custom hooks, for example:

const useGetUsers = () => {
   return useQuery<User[], Error>('users', fetchUsers)
}

The useQuery hook returns an object, from where we have destructured three properties:

isLoading: a boolean that indicates that the query has no data and is currently fetching.
data: the property that contains the data that the Promise resolved to if the request was successful. In our case, it is an array of Users, and we aliased it to the variable name users just for clarity.
isError: a boolean that indicated that the query encountered an error.
error: a property that contains the error thrown if the query is in an isError state.

We can use these properties to decide what the component should render, depending on the state of the query. We first check if it is in an isLoading state, and render a message accordingly. We then check if it an error occured via the isError boolean, and display the error under error.message . Finally, we can safely assume that query is in isSuccess state and render our list of users.

Updating our server-side state

So far so good, but what about when we need to create, update or delete our remotely stored data? React Query solves this issue with the concept of Mutations and the useMutation hook.

Let's create another component CreateUser that renders a button which POSTs a new user to the API when clicking on it, and add it to our App .

[...]

const App = () => {
  return (
    <QueryClientProvider client={queryClient}>
      <div className="App">
        <header className="App-header">
          <h1>React Query Demo</h1>
        </header>
        <UserList />
                <CreateUser />
      </div>
    </QueryClientProvider>
  );
}

export default App;

This time, we'll use Axios as our HTTP client to highlight React Query's versatility. Let's install it first:

yarn add axios

And let's write the code for our new component:

import React from "react";
import axios from "axios";
import { useMutation, useQueryClient } from "react-query";

import { User, USERS_KEY } from "./UserList";

const exampleUser = {
  name: "John Doe",
  email: "johndoe@gmail.com",
  username: "johndoe1990"
} as User;

const postUser = (user: User) => axios
    .post<User>('https://jsonplaceholder.typicode.com/users', user);

export const CreateUser = () => {
  const queryClient = useQueryClient();
  const { isLoading, mutate } = useMutation(postUser, {
    onSuccess: () => {
      queryClient.invalidateQueries(USERS_KEY);
    }
  });
  const onButtonClick = () => mutate(exampleUser);

  if (isLoading) {
    return <p>Creating User...</p>;
  }

  return <button onClick={onButtonClick}>Click to post a new user</button>;
};

Let's go over what's going on here.

Firstly, we create a hard-coded exampleUser to POST into the fake API when the user clicks on the button. We also create our required mutation function, postUser , which returns a Promise of an Axios Response of a POST call to our /users endpoint, passing in as data the argument of our mutation function.

Inside our component, we'll first initialize an instance of queryClient with the useQueryClient hook, also provided by React Query. This is the same instance created in App.tsx and provided by our QueryClientProvider. We'll make use of it in a second.

And now we make use of the useMutation hook, also provided by React Query, which takes two arguments:

a required mutation function that performs an asynchronous task and returns a Promise. In our case, we pass in the already defined postUser function.
an object with multiple properties:
- an optional mutation key, in a similar way as we defined a query key, to be used internally. We don't need to set one for this example.
- an optional onSuccess callback, that fires when the mutation is successful and is passed the mutation result.
- an optional onError callback that will fires if the mutation fails, and will get the error passed.
- an optional onMutate callback, that fires before the mutation function is fired and is passed the same variables the mutation function would receive. This allows us to do optimistic updates: that is, we can early update a resource (and our UI) in the hope that the mutation succeeds and give our application a "synchronous feel". The value returned from this function will be passed to the onError and the onSettled callbacks, so that we can rollback our optimistic update in case the mutations fails.
- more config properties can be found in the docs.

In our example, we are only setting up an onSuccess callback whose job is to invalidate our "users" query, by calling the invalidateQueries utility provided by our queryClient and passing our USERS_KEY as argument to it. By invalidating this query key in our cache after the mutation is successful, we indicate React Query that the data under that key is outdated and it should refetch it. Thus, the library will automatically re-query our /users endpoint, and will bring back our updated Users list.

The useMutation hook returns an object from where we destructure two properties:

mutate: a function that can be called passing variables to it as parameters and will trigger the mutation defined in the mutation function defined in the hook.
isLoading: a boolean that indicates that the mutation is still pending.

Our CreateUser component will use mutate when clicking on a button, so we create an onButtonClick function that fires mutate passing it our hardcoded exampleUser as an argument. We then use our isLoading flag to show an appropriate message to the user when the mutation is pending, or display the button with a call-to-action otherwise.

And that's it! Try playing around with it in the app. One note though, if you check the Network tab on the DevTools, you'll see that, because we are using a fake API, the POST call to add a user will indeed succeed with status code 201 . However, when React Query refetches the data, (the subsequent GET call that gets fired after we invalidate our query key) the new user won't be in the returned data there as JSONPlaceholder will simply ignore any new data added to it. However, on a real API you would see the User you just posted.

Wrapping it up

We've seen how React Query can handle the fetching of the data, cacheing and updating (via refetching) and provides us with a user-friendly hook to handle the returned data and rendering. Through the use of its query keys, and its simple API, the library can replace a fully fledged state management solution, taking out of your hands the responsibility of writing hundred of lines of boilerplate code, and adding great functionality that you'd otherwise have to write from scratch.

Check out the finished demo app and clone the repo to play around with the code. And don't forget to give the official documentation a read.