 Courses from Rares Matei

Apollo provides a universal GraphQL API on top of your existing services, so you can build new application features fast without waiting on backend changes.

apollo

Apollo, by default, does not assume what a given query might return. Anytime you invoke a query that wasn't invoked before, or it has been invoked, but not with the same variables, Apollo always asks the backend for the results. In some cases, however, we know that a given query can re-use a specific object or list of objects already in the cache.

Implement cache redirect policies to avoid slow network requests for new queries

We're going to complete our note selection example by adding reactive variables to the mix. These can be created via Apollo's "makeVar()" utility. Same as normal variables, they can be instantiated, read, and updated. The difference is that if we return them from "read" field policies, whenever they get updated, they'll signal to Apollo that that particular field has changed, and it should re-render the components.

Use reactive variables to hold local client state in Apollo's cache

In previous lessons, we've looked at defining "merge" field policies, that tell Apollo how new items should be written to the cache. In this lesson, we'll look at "read" field policies, and how they can be useful for putting local client-only state in our Apollo cache, that our components can then query as if they were querying the server.

Use "read" field policies to query local client state

If you help Apollo correctly identify objects, by asking the server for their ID, it will normalise them at the root of the cache. This ensures that instead of duplicating data, all queries and all the other entities just reference that single normalised instance. The more normalised entities and references to those entities you have, the more you'll notice components correctly reflecting updates when mutation are made.

Optimise queries to ensure all entities are normalised in the Apollo cache

Whenever we start up the app, it has to wait on all its initial queries to resolve. Even after that's done, as we click around the app and load new notes in the cache, all of that data is lost on refresh, because it's kept in memory. In this lesson we'll look at using the "apollo3-cache-persist" package, to set-up a syncing mechanism that automatically saves any changes to the Apollo cache in local storage, and then restores it when the app starts. This results in quick start-up times. We'll also look at setting global "cache-and-network" fetch policies that ensure our data is kept fresh and updated with the backend. We'll also set-up a secondary "nextFetchPolicy" that reverts the global query fetch policy back to the default "cache-first" once the app bootstraps.

Provide quick app start-up times by syncing the Apollo cache with local storage

The useSubscription hook completely replaces previous data with any new data coming in. In this lesson, we'll use the "subscribeToMore" function provided on the useQuery hook to append notes pushed to us by the server at the top of our existing notes query. We'll also look at solving a conflict created by our "load more" functionality, which has a merge policy responsible for adding new items at the end of the existing notes query.

Append GraphQL subscription updates to existing queries

While polling for changes is a simple, safe solution, sometimes we'd like updates pushed to us by the server as soon as they happen. We might also like small chunks of updates, rather than re-requesting the whole initial query. In this lesson, we'll look at making GraphQL subscription with the "useSubscription" hook. We'll also set-up a conditional protocol link, that either uses the HTTP or Websocket protocols based on the type of query being attempted.

Subscribe to immediate live updates from your server

In this lesson, we'll look at adding the pollInterval option when making queries. This instructs Apollo to continuously poll the backend and check for changes. We'll also explore some of the pitfalls of this approach, and how we might want to use a larger poll interval, and apply it on queries that do not return large chunks of data.

Keep queries in sync with the backend by polling for new data

You might still have some REST API endpoints that haven't been converted to GraphQL yet. In this lesson, we'll look at adding the RestLink. This allows us to add annotation to our GraphQL queries that tell Apollo to convert and re-direct to a REST endpoint behind the scenes. And since REST has no concept of types, we'll look at how to annotate types as well. This allows us to continue using a single way of querying for data in our components, without mixing fetch REST calls and GraphQL queries. It also provides a smooth upgrade path, since we can just remove the annotations once the conversion to GraphQL is finished on the backend.

Incrementally migrate from REST to GraphQL using the RestLink

In the previous lesson, we were always returning true for whether a note is selected or not. In this lesson, we'll look at how to make that dynamic, based on the ID of the current note being read. For that, we'll explore the "readField" helper that gets passed in to our "read" field policy callback, and use it to read the ID property of the current note.

