Learn Git, Jest and Ruby

Next.js is a minimalistic framework for server-rendered React applications.

This project is a Next.js example of Kent C Dodd's Frontend Masters Advanced Remix Workshop project.

The aim of this project and course is to take a large project using the traditional Next.js pages architecture and migrate the full project to use the new app directory architecture.

We will fork project repo and clone it to get setup with the project locally. 

Fork and Clone the Next.js 13 Project to Get Started

jest

Jest is a fast and safe testing framework with a focus on simplicity. 
This lesson will walk you through how to add jest to your application by running `yarn add --dev jest` followed by updating your `package.json` to be able to run your tests on the console by using the `yarn test` script.
This lesson covers how to create your first test by creating your first block that groups several related tests with `describe` and then adding your first test method using either the `it` or `test` keyword.

Add Jest to Your Application and Create Your First Test

The pluggable linting utility for JavaScript and JSX.

eslint

We can leverage GitHub Actions to automate the running of all of our accessibility auditing tools as part of a Continuous Integration (CI) workflow. 

Auditing tools will only catch a percentage of potential accessibility issues, it is no replacement for manual testing.  But being able to automate the auditing will add efficiencies to our testing and provide an early warning system that can be run much more frequently than it’s practical to perform manual testing.  Additionally, we can use our CI suite as a safety net to prevent code changes that break accessibility from being able to be merged.

## Resources
* https://app.egghead.io/lessons/react-set-up-eslint-to-audit-accessibility-issues-in-react
* https://docs.cypress.io/guides/continuous-integration/github-actions#Basic-Setup
* https://github.com/cypress-io/github-action

Automate Accessibility Audits with GitHub Actions

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

We can add accessibility testing to our `jest` unit tests with `jest-axe` which gives us:

* An easy way to automate accessibility auditing
* the flexibility to audit at any level of our code, as low as an element and as high as a component representing an entire page of our app
* A safety net for any accessibility regressions

Here we'll see how to use `jest-axe` with `react-testing-library` to render the components for `jest-axe` to audit for accessibility.

The React Testing Library is a very light-weight solution for testing React components. It provides light utility functions on top of react-dom and react-dom/test-utils, in a way that encourages better testing practices.

## Resources
* jest-axe: https://github.com/nickcolley/jest-axe
* react-testing-library: https://testing-library.com/docs/react-testing-library/intro/

Write Better Unit Tests with react-testing-library and jest-axe

We can add accessibility testing to our `jest` unit tests with `jest-axe` which gives us:

* An easy way to automate accessibility auditing.
* The flexibility to audit at any level of our code, as low as an element and as high as a component representing an entire page of our app.
* A safety net for any accessibility regressions.

Here we'll see how to use `jest-axe` with `enzyme` to render the components for `jest-axe` to audit for accessibility.

Enzyme is a JavaScript Testing utility for React that makes it easier to test your React Components' output. You can also manipulate, traverse, and in some ways simulate runtime given the output.

## Resources
* jest-axe: https://github.com/nickcolley/jest-axe
* enzyme: https://enzymejs.github.io/enzyme

Write Unit Tests for Accessibility Using jest-axe and enzyme

We can add accessibility testing to our `jest` unit tests with `jest-axe` which gives us:

* An easy way to automate accessibility auditing.
* The flexibility to audit at any level of our code, as low as an element and as high as a component representing an entire page of our app.
* A safety net for any accessibility regressions.

Here we'll see how to use `jest-axe` with `ReactDOM` to render components for `jest-axe` to audit for accessibility.

## Resources
* https://github.com/nickcolley/jest-axe

Render Components with ReactDOM to Write Tests with Jest and jest-axe

Best practices for building & testing redux applications have changed dramatically over time. This course aims to be a comprehensive yet understandable resource for those seeking to improve the testing of their redux applications.

This course is broken up into three parts.

