 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

How you build with Angular has changed quite a lot over the years.

For example, the `inject` function was introduced in version 14 but you might still be familiar with Angular's constructor injection.

Similarly, structural directives like `ngif` or `ngfor` have been replaced with `@if` and `@for` blocks since version 17 and beyond.

These are patterns that need to be adjusted if you want to stay up-to-date with the latest Angular has to provide.

Luckily, Angular gives you great tools in the form of a migration CLI for supporting your migration efforts as you incrementally update your App from older version features and patterns. 

When you're done with this course you'll know how to target specific features, folders, and files to migrate to the latest Angular version.

You'll learn how to 'migrate':
- Structural directives with control flow syntax
- Constructor dependency inject to inject function
- Make components standalone
- Lazy load routes
- Input/Output decorators to signal-based API


Angular Migrations in Practice

Migrate old Angular patterns for version 18 and beyond

When we import assets in React components outside of the `public` folder that Nitro reads for assets by default when running the development server we need to tell Nitro how to find them with the `devProxy` configuration option.

```typescript
export default defineNitroConfig({
  renderer: './renderer.ts',
  devProxy: {
    '/app/assets': 'http://localhost:5173/app/assets'
  }
})
```

This is ultimately inadequate in scenarios where you want to import assets arbitrarily and have them "just work" but works in a pinch.



Use devProxy in Nitro Config to Serve Static Imported Assets in Dev Mode via Vite

Learn how to use devProxy in Nitro Config with Vite to serve static assets in React components in dev mode.

Start with a basic Vite React TypeScript app and enhance it for production use by integrating Nitro as the server. 

This requires a custom Vite plugin for nitro as well as a custom renderer and manually creating Nitro config.

The other way to approach this would be to add Vite to a Nitro app instead. Same basic result.