Use the readField helper to get the ID of items in read field policies

Lists of notes can get very big. We don't want to load all existing notes on the database every time the user loads the app. We'd like to re-create the Twitter timeline experience, and only when the user scrolls to the bottom, then load a few more notes. For this, we'll start off by looking at the fetchMore utility, that is provided by the useQuery hook, to trigger loading of more notes from the server. Then, we'll look at defining a merge field policy, to define how these new loaded notes should be combined with the existing notes. Finally, we'll look at specifying keyArgs for queries, and how it helps us define by which variables to key certain queries in the cache.

Use fetchMore and merge field policies to dynamically load more items into a list

When deleting an item, we express our intent to completely remove all traces of it. If the mutation succeeds, that means it's gone from the backend as well. But some components external to our note list, might still be listening to our deleted item. To ensure they get the update, we can completely evict the normalised instance from the cache using the cache.evict() method.

Evict deleted items from the Apollo cache

In this lesson, we're going to explore the "optimisticResponse" option of Apollo's useMutation hook. Optimistic updates allow us to react immediately in the UI, as if the mutation succeeded. This provides a quick/responsive feeling to the user. Once we get the official response from the server, if it was successful, we leave the UI alone, because it should be unchanged, but if there was an error we need to rollback the optimistic updates we applied. This is where Apollo makes it very easy: as we'll explore in the lesson, Apollo has an optimistic cache layering mechanism, that automatically knows how to rollback any failed updates.

Use optimistic updates to build UIs that react immediately to user actions

In this lesson, we'll look at how to use the cache.modify() utility to manually reach into the Apollo cache and update cached queries. Once a mutation has finished, Apollo will invoke the callback you pass to its "update" option, with any data the mutation returned. We'll use the returned note and the cache.identify() utility to filter out the delete note reference from our notes list inside our cache.modify() invocation.

Manually modify the cache to remove deleted items

When making a mutation to delete an item in Apollo, there is no way to automatically mark that item as deleted based on the mutation return value. It cannot know how to update that were referencing that item now that it doesn't exist anymore. As a simple solution, we can use the refetchQueries option that the useMutation hook accepts, to tell Apollo which queries to refetch from the backend once the mutation has completed.

Handle item deletions in Apollo using refetchQueries

Understanding how Apollo normalises objects and how it stores them in the cache is especially helpful when writing our mutations. We'll see how just by making sure we return the ID of the changed entity from a mutation, plus any updated fields, Apollo will automatically make the necessary updates in the cache and re-render any components listening to that specific chunk of data.

Update the local cache automatically when making mutations

In this lesson we're going to see how the Apollo cache looks like and everything is normalised. Queries just reference normalised entities. Entities are cached by their backend database ID plus their typename, to avoid identifier collisions.

Understand how Apollo stores data in its cache

In this lesson we'll see how to easily make GraphQL mutation using the Apollo useMutation hook. Same as before, we get access to any data the mutation returns, as well as loading and error states.

Make GraphQL mutations with the useMutation Apollo hook

In this lesson, we'll import the RetryLink from Apollo and use it to automatically retry a given query a few times if there's an error. We'll also look at some of the way we can configure the Retry, including whether to jitter the times between retries. Finally, we'll see what links actually are in Apollo, and how it needs a protocol link as the last one in the chain (HttpLink in our case).

Use the RetryLink in Apollo to retry queries after an error

Similar to loading states, Apollo also gives us a simple error object from its useQuery hook. We can use this to handle what to display to the user if there's an error. There's a catch, however: your server might still send you partial data when there's an error, and Apollo blanks this data out by default, so that you don't forget to handle that state. We'll see how to handle this use-case by specifying an errorPolicy.

Handle GraphQL query error states using Apollo

Apollo gives us a simple loading flag from the useQuery hook, which we can use to display a loading spinner. Whenever the request finishes, Apollo will re-render our component so that it can display the fresh data.

Handle loading states for your GraphQL queries

