 Courses from Shawn Wang

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

In this talk, we’ll create an effective mental model of Concurrent React by building a tiny clone of React! We will start with a blank JS file and learn about how React renders components, schedules Time-Slicing updates with a Work Loop, add Hooks, and end off with a mini-clone of Suspense!

Concurrent React from Scratch

Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

node

Before you use any frameworks, you should know the fundamentals of what makes Node CLI's tick. Here we explain everything you need to know to write a complete Node.js CLI from scratch, parse arguments, publish it to NPM for users, and set up yarn symlinks for optimal developer experience.

Develop and Publish a Node.js CLI from Scratch

JavaScript® (often shortened to JS) is a lightweight, interpreted, object-oriented language with first-class functions, most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic, and supports object-oriented, imperative, and functional programming styles.

javascript

Flags and Args are the standard means of user input into CLI's. Oclif helps you parse them and declaratively indicate requirements, but because they are a public API, some thought should be put into designing the user experience. When in doubt, Flags win Arguments.

Parse Flags and Args in Node.js CLIs with Oclif and TypeScript

Heavy duty CLI's like gatsby and npm do more than one thing. The convention is to namespace them with a command name after the CLI name, like `gatsby new` or `gatsby build` or `npm install` or `npm uninstall`. We should be comfortable converting our single purpose CLI's into multi command CLI's as our needs grow, as well as understand how to share logic between commands to keep code DRY.

Convert a Single Command CLI into a Multi Command CLI with Oclif and TypeScript

Sometimes you still want to support the API and quick developer experience of a single command, while still supporting multi commands in your CLI. This is handy when, for example, you want your user to do something useful with just `npx mycli`.

Here's a quick hack that lets you do that, while also deepening your understanding of how your CLI works with TypeScript, Node.js and Oclif under the hood.

Create a Hybrid Single-Multi Command Node.js CLI with Oclif and TypeScript

Flags and arguments are only the most primitive ways of taking in user input. There is no opportunity to interactively prompt the user so they don't need to look up documentation or memorize your flags. Fortunately there are many libraries that help take in user input, however, there are also ways to do it badly and other ways to do them well. Enquirer is a great foundation to build Interactive CLIs that don't leak tokens and passwords, and make use of design affordances to offer beautiful and intuitive user prompts.

However, don't get overzealous with the prompting: remember your CLI's non-human users - Bots and Continuous Integration environments! We end with some advice on how to blend flags and prompting seamlessly.

Design Beautiful, Intuitive and Secure Node.js CLI User Input Experiences with Enquirer

You're going to run into a lot of frustration writing Node CLI's unless you get good at debugging. (Even if you use TypeScript!) To understand code execution (particularly code you didn't write), you should be comfortable using the VS Code Debugger for its excellent step-through and watch features. But in case you don't know where the problem is (particularly for heavily nested codebases like React) or if you're looking for performance issues rather than code errors, you'll also want a robust logging solution. The `debug` module is best in class and is built into Oclif.

Debug Node.js CLIs with the VS Code Debugger and the `Debug` module

Prompting is a nice patch over missing Flags and arguments, but what if your program is so complex that you have *too many options*? You will probably want to allow the user to specify config files. The conventions and user preferences over config file format are too numerous to manage, but that's fine because Cosmiconfig will help us manage them!

Config handling is one example of highly sharable business logic (just like authentication and backend syncing) - so we will also look at how to extract this out to a shared Base Command.

Create Highly Configurable Node.js CLIs with Cosmiconfig and Oclif

To be useful and trustworthy, your CLIs should be extraordinarily reliable. Investing in testing early will reap rewards in future. We show how to set up basic tests with Jest and Oclif's test helpers.

Test Node.js CLIs with Jest and Oclif

One of the killer apps of CLIs is with templating (or scaffolding). The `rails generate` and `ng generate` commands are famous for this. By immediately reducing the pain of boilerplate, you can also make it easy to write standardized code, with in-place reminders for comments and developer warnings (it is easier to delete generated code than write code, though of course one can overdo it). There is no standardized tooling for doing scaffolding, since you can use everything from the Express.js templating languages to writing your own, but we explore this problem space with the tiny `copy-template-dir` library to prove out the developer experience of adding scaffolding to your CLI.

Scaffold out Files and Projects from Templates in a Node.js CLI

CLI's gain an extra level of power when you realize they can start and manage other CLI's and run multiple concurrent child processes (great for farming out work on multi-core machines!). You can even use it to improve developer experience in really small ways. For example, create-react-app famously scaffolds out a React app for you, and *also* installs the relevant node_modules. We'll learn how to do this two ways: with execa and with a dedicated yarn-or-npm utility, because this is such a common usecase.

But before all that - we must learn and be comfortable with the raw Node.js child_process and I/O Stream API's. So that's where we begin.

Spawn and Manage Child Processes and Node.js Streams with execa

If your users globally install your CLI's, will they ever update them? How will they know about new features and patches? How do you check for updates without impacting performance? How do you respect user preferences to *ignore* your updates?

These are all solved problems with the wonderful `update-notifier` library.

Prompt Users to Update Your Node.js CLIs with Update-Notifier

Most Node.js CLIs merely execute scripts statelessly, deterministic based on inputs from flags and args and configs. However this understates the massive potential of CLIs given their location in your filesystem. Just like the Browser DOM is inherently stateful, remembering your past link visits and preserving your form data, CLIs are another form of user experience that can be enhanced greatly by adding memory, particularly when the same CLI is used across multiple projects. This isn't a surprising insight, it is just that there is no standardized tooling around this. (Although there is a spec for *where* to store your data while respecting the user's preferences and operating system, called the XDG spec)

