Learn Auth0, React-native and Vscode

React Native lets you build mobile apps using only JavaScript. It uses the same design as React, letting you compose a rich mobile UI from declarative components.

react-native

Use Expo Orbit to install past builds from EAS as well as from your local machine.

You can also use Orbit to easily view and launch all your connected simulators, emulators and physical devices.

🔗 [Expo Orbit](https://docs.expo.dev/build/orbit/)

Use Expo Orbit to Install Past Builds

Reconfigure your eas.json and app.json so you can install the development, preview and production builds all on the same device.

An app on your phone is uniquely identified by the bundle identifier on iOS and the package on Android, so to make the builds unique we have to make these IDs different based on the build profile.

📖 [Docs](https://docs.expo.dev/build-reference/variants/)

Install Multiple Variants of Your iOS and Android Apps on the Same Device

Set up credentials to upload your Android build to Google Play automatically.

For automatic uploads, you'll need to set up all the app metadata on your Google Play account, including setting up app assets. You'll also need to configure and set up a Google Service Account.

📝 [Create a Google Service Account](https://github.com/expo/fyi/blob/main/creating-google-service-account.md) 
📝 [Store Assets](https://docs.expo.dev/guides/store-assets/)
📝 [EAS Submit Docs](https://docs.expo.dev/submit/introduction/)

Upload an Android App to the Google Play Store Automatically using Expo Publish

Set the build number to increment automatically and learn when to increment version numbers.

While you’re developing your app, when you submit an app with a specific version + version code to the App or Play Store, you cannot submit another app with the same values.

The best practice is to set the build number to increment automatically.

The version number can be incremented manually after each store release.

📖 [Docs](https://docs.expo.dev/build-reference/app-versions/)

Increment Version and Build Numbers for iOS and Android apps using EAS

Create the app on the Google Play Store, create the first production build on EAS, upload it to Google Play, and publish it to an internal testing group.

For sharing apps via Google Play, you will need a paid Google Play developer account. It is preferable to have an organisation account if you're looking to monetise your app (you'll need to verify your organisation before you can create apps). But if you you are building apps as an individual developer, you can use the individual developer account. 

When creating an individual developer account, you have some additional restrictions:
1. You must submit proof of ID and home address to create the account
2. If you want to monetise your apps, your home address will be shown on the Google Play developer page
3. You will need 20 testers to test your app for 14 days before you can apply for production access

🎮 [Google Play Console](https://play.google.com/console)

🔗  [Register for a Google Play Developer account](https://support.google.com/googleplay/android-developer/answer/6112435)

🔗 [Required information to create a Play Console developer account](https://support.google.com/googleplay/android-developer/answer/13628312?hl=en-GB)

🔗 [QR Code Generator](https://www.qr-code-generator.com/)


Create an Android Release Build with EAS and Upload to Google Play Store

Create an Internal Distribution (Preview) build for sharing your app in internally in production mode.

This can be used to share your build with your team or testers without submitting it to Google Play.

📝 [Docs](https://docs.expo.dev/build/internal-distribution/)

Create an Internal Distribution Build for Android with EAS

Create a Development Build that runs on Android Emulator or Device.

This build can be used for local development on Android. You can use the same apk (the build artifact) on both an Emulator (that you can install via Android Studio) or on a real android device.

🔗 [Expo Website](https://expo.dev/)

📝 [Docs](https://docs.expo.dev/build/introduction/)

🔗 [Android Studio](https://developer.android.com/studio)

Create a Development Build for Android with EAS

Submit your Production Build to the Apple App Store and install it via TestFlight.

When submitting a build to Apple with EAS Submit (or otherwise), it will first get added to TestFlight which is essentially a pre-prod environment for Apple. This will allow you to install and share the actual production build to testers before releasing it to users.

App names on the Apple App Store must be globally unique. So if you've chosen a name for your app that is already taken - like Plants - you will have to choose a different name for the App Store Listing page. Note that this is only the case for the app name on the App Store listing page, and you can still use your preferred name elsewhere.

**TestFlight Internal Testing** - as soon as you upload your build to App Store Connect and it finished processing, it is available for internal testing. You can add users to the internal testing group by email, and the users must be registered on your Apple Developer account.

**TestFlight External Testing** - this is a separate testing group that allows you to share the build with anyone either by sending them an email invite or using an invite URL. Before you can share the build, you must first submit a build for external testing and wait for it to be approved by Apple, which usually takes a couple of hours.

**Release** - in order for the build to actually show up on the Apple App Store, you will need to create a Release on App Store connect and submit it for review. This review usually takes about a day.

🔗 [TestFlight](https://developer.apple.com/testflight/)

📝 [EAS Submit Docs](https://docs.expo.dev/submit/introduction/)

📝 [App Store Assets Docs](https://docs.expo.dev/guides/store-assets/)

Submit an iOS App to the Apple App Store and TestFlight using EAS

Create an iOS Release build for distribution.

This build gets submitted to the Apple and can only be installed via TestFlight or the App Store.

Create an iOS Release Build for the Apple App Store with EAS

Create an Internal Distribution (Preview) build for sharing your app in internally in production mode.

This is the only way to share your iPhone app without submitting it to TestFlight and is often used for QA testing or internal demos.

📝 [Docs](https://docs.expo.dev/build/internal-distribution/)

Create an Internal Distribution Build for iPhone with EAS

Create a build to run on your physical iPhone device that can also be used for local development.

📝 [Enabling Developer Mode](https://docs.expo.dev/guides/ios-developer-mode/)

📖 Further reading: [Push Notifications Docs](https://docs.expo.dev/push-notifications/overview/)

Create a Development Build for iPhone With EAS

Set up a Distribution certificate and an Ad Hoc provisioning profile for iOS internal distribution builds.

Here we learn how to sign Apple app builds to make them installable on Apple devices.

In order to install your own app on any Apple device, you need an Apple Developer account and a subscription to the Apple Developer Program.

🔗 [Apple Developer Program](https://developer.apple.com/programs/)

⚙️ [Code Signing Illustration](https://www.linkedin.com/posts/kadi-kraman_an-illustration-of-what-code-signing-with-activity-7132420058076581888-s6TM)

Use the EAS CLI to Configure App Store Credentials for Internal Distribution Builds

Create an iOS build for developing locally on a Simulator.

This is the only native iOS build you can do on EAS without having an Apple Developer account and being enrolled in the Apple Developer Program.

It can be used for local development on an iOS simulator, so you can only do this on a Mac, because you must be able to install Xcode to get access to the iOS simulators.

⚙️ [Xcode](https://apps.apple.com/us/app/xcode/id497799835)

🔗 [Expo Website](https://expo.dev/)

📝 [Docs](https://docs.expo.dev/build/introduction/)

Create a Development Build for iOS Simulator with EAS

Set up an existing Expo Go project to use Development Builds.

Expo Go is a Sandbox Environment designed for learning prototyping and getting started with mobile development quickly. The major limitation of Expo Go is that you are completely unable to add or edit any native code in your app. This might be a trivial limitation at the start of your project when you're prototyping and experimenting, but most production quality apps will eventually need to have more control over their native app bundles.

This is where development builds come in. A development build is basically your own customised version of Expo Go: you build the native side of your app yourself and get to have all the control over what libraries and configurations are included.

Thanks to CNG (with prebuild) the native projects are generated automatically based off of your app config and package.json.

📝 [Expo Go](https://docs.expo.dev/get-started/expo-go/)

📝 [Development Builds](https://docs.expo.dev/develop/development-builds/introduction/)

📝 [Continuous Native Generation (CNG)](https://docs.expo.dev/workflow/continuous-native-generation/)

Set Up Your Expo Go Project to Use Development Builds

Create a new React Native project using the Expo CLI.

You can use any of the supported package managers: **npm**, **yarn**, **pnpm** or **bun**. In the video (and throughout the course) we use **yarn**.

You can also choose a template to use for your project. In this video we choose the blank TypeScript template, but you can choose a different template if you prefer.

📝 [Docs](https://docs.expo.dev/get-started/installation/)

Create a React Native App With Expo CLI

Expo Application Services ([EAS](https://expo.dev/eas)) is a cloud build service used to build and publish React Native apps.

This course will show you how to create the common types of builds for iOS and Android on EAS. We'll cover Development builds for local development, Preview builds for internal testing, and Production builds for release.

Additionally, you'll learn about:
- app versioning
- automatic store uploads
- setting up store listing pages
- installing multiple app variants on the same device
- installing past builds with [Expo Orbit](https://docs.expo.dev/build/orbit/)

## iOS

An overview of build signing, and why an Apple Developer account needed in order to install builds on a real device.

How to create:
- an iOS simulator build
- a build to use on your device for local development
- a build to share with your team without uploading it to App Store Connect
- a release build to use on the App Store

You will also learn how to upload your build to App Store Connect, share it on TestFlight and create a Release.

## Android

How to create:
- a build to use for development on an emulator or a device
- a build to share with your team without uploading it to Google Play
- a release build to use ob Google Play

We'll cover what is needed to create a new Google Play account, and the current restrictions for individual accounts.

You will also learn how to set up auto-submit on Google Play.

Build and Deploy React Native Apps with Expo EAS

An easy to implement, adaptable authentication and authorization platform which basically makes your login box awesome.



auth0

After a user successfully logs in, Auth0 sends an ID token to your React application. Auth0, uses ID Tokens to cache user profile information and give it to a client application. The caching of ID tokens can improve the performance and responsiveness of your React application.

You can use the data from the ID token to personalize the user interface of your application. The Auth0 React SDK decodes the ID token and stores its data in the user object from the `useAuth0()` React hook. 

Customize UI With ID Token Data From The useAuth0 Hook's User Object

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

You can log out users from your React application by logging them out of their Auth0 sessions using the `logout()` method from the Auth0 React SDK.

Create a `logout-button.js` file in the src/components/buttons folder

Create a logout button component with the following code

```js
import { useAuth0 } from "@auth0/auth0-react";
import React from "react";

export const LogoutButton = () => {
  const { logout } = useAuth0();

  const handleLogout = () => {
    logout({
      logoutParams: {
        returnTo: window.location.origin,
      },
    });
  };

  return (
    <button className="button__logout" onClick={handleLogout}>
      Log Out
    </button>
  );
};
```

The `logout() method from Auth0 React SDK clears the application session and redirects to the Auth0 /v2/logout endpoint to clear the Auth0 session.

You can pass an object argument to `logout()` to customize the logout behavior of the React application. You can define a `logoutParams` property on that object to define parameters for the /v2/logout call. This process is invisible to the user. 

Pass the `logoutParams.returnTo` option to specify the URL where Auth0 should redirect your users after they log out. 

Setting `logoutParams.returnTo` to `window.location.origin` will ensure that Auth0 redirects your users to your production URL that you add to the "Allowed Logout URLs" list.




End Auth0 User Session with the logout Method from useAuth0 Hook

In this lesson, we create an AuthenticationGuard file that uses the Auth0React SDK to protect React routes by requiring login. 

You need to create the AuthenticationGuard component, pass in a component prop, and use it to protect any React route. 

```js
import { withAuthenticationRequired } from "@auth0/auth0-react";
import React from "react";
import { PageLoader } from "./page-loader";

export const AuthenticationGuard = ({ component }) => {
  const Component = withAuthenticationRequired(component);

  return <Component />;
};
```

Will also demonstrates how to use the AuthenticationGuard component to protect the profile, and admin routes in the application. 

```js
import { useAuth0 } from "@auth0/auth0-react";
import React from "react";
import { Route, Routes } from "react-router-dom";
import { PageLoader } from "./components/page-loader";
import { AuthenticationGuard } from "./components/authentication-guard";
import { AdminPage } from "./pages/admin-page";
import { CallbackPage } from "./pages/callback-page";
import { HomePage } from "./pages/home-page";
import { NotFoundPage } from "./pages/not-found-page";
import { ProfilePage } from "./pages/profile-page";
import { ProtectedPage } from "./pages/protected-page";
import { PublicPage } from "./pages/public-page";

export const App = () => {

  return (
    <Routes>
      <Route path="/" element={<HomePage />} />
      <Route
        path="/profile"
        element={<AuthenticationGuard component={ProfilePage} />}
      />
      <Route path="/public" element={<PublicPage />} />
      <Route
        path="/protected"
        element={<AuthenticationGuard component={ProtectedPage} />}
      />
      <Route
        path="/admin"
        element={<AuthenticationGuard component={AdminPage} />}
      />
      <Route path="/callback" element={<CallbackPage />} />
      <Route path="*" element={<NotFoundPage />} />
    </Routes>
  );
};

```

Use Auth0 component withAuthenticationRequired To Protect React Router 6 Routes

The `isAuthenticated` value represents the authentication state of your users it's tracked by the Auth0 React SDK. This value returns `true` when the user has been authenticated and `false` they're when not. Use `isAuthenticated` to render UI elements conditionally depending on the authentication state of your users.

```js
import { useAuth0 } from "@auth0/auth0-react";
import React from "react";
import { LoginButton } from "../../buttons/login-button";
import { LogoutButton } from "../../buttons/logout-button";
import { SignupButton } from "../../buttons/signup-button";

export const NavBarButtons = () => {
  const { isAuthenticated } = useAuth0();

  return (
    <div className="nav-bar__buttons">
      {!isAuthenticated && (
        <>
          <SignupButton />
          <LoginButton />
        </>
      )}
      {isAuthenticated && (
        <>
          <LogoutButton />
        </>
      )}
    </div>
  );
};
```
Authentication process doesn’t happen in your React application when using Auth0. Your React application will redirect your users to the Auth0 Universal Login page. Auth0 asks for credentials and redirects the user back to your application with the result of the authentication.


Use the Value of isAuthenticated to Render Components Conditionality

Create a `signup-button.js` file under the src/components/buttons folder

Add the following code:

```js
import { useAuth0 } from "@auth0/auth0-react";
import React from "react";

export const SignupButton = () => {
  const { loginWithRedirect } = useAuth0();

  const handleSignUp = async () => {
    await loginWithRedirect({
      appState: {
        returnTo: "/profile",
      },
      authorizationParams: {
        screen_hint: "signup",
      },
    });
  };

  return (
    <button className="button__sign-up" onClick={handleSignUp}>
      Sign Up
    </button>
  );
};
```
Adding `authorizationParams` to the `loginWithRedirect()` configuration object with the `screen_hint ` property and a value of `signup` will take users from your React application to the sign-up page.

Pass authorizationParams to loginWithRedirect to Direct Users to Auth0 Sign Up

AI is amazing for generating code, but often leaves us staring at functions and libraries we've never seen before. This creates a huge problem: When things break (and they will break), we're lost. We don't understand the individual pieces, let alone how they interact. Knowing one part isn't enough; we need to see how unfamiliar components work together.

The solution? Real-world examples.

This lesson introduces ghx, a tool I built to do exactly that. ghx searches GitHub, finding actual code examples that use the specific combinations of functions and libraries that are tripping you up. Instead of generic documentation, you get concrete implementations. You can find the ghx repository at https://github.com/johnlindquist/ghx.

Here's the workflow we cover:

Identify the Unknown: Pinpoint the AI-generated code you don't understand – specific functions, libraries, or their interactions.

Search with ghx: Use ghx to search GitHub for examples using those terms together. ghx finds repos where those elements co-exist.

Consolidate Examples: ghx combines the relevant code snippets from those examples into a single, digestible file.

Ask the AI (Again, but Better!): Feed this consolidated code to an AI (like a coding-focused model in an AI studio). Now, instead of asking general questions, you can ask targeted questions based on real-world usage:

"Explain how these functions are used together in these examples."

"What are some common use cases for this combination of libraries?"

"Show me alternative code snippets that achieve the same result."

"Can you identify potential problems or areas for improvement, based on these examples?"

Iterate. Use your improved understanding to make changes, and then repeat the process to debug.

By leveraging ghx and targeted AI prompting, we transform from being lost in a sea of unfamiliar code to actively learning from how others have solved similar problems. We gain a deeper understanding of our AI-generated codebase, making debugging, modification, and future development far more manageable. This gives you the tools to understand, debug and improve your own code.

John Lindquist

How to Work with AI-Generated Code You Don't Understand

In this less we create a custom Zod schema using `z.custom`.

The example case covers room numbers validation: it must start with an uppercase letter followed by three digits. `z.custom` allows the creation of a brand new custom schema with a callback function that returns a boolean indicating validity.

We highlight a challenge with type inference in Zod's custom schemas: callback parameter types don't get aligned automatically - type-safety must be explicitly defined using type parameters.

We run tests against various room numbers and demonstrate how to effectively validate inputs and manage error messages.


Tomasz Ducin

Create Custom Zod Schemas and Validate project-specific data

Create custom validation logic in Zod using z.custom, for primitive values, ensuring type safety and proper error messages for room numbers.


Excessive properties refer to any additional attributes that are not explicitly listed in an object schema. When creating an object based on a schema, it is important to ensure that only the defined properties are included.

In TypeScript, if an object is created with an extra property that isn't defined in the schema, TypeScript will not raise an error unless the type is explicitly annotated. When the type is annotated, TypeScript will issue an error indicating that the extra property is not allowed.

Zod provides a strict utility to enforce similar checks. This feature ensures that only specified properties are allowed in an object schema. When unnecessary properties are added at both the top level and within nested schemas, Zod will throw errors indicating unrecognized keys.

Adding an unrecognized property to a Zod schema results in an error message that specifies which keys are not recognized. Applying strict checks on nested schemas ensures that all levels of the data structure are validated correctly.


Make Excessive Object Properties Fail on Zod Validation

Prevent excessive properties in TypeScript and Zod schemas using strict checks for better data validation

In this lesson we discuss how Zod works with TypeScript to handle special types like `undefined`, `null`, `any`, `unknown`, `never` and `void`.

We modify our room booking schema to demonstrate the use of `optional` and `nullable` Zod utilities.

By using `.optional`, we allow a property to be either its _original type_ or `undefined`. With `.nullable`, we allow it to be either its _original type_ or `null`. Finally, `.nullish` allows a value to be either its _original type_, `null`, or `undefined`.

For all cases, we run tests to show how these schemas work in practice, as well as how TypeScript infers types.


Declare Lack of Value in zod (optional, nullable and nullish)

use Zod for TypeScript schemas, including handling undefined, null, and special types like optional and nullable values, as well as any, unknown never and void

In this lesson we make use of partial validation of large and nested schemas in Zod.

Instead of creating many small schemas, which can complicate maintenance, Zod allows for the extraction of specific parts of a schema using the concept of ".shape". It "unwraps" the object schema, enabling access to sub-schemas within specific properties.

Additionally, we can use the `.unwrap` to get into element schemas of altered schemas such as `.optional` or `.array`.

Simplify working with complex schemas without the need to break them into hundreds of small schemas.

Use Zod Schemas partially using shape and unwrap

Manage large and nested Zod Schemas by extracting partial validations using shape and unwrap utilities

In this lesson we cover implementing sets and maps in Zod.

Using `z.set`, a schema for string-based amenities is created. We demonstrate how validation works by intentionally introducing errors and customizing error messages for better clarity.

Next, a map is created for existing guestDetails schema using `z.map`, with string keys and an existing `z.object`-based schema. The validation process is shown again by deliberately breaking the schema, such as omitting the age property, which triggers appropriate error messages.


Validate maps and sets using Zod schemas

Use sets and maps in Zod for schema validation, ensuring type safety for both keys and values.

In this lesson we'll use a few predefined schemas which will serve as constituents to create union and intersection schemas.

Three room booking schemas are defined: _single_, _double_, and _suite_. Each schema has slight differences in the structure.

The `z.union` utility is used to create a union of these schemas, allowing for validation against any of them. Type inference (using `z.infer`) for the room booking schema produces a union of object literals, exactly like in TypeScript.

We also create an intersection using `z.intersection`, combining room booking details with discount information.

These techniques enhance data validation and allow to make `zod` aligned even more with `TypeScript`.


Define Unions and Intersections with Zod

implement unions and intersections in Zod schemas for example domain related objects, enhancing TypeScript validation with clear examples

This lesson demonstrates how to provide runtime type-safety for arrays in TypeScript applications.

First we need to understand the challenges behind ensuring array type-safety in TypeScript. We explain how TypeScript infers arrays with an undefined length, making it difficult to guarantee that array accesses are safe.

Zod schemas provide the `z.array` to define arrays of various element types. 

We compare how utilities such as `.min`, `.max` and `.nonempty` get reflected in inferred TypeScript types, and how zod processes the validation.


Declare Precise Array Types within Zod Schemas

Provide array type safety in TypeScript using Zod schemas, including handling non-empty arrays for better validation

In this lesson we make string-based schemas more specific using Zod in TypeScript. We focus on defining allowed values for a room type, showing how to use literals and enums effectively.

Zod's `z.literal` method allows us to specify a single allowed value for a string schema. For example, if we want to define a room type as `"premium"` and make it backward-type-safe in TypeScript, we can use `z.literal("premium")` to ensure that only this value is valid.

`z.enum` lets us define a set of allowed string values. This is useful when we have multiple options for room types, like `"standard",` `"premium"` or `"childrenFriendly"`. 

`z.enum` creates a union of TypeScript-compatible string literals, making it easy to validate against multiple values. Zod enums can be used to extract or exclude specific values from the enum.

Finally, zod's `z.nativeEnum` a native enum creates an equivalent of TypeScript's native `enum` ("real enums", we could say).

We can validate against all these values just like we do with literals and enums.


Work with Zod Literals and Enums Effectively

Use Zod for string schemas in TypeScript, including literals, enums, and native enums for room type validation

In this lesson, we dive into the Zod's `refine` utility, allowing defining more complex schema validation **on top of existing schemas and utilities**.

Sometimes, we need special validation rules for our applications to work correctly. The `refine` utility lets developers create their own validation rules. This method's uses a callback to check if the input is valid. We also create meaningful messages when something doesn’t meet the validation rules.

We use a practical example involving a room booking schemawith `dueDate` and `price` property refinement.


Apply Schema Custom Refinement with Zod

Enhance your TypeScript validation skills with Zod's refine utility for custom room booking schemas, focusing on date and price validation.


Search

Search Results