When comparing two visually similar websites, it can often be challenging to precisely identify the subtle differences between them. To facilitate a rapid analysis of these discrepancies, a practical technique involves leveraging Chrome's integrated developer tools to capture full-page screenshots of each site. Subsequently, these screenshots can be uploaded to a platform like AI Studio. There, the AI can analyze the images and generate a report detailing the variations. This entire process, leveraging a few quick shortcuts, can be completed in under a minute, delivering a comprehensive breakdown of the differences for efficient comparison and analysis.

Quickly Compare Two Sites Using AI Studio with Chrome Full Page Screenshots

It's fairly trivial to create a React project, but there's always a big hurdle between creating it locally and making it shareable so that someone else can run it. This lesson walks you through the process of automating creating a React project locally, creating the repository where it's going to be hosted, and creating shareable links where it can be run so that you can quickly and easily create single one-off demos and shoot them over to your friends and coworkers for sharing your code ideas in a working environment.


```bash
share-react-project() {
  if [[ -z "$1" ]]; then
    echo "Usage: share-react-project <project_name>"
    return 1
  fi

  local project_name="$1"
  local github_username=$(gh api /user --jq '.login')

  echo "Creating Vite project: $project_name"
  pnpm create vite "$project_name" --template react

  cd "$project_name"

  echo "Initializing Git repository"
  git init

  echo "Adding all files to Git"
  git add .

  echo "Creating initial commit"
  git commit -m "Initial commit"

  local codesandbox_link="https://codesandbox.io/p/github/${github_username}/${project_name}"

  echo "Adding CodeSandbox link to README.md"
  echo "" >> README.md
  echo "## CodeSandbox" >> README.md
  echo "[![Open in CodeSandbox](https://assets.codesandbox.io/github/button-edit-blue.svg)](${codesandbox_link})" >> README.md

  echo "Adding README.md to Git"
  git add README.md

  echo "Committing README.md changes"
  git commit -m "Add CodeSandbox link"

  echo "Creating GitHub repository: $github_username/$project_name"
  gh repo create "$github_username/$project_name" --public

  echo "Pushing to remote 'origin'"
  git push -u origin main

  echo "Project '$project_name' created successfully!"
  echo "GitHub repository: https://github.com/$github_username/$project_name"
  echo "CodeSandbox link: $codesandbox_link"
}
```

Automate Creating a Local React Project, GitHub Repository, and Live Hosted Demo in a Single Command