The Conf library provides an unbelievably easy way to persist values to memory in an XDG compliant fashion. We will explore two practical examples of using it.

Store State on Filesystem in Node.js CLIs with Conf

When all is said and done, the finishing touches to put on your world class CLI can make your experience visually stand out as much as the code underneath. Chalk helps add colors to draw the eye to console output, and Ora gives you all the spinners you could possibly want for communicating that important work is being done in the background or child process.

Polish Node.js CLI Output with Chalk and Ora

In stateful interfaces, there's a tradeoff between recency and frequency, two seemingly similarly aligned goals for guessing user intent. Recency biases towards newer entries being more likely to be what you are looking to do. Frequency biases towards betting on you doing the same thing you've always done. Fortunately there is an established algorithm that trades off frequency and recency, and chances are you've already used it in Slack or other similar interfaces!

Create Node.js CLI's that Intelligently Adapt to Usage with Frecency

Today, you can't do anything in JavaScript without bumping into a CLI. 

Want to install a library? `yarn` add it. 
Want a React app? `create-react-app`. 
Want to format your JavaScript? `prettier --write`. 
Want your types checked? `tsc`. 
Bundling? Pick from `webpack`, `rollup`, or `parcel`. 
Deploying? `now` or `netlify deploy`. 

CLI's are everywhere, and even if you don't write them, sooner or later you'll have to debug them.

This workshop serves as a comprehensive survey of the state of the art of CLI tooling for everyone looking to make an impact in open source, across their company, and even in their own productivity.