The [Nitro config reference](https://nitro.unjs.io/config) is a great read of you'd like to explore more options.


Configure a Vite React TypeScript Application on a Basic Nitro Server

Configure a Vite React TypeScript app by integrating Nitro for production, using custom plugins, renderers, and configs.

Quick Get Started style introduction to Vite using `pnpm create vite` with the React TypeScript template.

See [more in the official docs](https://vite.dev/guide/).

Create a Vite App with the React TypeScript Preset

Quick guide to start a Vite app using React TypeScript template with pnpm.

Over the years, your application have grown huge. Sometimes, really HUGE.

Many developers have contributed to the codebase. One day they pushed one coding style, a different one another day. Sometimes even different patterns and solutions for similar problems.

You want to keep your codebase consistent. In the Angular ecosystem, there were well established patterns for doing things the right way ™️. But the old solutions are being challenged by signal-based approach.

Eventually, you ask yourself the key question: **Should you integrate with the NEW solutions or stick to the battle-tested ones, but already considered LEGACY**?

That's a very good question indeed. Don't rush with architectural decisions 🤓.

## First, think of what problems you want to solve by introducing the change.

Do you have 1k LoC Angular components? Maybe even 2k? Do you and your team enjoy working with these? 😏

Where does the **domain logic and state management code** belong to - do you have a clear guidance on which code should be put where? Have you spot that different devs implement similar features in totally different ways?

Do you keep on asking the same questions over and over again: **whether this certain piece of code** should be **imperative** (plain old object properties and variables) or **reactive** (streams)? It'd be nice to keep all thinga reactive, but more often than not, it introduces complexity.

## Second, think of long-term consequences.

You are going to have more than one way to **manage the state**. But is that really an issue? If your codebase is modular, separate modules should not depend on each other in any way. Inner abstractions of one should be invisible to the other, etc.

You are going to introduce a **new tool**. On one hand, you need to learn it, and so does your team. But on the other hand, it's a breathe of fresh air. And it's useful to question the way you've been doing things so far. Maybe there's a more effective way?

You are going to embrace signal-based APIs. And that means taking taking advantage of Zoneless Angular. This means using all modern Angular APIs. And you know that signals are the future. Why would you want to stick to the **less performant, less type-safe, less flexible and, objectively, less effective solutions**?

## Finally, plan your INCREMENTAL integration.

INCREMENTAL is the absolute keyword here. You don't want to tell your PM you need to stop delivering features because of a refactor.

Actually, there's no need for a "refactor". Just pick the first new feature to be implemented. Or pick the one that needs to be extended.

NGRX Signal Store allows you to create both very simple & small stores, as well as bigger ones. **Composition** is the key here.

**Start simple**.

Create a `withState` section with the signals that hold the state. That's already reactive. And relatively simple.

```ts
const initialState: CartState = {
  items: ...,
  rebate: ...,
}

export const CartStore = signalStore(
  withState(initialState)
);
```

Create a `withMethods` section to provide ways to change the state:

```ts
export const CartStore = signalStore(
  ...
  withMethods((store) => ({
    addItem(item: ShoppingItem): void {
      patchState(store, (state) => ({ items: [ ...state.items, item ] }));
    },
    ...
);
```

Create a `withComputed` section to provide all derived computations:

```ts
export const CartStore = signalStore(
  ...
  withComputed(({ items }) => ({
    totalPrice: computed(() => items().reduce(...))
    ...
);
```

**Start simple**.

Now you can (literally) **`inject` this code into your existing solution**. All you need is to inject your brand new NGRX Signal Store implementation into a component, or a service:

```ts
@Injectable()
class ExistingBigService {
  cartStore = inject(CartStore)
  //...  
}
```

and that's it! What's beatiful is that NGRX Signal Store should remain an implementation details (of a component, service, etc). It **shouldn't leak outside to the entire application unintentionally**. Small NGRX Signal Stores help us to **keep logic more modular**.

Don't hesitate - give NGRX Signal Store a try! Start with the [_**Scalable Signals Angular Architecture with NGRX Signal Store**_](https://egghead.io/courses/scalable-signals-angular-architecture-with-ngrx-signal-store-a33abd39) course now!

Integrating NGRX Signal Store with an existing Angular application

Integrate NGRX Signal Store into your Angular app incrementally for modular, reactive state management. Improve consistency and performance with modern APIs.

In React 19, managing script tags efficiently within components can lead to performance enhancements and simpler code structures.

Originally, using script tags directly in a React component involved complex setups, like using `useEffect` to dynamically add JavaScript code. For instance, a component might dynamically inject script tags to load external widgets. This approach, while functional, resulted in multiple script tags and duplicate iframe elements. This duplication not only cluttered the output but also negatively impacted performance by loading scripts multiple times.

The workaround for this would be to manually hoist any common scripts and maybe load them when they weren't needed by any components.

With React 19 we now have a more effective method. This involves directly placing the script tag within the React component's return statement. This approach ensures that React handles the script loading, avoiding the duplication of script tags.

By implementing the script tags this way, the loading initiator becomes React DOM, which efficiently manages script loading and deduplication. This setup prevents multiple requests for the same script when the component is rendered multiple times, enhancing the overall application performance.

Furthermore, directly embedding the script tag simplifies the code, making the component cleaner and more maintainable.

Efficiently Render Script Tags in React 19 Components

Learn how to efficiently render script tags in React 19 components to improve performance by avoiding duplicate script loads and simplifying your code.

Let's learn how to dynamically manage title tags in React 19 applications. Rendering `<title>` dynamically is simple enough, however, a challenge arises when multiple title tags are present in the document, which can lead to issues with screen readers and search engine optimization (SEO). The solution presented involves ensuring that only one title tag is rendered at a time by using conditional rendering.

Also we need to make sure to have a single string within the title tag using a template literal, ensuring our HTML remains valid and optimized.


Deduplicate Title tags with React 19

Learn to manage multiple title tags in React 19 dynamically. Ensure accessibility and SEO by preventing duplicate title tags with clear examples.

In React 19, we can easily add a title tag like "Starship Deets" which then appears in the head section of the HTML even when we render it inside our components. This method also applies to meta tags such as character set and viewport settings, which are also lifted to the head section automatically.

This is an awesome feature because it maintains the same composition style we are familiar with in React components. It simplifies the handling of HTML head elements without needing extra setups like `useEffect` for accessing the head section. Even in situations where our components are rendering within a body element, like within a div, we can manage our head content directly within our components. React takes care of hoisting these elements where they need to go.


Hoist Title and Meta tags in React 19

Hoisting title and meta tags directly in React 19 components allows for simpler composition, similar to other React elements. Manage meta and title tags.

<PodcastLinks />

Dax Raad, known for his strong opinions on Twitter, sat down for a chat about web dev, career moves, and building cool stuff. He's not afraid to throw some heat at popular tools like [Next.js](https://nextjs.org/), though he still helps people use it. Dax is particularly excited about local-first development, which he thinks isn't getting enough attention. He argues that sometimes the best web dev move is to step away from web dev entirely and explore other areas of programming.

When it comes to career growth, Dax encourages developers to think beyond the "web dev" label and see themselves as programmers capable of tackling any challenge. He advocates for trying out weird stuff and learning unusual languages, as these experiences can lead to unexpected opportunities. Taking smart risks in your career can open doors to awesome possibilities.

In the business world, Dax is a fan of making "asymmetric bets" - moves with low downside but huge potential upside. He applies this philosophy to his work on [SST](https://sst.dev/), reasoning that even if it fails, he'll walk away with valuable experience. He also emphasizes the importance of resisting quick payouts in favor of potentially bigger wins down the road.

Looking to the future of tech, Dax is betting on local-first development. He sees potential in getting in early on emerging technologies like [Solid.js](https://www.solidjs.com/). Building in public and making connections in new tech communities can pay off in unexpected ways.

Dax also challenges the notion of constant hyper-productivity in tech. He suggests balancing focused work with time for exploration and learning. Sometimes, he points out, what seems like a "dumb" choice (like learning a niche language) can turn out to be a smart career move in the long run.

## Good Stuff Mentioned

- [Next.js](https://nextjs.org/)
- [Vercel](https://vercel.com/)
- [SST](https://sst.dev/)
- [Elixir](https://elixir-lang.org/)
- [Solid.js](https://www.solidjs.com/)
- [RepliCache](https://replicache.dev/)
- [Linear](https://linear.app/)
- [Remix](https://remix.run/)
- [Shopify](https://www.shopify.com/)
- [React](https://react.dev/)

Developer Career Growth and Asymmetric Bets with Dax Raad

<PodcastLinks />

Dev and Joel discuss React Miami conference, praising its fun atmosphere and location. They chat about React Server Components, with Dev sharing his experience building a mini framework. They talk about Vinxi, Nitro, and the unjs ecosystem as tools for creating custom frameworks. The conversation touches on Vue's popularity outside web dev circles and non-web dev conferences. They discuss the benefits of TypeScript and strongly-typed APIs. Dev mentions his upcoming talk on durable objects at [a conference in Dallas](https://x.com/DThompsonDev/status/1829674506237194456). They end by discussing WebSockets, PartyKit, and platform-specific frameworks.

## What's Good?

- [React Miami Conference](https://www.reactmiami.com/) 
- [Brenley Dueck's blog post on Simple RSC with Vinxi:](https://www.brenelz.com/posts/simple-rsc-with-vinxi/)
- [Vinxi](https://github.com/nksaraf/vinxi)
- [Nitro](https://nitro.unjs.io/guide/configuration)
- [unjs ecosystem](https://unjs.io/)
- [Solid Start](https://start.solidjs.com/)
- [TanStack Router](https://tanstack.com/router/latest) 
- [PartyKit](https://github.com/partykit/partykit) 
- [Durable Objects (Cloudflare)](https://developers.cloudflare.com/durable-objects/)
- [Flightcontrol](https://www.flightcontrol.dev/) 
- [SST](https://sst.dev/)
- [OpenNext](https://open-next.js.org/)

Shawn Wang

Search Results