[Verdaccio](https://verdaccio.org/) is a fully featured NPM registry that you can run locally on your machine. It’s a great tool for testing your release process, running end-to-end tests, and simulating real-world scenarios like deploying packages, installing them, and verifying functionality as an end user would.

Nx includes a [generator](https://nx.dev/features/generate-code) that simplifies setting up Verdaccio. To configure it, run:

```shell
npx nx g @nx/js:setup-verdaccio   
```

This command installs the necessary NPM packages and creates a `project.json` file with a `local-registry` target. To start the local registry, open a new terminal window and run:

```shell
npx nx local-registry
```

This will:
- Launch the Verdaccio registry.
- Configure NPM to point to the local Verdaccio server at `http://localhost:4873`.

> **Note:** A `project.json` file provides an advanced way to define scripts, offering more flexibility than a traditional `package.json` for managing complex targets.

Setup local Verdaccio server to release NPM packages

Learn how to spin up a local NPM registry powered by Verdaccio to test deploy your NPM packages.

In TypeScript, developers often begin by defining the structure of their data using type definitions or interfaces, which is a powerful way to ensure type safety. However, as applications grow and become more complex, simply defining the shape of an object might not be enough to guarantee its consistent creation and behavior throughout the codebase. This often leads to situations where objects that are intended to be of a certain "type" might be missing crucial properties or have incorrect data, which can be difficult to track down and debug.

This lesson tackles the question of when and why to move beyond basic type definitions and embrace classes in TypeScript. It demonstrates how classes provide a more robust mechanism for defining object structure, enforcing type constraints, and ensuring consistent object creation. By establishing a clear blueprint for objects, classes not only improve compile-time type safety but also offer runtime benefits and better code organization, ultimately helping developers avoid common pitfalls associated with loosely structured objects in larger TypeScript projects.

Stop Avoiding Classes in TypeScript

Karabiner isn't only for your keyboard. It can also hijack your mouse buttons and enable them to be similar to layers on your keyboard, where holding down a mouse button can allow you to tap keys on your keyboard to trigger commands and macros that can completely revolutionize your workflows. For example, you can hold down the right mouse button and tap on R to go to references in VS Code. Or hold down the right mouse button and tap the left mouse button to chop up videos and Screenflow.

This completely unlocks a whole new world of possibilities and use cases for your mouse as you can hover your mouse over anywhere on the page. And just tapping keys on your keyboard allows you to trigger mouse actions, to trigger keyboard actions, or to trigger macros and applications and terminal commands. and anything that your imagination can come up with. 

Karabiner: Rethinking Right-Click as a Macro Command Center

Make an HTML table more readable on mobile devices by using the ::before pseudo-element. We add labels to each cell, so they appear like cards when the table is viewed on smaller screens. The ::before content is set using a data-label attribute for each cell to enhance mobile viewability without horizontal scrolling.



Create a mobile friendly table with the before pseudo-element

Learn to use CSS ::before pseudo-element for mobile-friendly HTML tables. Add labels to cells for enhanced readability on mobile, avoiding horizontal scroll.

Any app of a decent size has event flows and messages being passed around. At a certain point it becomes complicated to explain it through prose and you want to turn towards diagrams. Now setting aside the time to create diagrams that accurately describe what's happening in your codebase can be quite time consuming. Luckily, with today's AI tools, we can now just do basic walkthroughs with rough recordings over codebase dictating what's going on along the way and then upload that to tools like AI Studio and then ask it to generate diagrams in a text-based format such as Mermaid that will then generate the flowcharts and diagrams for us. So this video walks us through this process of recording a rough video, uploading it to AI Studio and then asking AI Studio to generate the proper Mermaid diagram syntax.

Generate Mermaid Flow Chart Diagrams with Gemini 2.0 from Rough Screen Recordings

I'm a diehard Karabiner user and anytime I start doing something repetitively I always move it into my Karabiner configuration. Sometimes I'll fall into scenarios where I want to trigger a command, but I also want to know if that command succeeded or failed. Since Karabiner can trigger any command, setting up the command is fairly straightforward, but knowing whether it succeeded or failed became much more difficult. Luckily for me there is a package called terminal-notifier that you can install from homebrew and you can pipe the output of your command to terminal-notifier. And have a seamless way of triggering your keyboard shortcut which runs a command and you can be notified of the results.

Use Karabiner to Trigger a Terminal Command and Get Notified of the Results

There are a lot of scenarios when inspecting a site in Chrome where you don't want any click events to fire and you don't want any scripts to run. Or maybe something is animating in and out of the page and you want to capture it at a certain moment. This is a great use case for pausing script execution, which is kind of using the debugger manually by going into the Chrome DevTools and the Sources tab and clicking the pause button to essentially pause the entire page. This will give you a chance to inspect any of the elements and styles you want to inspect. And you don't have to worry about fire and click events or anything that might interrupt your investigation into the elements and styles that you want to find.

Pause Script Execution in Chrome to Easily Inspect Elements

Gemini 2.0 has a context window of a million tokens, and this means that you can upload hundreds of files and allow it to inspect and analyze massive refactors across entire code bases. 

This lesson demonstrates concatenating an entire code base into a single file and then uploading it to AI Studio. Once within AI Studio, we ask it to find the types of tasks that it can evaluate for us. Then we select one of the tasks and ask it to generate instructions for that task. Once those instructions are complete, we then turn them over to Windsurf's Cascade agent, and we allow Windsurf's Cascade to do all of the work for us as we sit back, relax, and let the AI do our jobs.

Rares Matei

Search Results