The intro is look at how to add jest to an existing react redux application that was built on top of [vite](https://vitejs.dev/). We cover basic functionality like [watch mode](https://jestjs.io/docs/cli#--watch) and generating and using [code coverage](https://jestjs.io/docs/cli#--coverageboolean) to inform our testing strategy.

The first section covers the specifics of unit testing the redux code in our application. We'll go over how to test reducers, selectors and thunks. As part of this we'll touch on mocking APIs and using [Redux Mock Store](https://github.com/reduxjs/redux-mock-store) as well as running actions through our applications' actual reducers to broaden our test coverage.

Finally we'll look at how we can test our redux connected react components using the various utilities that come with the [React Testing Library](https://testing-library.com/docs/react-testing-library/intro/). We'll cover simulating various kinds of user input with the [user-event module](https://testing-library.com/docs/ecosystem-user-event), populating our redux store with test data, using [jest spy](https://jestjs.io/docs/jest-object#jestspyonobject-methodname), how to wait for asynchronous tasks to complete, and several approaches for finding & asserting that visual elements exist on the page.

This course is built on top of content that was created for the [Modern Redux with RTK and TypeScript](https://app.egghead.io/playlists/modern-redux-with-redux-toolkit-rtk-and-typescript-64f243c8) course and I highly recommend you start there if you haven't completed it already. 

I'm confident you will level up your redux testing abilities if  watch these lessons and practice coding each of them as you go.

Intro to Confidently Testing Redux Applications with Jest & TypeScript

Intermission Pep Talk - Testing Redux Applications

The [reselect module](https://github.com/reduxjs/reselect) popularized a pattern of memoized redux selectors. Now that pattern is baked into Redux Toolkit with its [createSelector](https://redux-toolkit.js.org/api/createSelector) method, which is used by the `getMemoizedNumItems` selector we're testing here.

Any selectors created with `createSelector` come with these two additional methods `recomputations()` and `resetRecomputations()`. These methods keep track of how many teams your data was recomputed and are essential for testing these selectors.

Some additional examples on testing memoized selectors can be found here:
https://github.com/reduxjs/reselect#q-how-do-i-test-a-selector



----

The createSelector method first takes any number of "input selectors" which gather data from your redux store and then for its final arguments takes an additional selector which has for its inputs the result of those input selectors.

The memoization is broken if either the initial state is unchanged OR if the any of the  results of the input selectors are unchanged. It uses `===` equality and not any sort of nested equality checking so `state` and `{ ...state }` would not be considered the same and always would recompute. On the flip side passing in `state` and then running `state.count++` would not trigger a recompute automatically, because the `state` object reference has not changed and `===` would pass. It definitely tripped me up a few times, so keep an eye out for issues with this.




Unit Testing a Memoized Redux Selector Built with Reselect/RTK

Redux is a predictable state container for JavaScript apps.
It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test.

redux

There are several ways to mock APIs for our tests.

Here we're using [jest.mock](https://jestjs.io/docs/es6-class-mocks#calling-jestmock-with-the-module-factory-parameter) with the module factory parameter to a new mocked module to replace our original. This helps us avoid problems like servers taking a long time and node.js not having fetch built-in.

When using mocks this way it's important to note that this mocked module is only going to show up for the tests executed in this file. Other test suites will continue to receive the original implementation of app/api. 

Other approaches to mock APIs include mocking out `window.fetch` or using [Mock Service Worker](https://mswjs.io/docs/getting-started/integrate/node) to provide a more robust API implementation. However, the approach we took here makes sense for our use case. We have a simple API surface, it lives in a single file, we never call `fetch` directly and we don't need a lot of bells and whistles (like responding to different routes or query parameters). So for that reason this approach and the [spyOn](https://jestjs.io/docs/jest-object#jestspyonobject-methodname) approach used in some of the later lessons actually works really well.

If you're using [Apollo](https://www.apollographql.com/) or [ReactQuery](https://react-query.tanstack.com/) or [SWR](https://swr.vercel.app/) to handle your data, then you almost certainly should use [Mock Service Worker](https://mswjs.io/docs/getting-started/integrate/node) instead of the jest.mock approach.

Mocking out our API Helper with jest.mock

Code coverage is an important part of any test setup. One of the jest framework's innovations is built-in test coverage support. In this lesson I demonstrate using the [collectCoverageFrom](https://jestjs.io/docs/configuration#collectcoveragefrom-array) configuration option to improve jest's coverage support for TypeScript files and then demonstrate using `npx jest --coverage` to run code coverage as well as `npm test -- --coverage`, which does the same thing.

At the end I briefly mention the [collectCoverage](https://jestjs.io/docs/configuration#collectcoverage-boolean) flag which seems like you'd want to always just have on, but in practice is annoying. That's because coverage takes several extra to process and I rarely need my code coverage run, so it just makes the testing feedback loop a lot slower. For a build-only config it might make sense to leave on.

----

There's a [pretty good question on stackoverflow](https://stackoverflow.com/questions/43046885/what-does-do-when-running-an-npm-command) that covers using `--` with `npm test` that you might want to check out.

Here's an explanation of [how npx differs from npm](https://medium.com/@maybekatz/introducing-npx-an-npm-package-runner-55f7d4bd282b).


Configuring Code Coverage for TypeScript Files in Jest

Jest has a [watch mode](https://jestjs.io/docs/cli) that can really speed up test development. It will automatically run your tests as you save your test files. And it has a built-in pattern option to allow you to only focus on tests for a particular file. This approach works well in combination with [test.todo](https://jestjs.io/blog/2019/01/25/jest-24-refreshing-polished-typescript-friendly#testtodo) where you can stub out a number of tests and then code on them until they all pass.

Most of what is being done in these tests we've already seen before and it's important to note that I'm doing only the most basic of testing here. For each of these actions it wouldn't be uncommon in production to have 3-6 tests instead of just one.

It's important to note that `it` and `test` are aliases of one another so `it.todo` and `test.todo` both work seamlessly and are just a matter of preference. *Usually* when I'm doing unit testing I'll stick with `describe` and `it`, which commonly go together and I use `test` without `describe` when I'm testing react components with [React Testing Library](https://testing-library.com/docs/react-testing-library/intro).

Using Jest in Watch Mode with test.todo to Test a Redux Reducer

The app is built on top of [vite](https://vitejs.dev/) instead of the more popular [create react app](https://reactjs.org/docs/create-a-new-react-app.html). The benefit of vite is that it installs and builds extremely quickly. One of the downsides of vite is that it doesn't come with any out-of-the-box testing support. It also has its own [esbuild-based compiler](https://vitejs.dev/guide/features.html#typescript), which is not currently compatible with jest, so we have to configure JSX & TypeScript support for jest even though `vite` handles that already for our app.

This lesson requires installing a handful of modules:
```
npm install -D jest
npm install -D @testing-library/react @testing-library/jest-dom @testing-library/user-event
npm install -D @babel/preset-react @babel/preset-typescript @babel/preset-env
npm install -D identity-obj-proxy
```

Each of them serves an important purpose:

- [jest](https://jestjs.io/) _runs our tests_
- [@testing-library/react](https://testing-library.com/docs/react-testing-library/intro) adds the ability to render react components inside of our test environment
- [@testing-library/jest-dom](https://github.com/testing-library/jest-dom) _allows us to assert that components are in the DOM and contains certain text and classes_
- [@testing-library/user-event](https://testing-library.com/docs/ecosystem-user-event) _allows us to interact with rendered components programmatically_
- [@babel/preset-react](https://babeljs.io/docs/en/babel-preset-react), [@babel/preset-typescript](https://babeljs.io/docs/en/babel-preset-typescript), and [@babel/preset-env](https://babeljs.io/docs/en/babel-preset-env) allow us to use ES6 Modules, JSX, and TypeScript in our tests
- [identity-obj-proxy](https://github.com/keyz/identity-obj-proxy#identity-obj-proxy---) is helpful when rendering CSS modules so that we can see the original class names instead of obfuscated ones

We also have to add numerous config files such as `babel.config.js` and `jest-setup.ts` which are required to enable all of this functionality.

We put our `jest` config in our `package.json` file which works well, but you can also put it in a file named `jest.config.ts` or `jest.config.js`. See the [Jest Configuration Documentation](https://jestjs.io/docs/configuration) for more details about configuring jest.



Adding Jest with TypeScript Support to a Vite Application

In this lesson we go after the elusive goal of 100% test coverage by testing a few additional cases: error responses, empty error messages and the pending state that should exist between checkout being clicked and the API returning data.

The first two require special handling in our mock API:

```typescript
if (items.evilItem > 0) throw new Error();
if (items.badItem > 0) return { success: false };
```

In some ways these are arbitrary examples that may not exist in your other applications, but I wanted to demonstrate the fact that there are a lot of different ways an API might decide to communicate errors.

In general with AJAX calls a non-200 status response often gets thrown as an error and treated as an error case, but some APIs (such as graphql) include errors as part of a normal `200` response and need special handling. These lessons are meant to demonstrate what that might look like in your mocks.

Now it's useful to reiterate here that our simple API interface makes writing these mocks very easy, but in many cases something like [Mock Service Worker](https://mswjs.io/docs/getting-started/integrate/node) is a more appropriate way to mock out an API.

For our "pending" test, it's interesting what we lose when we stop focusing on actions fired (like in our previous 2 lessons) and instead focus purely on the resulting state. It makes looking at the intermediary state a bit more difficult. Here we work around that by calling `store.dispatch(thunk)` and saving the results of that to an `action` variable, which we `await` after doing an initial assertion. That `await` triggers our mock API to respond, so we can use the space between `dispatch` and `await` to peak into the pending state.

Additional Redux Thunk Unit Tests for Increased Code Coverage

In a lot of ways plain selectors like we're testing here are extremely simple to reason about. The only thing that's a little tricky is even though they're often written side-by-side with a reducer, they accept the `RootState` instead of the reducer state. When writing these tests with TypeScript you often find yourself using `as` to cast partial state into full `RootState` type.

Here we're doubly nesting our `describe` blocks and it works great and makes our test output nicely formatted.

Unit Testing a Basic Redux Selector

For this lesson we focus on running our thunks through our app's reducer methods to test both the thunks and the reducers in a single test. Testing our thunks this way gives us more confidence they are working exactly as we expect and its less code for us to write. The main challenge we face in using our redux store this way is that we need to preload it with state.

To make that simpler we create two helper utilities: `getStoreWithState()` and `getStateWithItems()`. We're going to continue to use these utilities throughout our lessons. 

You'll notice I keep referring to the generated store as our "real redux store", even though we aren't relying on the `store` variable but generating a new store with the same reducers. What I really mean here is that our store has the same middleware and reducers as our app's store. Generating a new store for each test is important so that they can have their own state that don't conflict with other tests.

**Note**: It's also possible to generate the app's `store` variable with `getStoreWithState()`, but it makes the TypeScript syntax more complex and it seemed like it wouldn't add a lot of value.

Unit Testing Redux Thunks and Associated Reducer Methods using Your App's Redux Store

[Redux Mock Store](https://github.com/reduxjs/redux-mock-store) is a library that provides two important capabilities. 1. It makes it easy to pre-load state. 2. It keeps track of which actions were fired. We take advantage of both here for testing our thunk, in what amounts to just a slightly cleaner approach than using `jest.fn()` as we did in our previous lesson.

[Redux Mock Store](https://github.com/reduxjs/redux-mock-store) is more commonly used as a way to test redux-connected components, but also works anytime we need an easy way to confirm that certain actions are fired into our redux store.


While it does make it easy to populate a redux store and inspect which actions were fired, redux mock store doesn't have any reducers, so you can't use it in tests where you want your components to update in response to any actions. It's strictly a read-only store. Another challenge of using redux mock store is that it needs to be configured separately from your primary redux store. There may be cases where you'll have a middleware on your production redux store, but forget to add it to your mock store, leading to tests that don't match the behavior of your application. For these reasons I think it's generally better run both unit and integration tests against a store with your actual reducers hooked up when at all possible.

Unit Testing Redux Thunks using Redux Mock Store

The [reselect module](https://github.com/reduxjs/reselect) popularized a pattern of memoized redux selectors. Now that pattern is baked into Redux Toolkit with its [createSelector](https://redux-toolkit.js.org/api/createSelector) method, which is used by the `getTotalPrice` selector we're testing here.

Any selectors created with `createSelector` come with these two additional methods `recomputations()` and `resetRecomputations()`. These methods keep track of how many times your selector was recomputed and are essential for testing.

The createSelector method first takes any number of "input selectors" which gather data from your redux store and then for its final arguments takes an additional selector which has for its inputs the result of those input selectors.

A cached response will be used, if one exists, when either the root state passed in to the selector is unchanged or if any of the results of the input selectors remain unchanged between calls. It uses `===` equality and not any sort of nested equality checking so `state` and `{ ...state }` would not be considered the same and would always recompute. On the flip side passing in `state` and then running `state.count++` would not trigger a recompute automatically, because the `state` object reference has not changed and `===` would remain true. Writing tests for my memoized selectors definitely helped me better understand this behavior.

Some additional examples on testing memoized selectors can be found here:
https://github.com/reduxjs/reselect#q-how-do-i-test-a-selector




Unit Testing a Memoized Selector that Derives Data from Multiple Reducers

How to properly test thunks seems to be the source of a lot of confusion. Usually an API needs to be mocked and then there are numerous ways to actually run the tests. This lesson showcases the most basic approach which relies on [jest mock functions](https://jestjs.io/docs/mock-functions) and avoids hitting a redux store or reducer. 

For this lesson we're testing a thunk created using Redux Toolkit's [createAsyncThunk](https://redux-toolkit.js.org/api/createAsyncThunk) method. The test should continue work completely untouched even if we build the thunk by hand.

The [mock property](https://jestjs.io/docs/mock-functions#mock-property) of the `jest.fn()` we create here for our mock dispatch ends up doing most of the work. The nested array inside of the `calls` property measuring first "times called" and then "arguments passed" is a little bit confusing, but extremely powerful!

My least favorite part of this was needing to pass the third `extra` argument to our thunk to satisfy TypeScript. The other frustrating part was having to build a complete `RootState` object to pass into our `getState` method. We'll solve that in a later lesson by creating a `getStateWithItems` helper.

Unit Testing Redux Thunks with a Mock Dispatch Function

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Getting started with contributing to open source projects can be very confusing and stressful. This talk will help clear away the confusion and pinpoint why and how you can make your first open source contribution. 



How to Make Your First Open Source Contribution

It always happens again. We have some weird bug in our codebase, hard to debug and just looking at the Git history doesn't help much. Git has a powerful command to help us: `git bisect`.

We have to simply identify a commit where the bug was not present, and the bad commit (usually the latest of the `master` or `main` branch). Then we invoke `git bisect` with both of them. The rest is just following along and answering questions. Let's see how that works.

Find that bad commit that broke your App with Git Bisect

TypeScript's satisfies operator finally clicked for me when I realized it's almost always used for specific implementations of configuration objects. So this lesson walks you through the naive approaches I've taken before and how to solve them using the satisfies operator. After this, satisfies will be another tool in your belt in TypeScript. To clean up all the TypeScript code you have around configuration.

TypeScript's "satisfies" for Configuration

Windsurf and Cursor are both able to take an image and then use an agent to build out what it sees in that image. This lesson is going to compare Windsurf and Cursor by uploading the same image to both and giving them the same prompt. Comparing not only the results, but also the steps that they take to get there. We'll also try uploading additional images throughout the process to see what they do as far as revising along the way and improving the site as they go along. 

Windsurf Cascade vs. Cursor Composer Agent: Build a Site from an Image

In this lesson, you'll discover how to style View Transitions using CSS pseudo-selectors to create custom animation effects. We'll transform the default cross-fade into a smooth slide transition by targeting the ::view-transition-old and ::view-transition-new pseudo-elements. You'll learn how these powerful selectors give you precise control over your transition animations, allowing you to create more engaging and personalized user experiences with just a few lines of CSS.

Customize View Transitions with CSS Using view-transition-old and view-transition-new

In this lesson, you'll learn how to implement smooth state transitions in your web applications using the browser's built-in View Transitions API. We'll create a simple example that demonstrates how to animate between different text states with just a few lines of code - no external libraries required. This powerful native API makes it easy to add professional-looking transitions to your user interface, enhancing the user experience with minimal effort.

Create Smooth UI Transitions with the Native View Transitions API

I've been using Cursor for a very long time and their "Agent" feature in Composer is fairly new, so I'm still getting used to it. But since Windsurf recently got onto the stage with their Cascade agent, they've slowly been gaining the mind share on the UX for coding agents. I decided to put them to the test by putting Windsurf and Cursor on the exact same screen side by side trying to accomplish the same task and to see which workflow I would prefer. I've been a diehard Cursor user for over a year now, so it's going to take a lot for me to switch to a different IDE. But I just have to say, even from this simple demo, Windsurf is looking pretty nice.

This lesson is just going to walk through creating a CLI using both tools to print out inspirational quotes and to explore how they approach the step-by-step of installing packages and running commands and setting up all the files we need to get this running.

Windsurf Cascade vs. Cursor Composer Agent Side-by-Side Comparison

This TypeScript tutorial explains how to use generics, allowing for different types to be passed as arguments. It discusses the use of shorthand syntax in generics and illustrates with examples. This method is useful for library creation, providing type safety and control to the user.

```typescript
interface PhotoMetadata<T> {
  title: string;
  takenAt: Date;
  customData: T;
}

// Function that processes a photo with custom metadata
function processPhoto<T>(photo: PhotoMetadata<T>): {
  processedTitle: string;
  daysSinceCapture: number;
  customDataSummary: T;
} {
  const today = new Date();
  const daysSinceCapture = Math.floor(
    (today.getTime() - photo.takenAt.getTime()) / (1000 * 60 * 60 * 24)
  );

  return {
    processedTitle: photo.title.toUpperCase(),
    daysSinceCapture,
    customDataSummary: photo.customData
  };
}

// Example usage with different custom data shapes
type CameraSettings = {
  iso: number;
  aperture: string;
  shutterSpeed: string;
}

type LocationData = {
  latitude: number;
  longitude: number;
  locationName: string;
}

// Using with camera settings
const photoWithCamera: PhotoMetadata<CameraSettings> = {
  title: "Sunset at beach",
  takenAt: new Date('2024-01-15'),
  customData: {
    iso: 100,
    aperture: "f/2.8",
    shutterSpeed: "1/1000"
  }
};

// Using with location data
const photoWithLocation: PhotoMetadata<LocationData> = {
  title: "Mountain vista",
  takenAt: new Date('2024-02-01'),
  customData: {
    latitude: 45.5231,
    longitude: -122.6765,
    locationName: "Mount Hood"
  }
};

const processedCameraPhoto = processPhoto(photoWithCamera);
const processedLocationPhoto = processPhoto(photoWithLocation);

processedCameraPhoto.customDataSummary.iso
processedLocationPhoto.customDataSummary.longitude

```

Basic Explanation of Typescript Generics

A very basic explanation of generic function arguments

I've been using Cursor as my primary editor for over a year now, but recently I've heard wonderful things about Windsurf AI Agent features. I decided to record myself building out something I've always wanted to make, but never made the time for.

In this lesson, I demonstrate how to leverage Windsurf's powerful agent process to create a fun word-guessing game inspired by Heads Up. Watch as I build an interactive application featuring category selection and word navigation, complete with data hosting on GitHub Gists and deployment to GitHub Pages - all in under 30 minutes (before editing the lesson down to 12 minutes)!

What makes this project particularly exciting is how Windsurf eliminates the typical friction points of development. While this game was always on my project wishlist, the overhead of setup, configuration, and deployment made it hard to justify the time investment. Windsurf's agent process handles all these pain points seamlessly, from managing URLs to orchestrating deployment.

This lesson perfectly showcases how AI agents can help developers bring their backlog of project ideas to life, transforming what would typically be time-consuming tasks into efficient, enjoyable development experiences.

Build a Word Game with Windsurf's Cascade AI Agent



Discover how to harness the power of Cursor IDE's Composer Agent feature to optimize your code. In this lesson, you'll witness an AI agent doing all the work to generate test suites, implement performance benchmarks, and create optimized function variations - all without writing a single line of code. You'll learn how to validate performance improvements through data-driven benchmarking, ensuring that optimizations are backed by concrete metrics rather than speculation. This hands-on demonstration showcases a groundbreaking approach to automated function development that combines the precision of test-driven development with the efficiency of AI-powered optimization.


Agent-Driven Development in Cursor: Testing, Benchmarking, and Optimizing Functions

This course is aimed for using `zod` effectively in projects based on TypeScript (both browser and node.js). The benefits you gain with this course is not just simply coding, but also understanding when/why/how should you perform runtime validation.

`zod` is the missing piece to TypeScript's capabilities, which can guarantee type-safety only in compile-time.

`zod` can be used whenever the compiler cannot guarantee what happens in runtime. And... it's a very frequent usecase, such as HTTP calls, websockets, etc.

In this course you get quickly up and running by:
1. using `zod` with primitives and objects
2. adapting `zod` quickly to existing projects thanks to automatic generators
3. changing the strategy frm type-first to schema-first
4. using error-throwing `parse` or non-error-throwing `safeParse` basing on your needs
5. applying `zod` to the most common usecase - validating API responses
6. handling errors the most convenient way (out of many!)

Take advantage of runtime validation with `zod`. Take advantage of the detailed lessons in this course 🔥

Effective Runtime Type Checks with Zod


Cursor can now automatically run commands in the terminal and walk step-by-step towards building out your entire project. You give it a goal, then it will suggest the commands you need to run and the files that you need to create and you can work with it to achieve what you're building. This lesson does a quick walkthough of using a Cursor Agent to build a project from scratch and guide it along the way. Cursor Agents definitely feel like a sneak peek at the future of programming!

Search

Search Results