Check out these [**community notes for this course on Github**](https://github.com/eggheadio-projects/build-custom-cli-tooling-with-oclif-typescript-notes).

TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.

typescript

Build Custom Command Line Interface (CLI) Tooling with oclif and TypeScript

The fastest way to create a robust, cross-platform compatible Node.js CLI (optionally typed with TypeScript) is by running `npx oclif single mycli`. Here we explain what this means and how and why to integrate this with Yarn Workspaces for an ideal developer experience.

Create a Single-Command Node.js CLI with Oclif, TypeScript and Yarn Workspaces

In this lesson we start from an empty directory and bootstrap a React TypeScript app with create-react-app. Then we write our first React TypeScript Component and add our first types, including an optional type.

Write your first React TypeScript Component 

There are many ways to type event handlers with TypeScript, and we use the case study of controlled components to explore the 3 major ways to do this. Then we refactor to use the createRef API to write uncontrolled components, and explore the typing strategies for that as well.

Write Controlled and Uncontrolled Components for Forms with React and TypeScript

TypeScript's Basic Types are worth exploring with a view toward practical usage in React Components. Furthermore, you can comment your components and your types and have them show up in your tooling, for example your IDE, or even autogenerated documentation for your design system.

Write Self Documenting React Props with TypeScript Basic Types and Inline Comments

Here we refactor a React TypeScript class component to a function component with a useState hook and discuss how props and state types can be modeled accordingly.

Write a stateful Component with the React useState Hook and TypeScript


While using anonymous functions might seem convenient, they can create difficulties when trying to identify performance bottlenecks during profiling. This lesson will demonstrate how named functions make it easier to pinpoint and address performance issues, ultimately leading to more efficient and debuggable code. Learning this practice will greatly improve your ability to locate and fix performance issues in complex projects.

Always Name Functions in JavaScript

Mock Service Worker is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments.



Mocking WebSocket APIs with Mock Service Worker


When attempting to load the same module twice in JavaScript you'll hit a cache and code won't re-run. In scenarios where you actually do want to have state in your modules, you'll have to use a cache-busting technique by passing a query parameter to a dynamic import. This lesson walks through how to add a query parameter, how to add the appropriate types for loading dynamic modules in TypeScript, and when these techniques are valuable.

Import the Same JavaScript Module Multiple Times with Cache Busting



The include keyword in GitHub Actions empowers you to add custom variables to your matrix strategy, providing flexibility beyond standard configurations. In this video, we'll explore how include allows you to define specific combinations of variables, enhancing control over your workflow runs. You'll see how this feature enables you to tailor jobs for unique environments or scenarios not covered by the default matrix options. By leveraging include, you can efficiently manage complex build processes with greater precision. This technique helps you streamline your CI/CD pipeline, making it more adaptable to your project's evolving needs.

Use GitHub Actions Matrix Include for Complex Job Configurations

While running `zod` schema validation agains domain-rich objects, the error message saying that _a string is not a number_ might not be really useful.

Especially, when you need to provide a meaningful feeback to the user, e.g. after they have submitted a form with lots of data.

`zod` allows to customize messages on a very granular level. We can also extract repeatable customization to `zod` error maps.

Finally, in order to process an error message further (e.g. display it to the user), we need to handle the `zod` validation errors effectively. Especially, when a big object validation has failed and we could receive a handful of errors.

That's what we learn in this lesson. 🔥

Customize zod Error Messages and Handle zod Errors Effectively

customize zod validation messages, customize zod schema property messages, reuse error maps across different schemas, navigate through zod error objects

You might want to run `zod` schema checks in different styles.

Sometimes you prefer to conditionally throw the error - that's what `parse` does. But another time you'd prefer to receive a `boolean` property that determines whether the validation was successful or not - and perform further actions accordingly.

Additionally, the error-throwing API of `parse` works extremely well with [TypeScript assertion functions](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#assertion-functions). Their combination is just... perfect! 👌

That's what we learn in this lesson.

Use parse and safeParse Runtime Type-checks with zod

use zod parse function to conditionally throw ZodError, use zod safeParse to get a boolean value and run typescript type guard over success property

In this lesson we learn that TypeScript cannot guarantee correct shapes of responses. That's due to TS performing checks in compile-time, while the response will be availbale in runtime - when TS doesn't exist anymore.

In some situations, such as HTTP requests, runtime type checks such as `zod` are essential for providing quick feedback around data-related errors.

Understand where are the possible mistakes to make while using TypeScript with HTTP calls. Use `fetch` and `axios` along with `zod` schema checks.

Also, note that similar mistakes or mistakes could happen while using web storage (e.g. `localStorage`)

Validate HTTP API Response with zod, fetch and axios

use zod as an HTTP response validation tool along with fetch and axios in order to make sure that the response has expected data structure

In this lesson we learn that the `zod` schemas become the single source of truth.

We shall not update TypeScript types manually, since they are generated automatically from the schema.

Same with validation functions.

Whenever the schema changes, all the rest will update accordingly. It's an important mind shift.

Treat zod Schemas as Single Source of Truth

Zod Schemas are the single source of truth for both typescript types, and interfaces - and runtime validation functions. Schemas should be updated first.

`zod` is powerful, but writing the schemas manually for existing JSON objects, especially big ones, can be time-consuming.

But that's what `quicktype` is for! You can get 80% work done instantly! 🥳

Depending on your need - whether you want to automate the process, or do it just one time, you can:
- use an online app
- use an IDE extension
- run a CLI script
- generate a script to be executed within CI/CD environment/tooling

And this is what we learn in this lesson! 🔥🔥🔥

Get started with zod quickly!

Generate zod Schemas Automatically using Quicktype App, Extensions and Scripts

Use quicktype app, extension or scripts to automatically generate zod schemas from existing json files. Save time and get started with zod quickly!

`zod` is a powerful library allowing to run runtime type-checks.

It's complementary to TypeScript, which does type checks in compile time.

In this lesson we create few schemas that represent primitive type values, along with `zod` utilities which make these more precise. We also create object schemas and nest one inside another.

All schemas are being validated against example values. We analyze how to interpret error messages in case of failures.

Perform Runtime Type-checks on Primitives and Objects with zod

Create zod schemas to validate primitive type and object type values in runtime. Analyze the errors to see how a value doesn't correspond to schema expectations

Shawn Wang

Search Results