 Courses from Joel Hooks

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.

<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/)

Nitro, Vinxi, and RSCs - What's Good with Dev Agrawal

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

Managing state in a UI is challenging. It's genuinely difficult and the solutions require a depth of knowledge and experience to understand. Everything is a balance of tradeoffs in complexity, performance, and user experience. In this interview, Joel and Matt discuss those challenges and big ideas that drive React State Management in 2021.

Building Stateful UI Applications with Matt Pocock

Joel and Tanner Linsley chatted about why state management is such a big issue when building UI's, the motivation for creating state management tools, how server State has inherently different problems from UI state and therefore needs to be managed differently. Additionally, Tanner gave a walkthrough of how React Query manages query caching and uses a serializable array or "query key" to do this.

### Why is state management is such a big issue when building UI's?

- It gets difficult because of how the DOM works (having immutable nodes).
- Part of this is why React came to be (to make everything declarative).
- But it's important to note that State Management was a problem before React.
- The constant battle of state management has been: "Is this actually what the user is seeing?"
- **Drawbacks of losing State:**
    - Users lose trust (for a regular user, it's confusing and frustrating).
    - For developers: they lose trust in their code.
- The internet has lagged when it comes to managing State.
    - State machines have existed for a long time, and as a community, we are still learning what's the best approach to managing State.

### What's the motivation for creating your own tools?

- Creating open-source software.
- This blog expands more on the motivation of working on open-source software. ⤵️
https://tannerlinsley.com/blog/the-similarities-between-open-source-work-and-running-a-tech-startup

- Finding the right tools! An example of this is building [React Table.](https://github.com/tannerlinsley/react-table)
- [#TanStack](https://twitter.com/search?q=%20%23TanStack&src=typed_query)

### When it comes to State management, what are the big ideas?

- [David Khourshid](https://twitter.com/DavidKPiano)'s works have been a great inspiration!
    - The concept of having State Machines they are sound and solid:
        - **1. Finite State Machines**
            A finite state machine is a mathematical model of computation that describes the behavior of a system that can be in only one state at any given time.

        - **2. Statecharts**
            Computer scientist David Harel presented this formalism as an extension to state machines in his 1987 paper Statecharts: A Visual Formalism for Complex Systems.

        - **3. Actor Model**
            The actor model is another very old mathematical model of computation that goes well with state machines. It states that everything is an "actor" that can do three things:

            - **Receive** messages
            - **Send** messages to other actors
            - Do something with the messages it received (its **behavior**)
- It's important to note that the same principles of XState can be applied to other things. **Those principles are universal, and the implementation is not.**
- Another big idea is not letting your application be in multiple States.
- Understanding that State can be derived from mathematics.

## Server State vs UI State

### What should people be asking of their state management libraries?

There are various categories of state, but every type of state can fall into one of two buckets:

**1. Server Cache** - State's stored on the server, and we store in the client for quick-access (like user data).

**2. UI State** - State that's only useful in the UI for controlling the interactive parts of our app (like modal `isOpen` state).

- **We make a mistake when we combine the two.**
- Server cache has inherently different problems from the UI state and therefore needs to be managed differently.
- If you embrace the fact that what you have **is not actually state at all but is instead a cache of state**, then you can start thinking about it correctly and therefore managing it correctly.
- Stop colocating your server-state with your client state.
    - Talk:
        - [It’s Time to Break up with your "Global State"](https://t.co/NkAPNkhf2K?amp=1) - not public yet. 😕
    - Tweet expanding on server-state vs. client state: [Twitter Link](https://twitter.com/tannerlinsley/status/1249737377561464832?s=20)

## UI Abstraction

- **For client state:** there's no need to go outside of React. Unless I want to, like going for Redux because of the dev tools.
- **For server-state:** I'm going to reach for React Query, Apollo, SWR.
- Keeping track of the local state is easy; it's predictable. You can control everything inside your application.
- When you start consuming stuff outside of your app, you are no longer in control. They are reading a Snapchat of an API endpoint. People treat data as they own it, which they don't. And that's hard to keep track of.
- **Rule:** Who owns this code?
    - If you can answer this question correctly, then you'll know what tool to use.
- **Part of this conversion is this talk:**
    - Custom Hooks in React: The Ultimate UI Abstraction Layer: [YouTube Link](https://www.youtube.com/watch?v=J-g9ZJha8FE)

## Recap:

- Custom Hooks in React is helpful for much more than just managing the local state and one-dimensional side-effects you see in almost every React Hooks example.

- They can be used to build sophisticated memoization pipelines and chained effects that automatically manage local and network resources.

- But most importantly, they provide a new layer of abstraction to accomplish new and amazing patterns that we couldn't have just over a year ago.

- On the surface, this abstraction layer is simply a collection of custom hooks, but when unlocked, it can be the most powerful piece of your application architecture.

## Moving away from Redux and Apollo

- Once we React Hooks came out Tanner moved away from Redux entirely.
    - React Query is significantly different from using Redux. Redux is a global state manager with its own context. React Query to some extent is also a global state manager for async data.
    - If you were to integrate the two, you would move all of your async data out of redux into React Query and only use Redux for non-async-data global application state.
- A few months, Tanner use Apollo but realized that he didn't like GraphQL.
    - Drawbacks from using Apollo:
        - Force you to manage async data in a synchronous way
        - Duplicate unnecessary network operations
        - Over-engineered caching strategies
- **Tanner asked, how can you get the Apollo experienced without Apollo?**
    - The inspiration for React Query came from [draqulajs](https://draqulajs.com/) - a GraphQL client for minimalistic React apps.
        - [Draqula Github](https://github.com/vadimdemedes/draqula)

## Query Keys in React Query

- React Query manages query caching for you and uses a serializable array or "query key" to do this.
- React Query Keys can be strings or an array with a string and then any number of serializable primitives and/or objects, unlike URLs and/or GraphQL query template strings.

## Following Query Keys

- When a query needs more information to describe its data uniquely, you can use an array with a string and many serializable objects to describe it.
- You can use this query multiple times, using a single cache.
- You can grab your data from any place. You can pass anything inside the keys, even a graphQL query as long as it resolves data.

## Under the hood

- Query Keys are serialized deterministically. 

- This means that no matter the order of keys in objects, all of the following queries would result in the same final query key.
- Query keys get passed to the `getQueryArgs` function and then it determines the arguments by using the `queryKey.` [Utils.js](https://github.com/tannerlinsley/react-query/blob/588d54cfc54d3c62e486d8f6cdfd12eed98c36b4/src/utils.js#L94)

- Next, it passes the `queryKey` to the `useBaseQuery` function to send it off to `buildQuery`. [useBaseQuery.js](https://github.com/tannerlinsley/react-query/blob/588d54cfc54d3c62e486d8f6cdfd12eed98c36b4/src/useBaseQuery.js#L15)

- Finally, it's passed to the `buildQuery`. [queryCache.js](https://github.com/tannerlinsley/react-query/blob/588d54cfc54d3c62e486d8f6cdfd12eed98c36b4/src/queryCache.js#L122)

- If we take a look at `config.js` we'll see that the simplest form of a key is not an array, but an individual string. [config.js](https://github.com/tannerlinsley/react-query/blob/588d54cfc54d3c62e486d8f6cdfd12eed98c36b4/src/config.js#L60)

- When a query needs more information to describe its data uniquely, you can use an array with a string and any number of serializable objects to describe it.
- This is where the `stableStringify` is used.
- This contains a `JSON.stringify` function but with a `stableStringifyReplacer` that will check if any values are objects. If they are Object, it will sort the keys and remap them back.

## React Suspense

### **How come Suspense is integrated into React Query?**

- React Query can be used with React's new Suspense for Data Fetching API's.
- Since React Query is backed by its own cache, it makes "suspense resilient".
- No one is using Relay outside of Facebook. Usually, people are not building the next Facebook.
    - Relay feels over-engineered.
- Joel mentioned that you should optimize for deletion.

"Optimize for deletion when you write your code because if you don't it's easy to end up needing to grind out large rewrites, which contain massive risk."

**From Chris Biscardi's Digital Garden**: [If you can't delete code then you're stuck with it](https://www.christopherbiscardi.com/post/if-you-cant-delete-code-then-youre-stuck-with-it)

## Adding Suspense to React Query

- Implementation Suspense to React Query wasn't hard.
- You can set either the global or query level config's suspense option to true.
- Its handle by the `handleSuspense` function. [Github](https://github.com/tannerlinsley/react-query/blob/588d54cfc54d3c62e486d8f6cdfd12eed98c36b4/src/utils.js#L129)

- People are building the same thing, they are not really worried about changes coming to Suspense.

Using react-query to Manage Server Data and Cache with Tanner Linsley

Please be advised that this video contains language that can be considered explicit.

Joel and Jared chat about the essential questions around State management; they concluded that there is no silver bullet in dealing with State Management. The conversation also included an overview of how URL-driven Applications are used to maximize SEO performance (they do this by keeping State the URL). Jared also gave a walkthrough of Formkit and Recoil. He expanded on how Recoil solves performance when you need to update State in a deeply nested tree.

## Resources

[Jared Palmer](https://jaredpalmer.com)

## State Management

- The reason why State management comes up as a pain-point is that it's core to application development. If you understand State Management, you know React at its most profound levels.
- Managing State is an art form. It's the most challenging part because it's the main job.
- Managing State has heuristics, similar to a language that has been acquired through experience.
- Using TypeScript, you learn to start recognizing patterns. It gives an additional layer of information. It also enhances communication in a project.
    - "I became a lot better at managing State when I started using TypeScript... you can preview what's behind the interface."
    - "Strict TypeScript rules reduce cognitive load."

## Essential Questions in State Management

- The biggest question that you need to answer: **Where is this State going to live?**
- You should never have State in two places at any time. **Do not duplicate State.**

- You need to have a single source of truth, and it needs to live in one place.
    - It can live in memory, local storage, session storage, URL bar, and browser history.
    - Example of implementing **State in browser history. 👉**
https://twitter.com/rauchg/status/1245850468212826114

## URL driven Applications

- An example of Natural Language Generation in the URLs.
    - [https://nomadlist.com](https://nomadlist.com/)
    - [https://houzz.com](https://houzz.com)
    - [https://www.parentlist.org/resources/?fwp_grade_level=1st-grade&fwp_pricing=free](https://www.parentlist.org/resources/?fwp_grade_level=1st-grade&fwp_pricing=free)
- **Amazon SEO hack:** generating canonical URLs for better SEO.
- Currently, you can not share search queries on [egghead.io](http://egghead.io/). **URLs = Sharing State.**
    - You need to ask yourself before using URLs to store State: Is this something that you need to share with someone else? If yes, store State in the URLs.
- **URL-driven applications are not hard to build.** The best way is to extract the writing and reading of the URL from your components.
- You are holding the State in the URL; you are not keeping State in React. You can then flow it down the tree.
    - **Example**: [https://www.houzz.com/products/coffee-and-accent-tables/shape_name--Round](https://www.houzz.com/products/coffee-and-accent-tables/shape_name--Round)
- This isn't just an SEO problem, but a State management problem.

## Normalizing Data

- The best way to level up your State game is to **learn how to normalize.**
- The process of normalization is heavily used in every software design because normalizing data has a significant impact on reducing data redundancy.
- **Normalizing data with unlock performance gains.** You need to have a single source of truth for each atomic unit of State. And you only want to make a change in one place.
- Immer - write mutual code.
    - Using immutable data structures provides many benefits, including making your code easier to reason about and less prone to bugs.

        [Immutable JavaScript Data Structures with Immer](https://egghead.io/courses/immutable-javascript-data-structures-with-immer)

        [](https://github.com/immerjs/immer](https://github.com/immerjs/immer))

- Immer - It's useful when making an update at scale using structural sharing. It's super fast, perfect for large nested lists.

## Formik

- [https://formik.com](https://formik.com/) is using Immer when creating deeply nested components.
- Lots of State is being managed in one single place.
- To handle several nested tree updates, it uses recursion, and its handle by an internal engine, using React to evaluate, and Immer to manage the updates.

![](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1618258679/transcript-images/state-management-2021-descriptions/question-3.png)

![](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1618258673/transcript-images/state-management-2021-descriptions/long-question-3.png)

## Recoil

https://codesandbox.io/s/recoil-sandbox-20200516-meh12

- Recoil is a state management library for React, so you need to have to React installed and running to use Recoil.
- Recoil will solve the issue of performance, keeping the typing fast in Formkit.
    - [https://github.com/facebookexperimental/Recoi](https://github.com/facebookexperimental/Recoi)
- With Recoil, you can isolate nested State and ignore the rest of the tree.
- React is not the best option when working with deep, nested trees.
    - "It doesn't always have to be React."
    - "There is no silver bullet when it comes to State Management. If it's confusing for everyone, it's hard for everyone."

Managing Complex State in React with Jared Palmer [explicit]

Paul Henschel is a frontend developer based in Germany and Switzerland. The founder of Luxundlaune, a photography platform in Germany, Paranoidandroid, a custom firmware for Android, and several open-source projects like [react-spring](https://www.react-spring.io) and [react-three-fiber](https://github.com/pmndrs/react-three-fiber).

In this interview, Joel and Paul discuss the biggest challenges in state management, picking a state management library for your project, and the Redux mindset that everything should revolve around State. 

### Why is State management talked about so much when it comes to building an application?

- So many ways you can go about it. There is no one defined way to do it.
    - proxy
    - mutate
    - streaming

### Zustand, react-spring, and react-three-fiber

When starting using Zustand, Paul liked using Redux over things like Mobx or anything that's Magic. But he didn't like the boilerplate or the opinions that came along with it. Then he decided to create something new that came along with Zustand.

react-three-fiber brought its own complications. There were two reconcilers that needed to talk to each other, basically like components. That's when Paul realized there was so much more going on that he didn't even know that he needed. The core fundamentals of React and Redux weren't going to help here.

- Take anything to do with 3-D games, for instance. Refreshing props via React simply wouldn't work based on the fact that it needs to be very fast. React would be refreshing roughly 60 times per second, every frame the object moves to get from point A to point B.
- Redux, at the time, couldn't put them on.
- Zustand resolved these issues by the fact that it can notify a component of changes without re-rendering it.

### Are there too many options in the world?

- Possibly! Every library basically solves a problem. That's how libraries are pretty much created. Take Facebook, for instance. They made a library that solved their problems, and thus [Folly](https://engineering.fb.com/2012/06/02/developer-tools/folly-the-facebook-open-source-library/#:~:text=Facebook%20is%20built%20on%20open,such%20as%20HipHop%20and%20Thrift.) was born.
- Other libraries, such as Recoil, Paul isn't a huge fan of. It's extremely large and has somewhere around 30 API's in it. Even if it is the best thing in the world, there is just so much to learn and that takes a lot of time.
- Recoil is great.
- React is like a petri dish, constantly evolving and upgrading.

### Animation is largely a product of state

- The problems that come up with animations is largely a state management issue.
- Hooks changed the game in this regard. With hooks, you have your bare-bones application and a simple flag that toggles on/off.
- It's state made movable.

### State is the most important part of the application

- Applications should revolve around your state.
- The apps that are made without state in mind are a complete mess.
    - It doesn't scale as well.
    - You're modeling stuff around refactor.
- When writing something big, start with a good, stable state model.

### Redux as a state management solution

- Joel loves the Zen of Redux. the philosophies underneath it, and the core principles over the implementation of the library itself.
    - The mind-blowing idea of the store; the single source of truth; the ability of being able to store everything at the top level.
- For Paul, it was difficult to get into. After hearing about it from basically everyone, decided to give it a go. He really liked it in the beginning.
    - It helped him to also learn JavaScript and functional programming along with Redux.
    - "I'm glad I went through all this churn, and what people call boilerplate."
- Zustand represents those principles at the core fundamentally.
    - It's inspired by and has a direct line that you can draw between the two.
    - "Same idea. New implementation, different use cases perhaps, different ways to think about it, too."

### Do you use state machines?

- Paul didn't really try it at all. It's a bit overarching.
- It's a wall of very specific configuration and It's hard to function like that.
- He likes obstructions and tools on thresholds, not Magic. There is a sweet spot between something that creates and does everything and something that still allows you to be explicit.

### Has anything come out of this, creating these libraries, that surprised you?

- Yes, of course, because there are so many levels that have accumulated now. React green room, React use gesture and switched arms, React-Three-Fiber.
- I enjoy this. For me, that's my reward.

State Management in React with Paul Henschel

### **Have you authored a State Management library?**

- Yes. Animation is entirely State. Moving from State to State in a fluid manner, dealing with interruptions.

    [Animated · React Native](https://reactnative.dev/docs/animated)

- The Animated library is designed to make animations fluid, powerful, and painless to build and maintain.
- Animated focuses on declarative relationships between inputs and outputs, configurable transforms in between, and start/stop methods to control time-based animation execution.
- **The notion of physically-based animation.**
    - Physically-based animation is an area of interest within computer graphics concerned with the simulation of physically plausible behaviors at interactive rates.
    - Native applications are using "springs." Similar to a real springs (physically-based animation). It feels more real life, and it the way how iOS has implemented animations.
    - Problems occur when you need to apply this on the framework level.
- If an animation is interrupted, it will result in a choppy animation. **This is due to JavaScript being single-threaded.**
    - The way native platforms are solving this problem is by moving this process to a different thread.
    - What we have done for Animated is that you define the animated values, then those values are sent to be computed in the dependency tree on a separate thread.
    - Now the challenge is how do you make declaring animations easier.

### **Is there a correlation between State and the *processes*? What layer of State is that?**

- The difference between Animated and Recoil lies in how you update the DOM elements.
    - With Animated, we want to update the final DOM elements.
    - Recoil is a very low level of that implementation. You need to have find grain dependency management.
- **Recoil works and thinks like React.** It uses the React component states and updates them.
    - The atomic unit that you are working on now is a React component.
    - You don't have to invent your own implementation. You can directly target specific React elements without reloading the entire tree.

### **What collaboration and resources came to inform this solution?**

- Animated didn't inspire Recoil. The actual libraries are really small. The problem is how you educate people to start working with these libraries.

### These are complex problems. What are the common patterns when solving State Management?

- **Recoil got inspiration from React Hooks.**
    - With Recoil, you are able to do the same thing as useState but also have access to a regular JavaScript object that you can pass around.
    - This has the benefit in that you no longer need to take over the whole JavaScript bundle.

### **What are the types of State that you have in an application?**

- The first phase of State is the external data source that you get from the server.
- For this type of State, Relay and GraphQL are excellent solutions. GraphQL is declarative. Relay handles local caching - transferring data between minor updates. And Relay is a superb solution to update specific components.

### **Why is Relay not the go-to solution?**

- With Relay, you need to have a GraphQL backend. No easy way to create an integrated compatible backend solution.
- At a conceptual level, we can think about Relay, GraphQL, and Apollo as the same, but at the implementation level, they differ from each other.
- At the end of the day, the technology that you choose to work with will create constraints for your application.
- **How you fetch data will affect the rest of your application.**
- Gatsby uses a Relay-like implementation to build the Graph from 20-something data sources - but they make that invisible when building those structures.
- Another type of website is CRUD apps that want more complex forms. There are no good solutions to manage forms. In the past, Redux was used, but it didn't solve the problem.
- PHP, Rails, WordPress let you generate forms and manage them nicely on the backend.
- Recoil solved problems for Formik. Managing states and updates in nested forms.

    [Jared Palmer and Joel talk about State Management](https://www.notion.so/egghead/Jared-Palmer-and-Joel-talk-about-State-Management-20676ba02a8b4484912e3b59d77c742c)

### **Have you ever explored Falcore?**

- Yes. Falcor is a real-time rendering framework supporting DirectX 12. It aims to improve the productivity of research and prototype projects.

    [NVIDIAGameWorks/Falcor](https://github.com/nvidiagameworks/falcor)

- The idea with Falcor is that we can do the same thing without having a solid schema (Dynamically importing REST points.)
- This solves the same issues when managing State, and it lowers the barrier of entry.

### **What State Management problems did you run into when building Excalidraw?**

[Excalidraw](https://excalidraw.com/)

- The initial plan was to use Recoil. The solution was to create one JSON file to manage the state. Then re-render the whole tree.
- It worked pretty well until we wanted to update different parts at different rates. We wanted the interaction to be faster and making caching easier.
- Recoil would have handled this for us, but we took a different approach; we started building tooling with pure React and JavaScript.
    - We didn't want to add additional features that would make it slower.
    - We implemented the core features from other libraries to avoid adding additional dependencies.
    - This is a design feature; you can start designing backward.
- **Optimizing**
    - At WhatsApp, we optimize by writing small amounts of code and adding little to no dependencies.
    - Facebook takes a different approach. They iterate fast, so they are implemented in multiple libraries.
    - **Both are successful but with different strategies.**

### **When you are doing optimization at scale, is State Management part of that?**

- State Management is part of the conversation. But it's not critical since this is not likely to change much.
- For example, when we re-wrote Facebook from PHP to React + GraphQL + and server-side rendering. The underlying architecture did not change much.
- **To improve the performance, you need to measure it**.
    - Our team has focused on measuring performance in testing, production, etc. Once we have those measurements, we can start implementing tools to track performance.
    - Many teams own different parts of Facebook. We take all of those metrics and put them in a program where executives can review the status.
    - **It's State Management at a business level. Everything is moving-different components.**
    - If you give a Metric to an engineer, they will drive it down. They are excited to make it fast. It's important to track it. If you want to improve performance, you need to track it, improve it, and show it to management.

State Management in React with Christopher Chedeau

Joel and Dave chat about the essential questions around State Management. A critical point mentioned was that programming gets boiled down to managing State, especially when it comes to working with React; this is due to React's functional paradigms. Dave also talked about how Recoil is designed with Concurrent Mode in mind, his experience in open source, Pattern Language, and the different State in a browser.

## Resources

- [Recoil](https://recoiljs.org/)

- [Introducing Concurrent Mode (Experimental) - React](https://reactjs.org/docs/concurrent-mode-intro.html)

### Why are react developers always talking about State Management?

- UI's have been made the same way since small talk in the '70s. MVC
- React changes how you look at it, folding in ideas from functional programming.
- React is a whole new world of possibilities.
- **Programming gets boiled down to State management.**
- State is the easiest place to get yourself in trouble.
- CSS is a stateless example. It's complex, but you cant shoot yourself in the foot as much.
- Async State makes things even more complicated.

### What are the essential questions you ask before you get started?

- Applications have evolved. David doesn't know if there is a "design" phase where you could ask this question. You start with a prototype and move from there.

### As your app evolves, how do you know when you need more tools?

- App for performance analysis. It became successful, so they added a bunch of features.
- It turned out to be really buggy.
- **Recoil applies a functional structure to async processes**. Async processes are just functions evaluated on another host.
- The remaining complexity lies in the non-functional aspects of development.
- They knew that what they were doing was buggy and wasn't working, so they started to solve those problems.

### Why yet another one of these? - this question comes out of the assumption that making a State Management library is a big deal.

- David thinks this library captures some programming patterns written down into some code. Everyone should be doing this.
- **You are always designing. Sometimes you make happy accidents**.
- David doesn't think State management has an established pattern yet.
    - Joel extrapolates to web development in general.
    - Concurrent and scheduling need to be more established before we can come to a consensus on web development.

### Should you use Recoil in every app?

- You could use it in any app, and it gives you patterns and utility hooks that will ensure your app is built for the future.
- Just use react with most apps. The fewer dependencies you have, the more resilient your code.

### Any insight with concurrent mode looming?

- It's a slow process because there's a lot of incompatible code.
- Concurrent mode is very complex. Recoil will work with concurrent mode. **Recoil was designed with concurrent mode in mind.**
- The state definition is incremental and distributed, making code-splitting possible.
- State can be replaced with derived data without modifying the components that use it.

### What's the cool stuff that hasn't been published yet?

- Persistence (Observation API)
- Scaling it to bigger apps with more State.
- Note: portions of code need to be optimized.

## What's the open source experience been like for you?

- It’s been really good. Lots of support from the community.
- Joel mentions Jared Palmer and Joel talk about State Management and how Jared fixed their crippling performance problems with Recoil.

    [Jared Palmer and Joel talk about State Management](https://www.notion.so/Jared-Palmer-and-Joel-talk-about-State-Management-20676ba02a8b4484912e3b59d77c742c)

- This is because Concurrent Mode **rendering is not blocking; it is interruptible.** This improves the user experience.

### When did design patterns fall out of favor? The Gang of Four style patterns

- David thinks that the **good parts are assumed, and the bad parts are mocked**.
- [Christopher Alexander Pattern Language](https://en.wikipedia.org/wiki/A_Pattern_Language) changed the way David looks at his environment.
- The book creates a new language, what the authors call a pattern language derived from timeless entities called patterns.

### Are we just encapsulating patterns into the library?

- People just don't use pattern language anymore. Did Java kill it?
- **It's more of an oral culture rather than a written culture.**
- Cargo holding.
- Maybe this is why people use redux when they don't need to because they don't understand what pattern of redux solves, so they use it every time.

    Jed Watson combining layers of State.
       - Local State
       - shared State
       - Remote State
       - Meta State - you aren’t the source of truth
       - Router State

- David's mental modal:
    - You can add some types of state.
    - Including State shared across tabs.
    - Don't separate router state. You can use a function to put the application state into the router and vice-verse
- **Url bar could be thought of as a component.**
    - **Essential Question:** Why is there a difference between mobile and browser?
- There's an upside to having a browser that knows about all the semantics on your page.

Using Recoil to Manage Orthogonal State in React Apps with David McCabe

Joel and Chance chat about the big ideas of State Management and when you should start implementing a State Machine in your application. Chance gives a walkthrough of how Reach UI handles State, how the `Listbox` component was built, and how reading the React UI source code is an excellent source of learning material.

## Resources:

[Reach UI](https://reacttraining.com/reach-ui/)

## What are the big ideas of State Management?

- A good starting point is understanding why React is so popular. React gave us a very convenient way of thinking about our application based on State. It determined that you're UI is a function of your State.
    - That was a simple and revolutionary idea that changed how we manage the State.
    - Tools like Redux and Flux have helped us think about State at a higher level.
- **State should be managed closer to the components.** The closer you can keep the State to where things are happing, the more deterministic.
- Reach UI - uses a State Machine model.

## When should you add a State Machine?

- It's essential to understand what a State Machine is first. A finite-state machine is a mathematical model of computation. You will only have one State at any given time.
- First, you would define your States and then integrate events.
- **You always want to think like a finite-state machine when building a new component.**
    - Once you start thinking in those terms, you start writing your code differently. An example of this is Boolean props (having a button with three different color props).

## Is our application a State Machine?

- Yes. For example, you can turn a reducer pattern into a State Machine by adding a second reducer.
- State Machines do a great job connecting how designers and developers work/think.
- **Designers are always thinking of State.**
    - If you get a component mockup, you'll get a design with all the different State.
    - They are writing a State Machine in a visual format.

## What was your favorite Component in Reach UI that was a challenge building?

- The `Listbox` component was the most challenging; a `Listbox` presents a list of selectable options in a popover, which is toggled on or off by a button.
- Visually and behaviorally, it is similar to `@reach/menu-button` except that `ListboxOption` components hold a value.
- In this sense, they are more directly comparable to HTML select elements.

[Listbox](https://reacttraining.com/reach-ui/listbox)

- (A bad example of this is Ant Design)[https://ant.design/components/select/](https://ant.design/components/select/)
    - When you open, you can't select on `mouseDown`.  Unlike with the native `select` - [Web/HTML/Element/select](https://developer.mozilla.org/en/docs/Web/HTML/Element/select)
    - People don't use native features due to ascetics preferences and the ability to add functionality.
- **Notes:** you should always try to use the native elements.

## React UI and XState

- Reading the Reach UI source code is an excellent source of learning material.
- Reach UI contains `@xstate/fsm`, a miniature version of XState.
- Before XState, Ryan wrote his own `Transition`:

```jsx
// https://github.com/reach/reach-ui/blob/a376daec462ccb53d33f4471306dff35383a03a5/packages/tooltip/src/index.tsx

/**
 * Finds the next state from the current state + action. If the chart doesn't
 * describe that transition, it will throw.
 *
 * It also manages lifecycles of the machine, (enter/leave hooks on the state
 * chart)
 *
 * @param event
 * @param payload
 */
const transition: Transition = (event, payload) => {
  let stateDef = chart.states[state];
  let nextState = stateDef && stateDef.on && stateDef.on[event];

  // Really useful for debugging
  // console.log({ event, state, nextState, contextId: context.id });
  // !nextState && console.log('no transition taken')

  if (!nextState) {
    return;
  }

  if (stateDef && stateDef.leave) {
    stateDef.leave();
  }

  if (payload) {
    context = payload;
  }

  let nextDef = chart.states[nextState];
  if (nextDef && nextDef.enter) {
    nextDef.enter();
  }

  state = nextState;
  notify();
};
```

- This component also contained a `StateChart`, which takes the main ideas of a State Machine to handle several events.

```jsx
// https://github.com/reach/reach-ui/blob/a376daec462ccb53d33f4471306dff35383a03a5/packages/tooltip/src/index.tsx

const chart: StateChart = {
  initial: IDLE,
  states: {
    [IDLE]: {
      enter: clearContextId,
      on: {
        [MOUSE_ENTER]: FOCUSED,
        [FOCUS]: VISIBLE,
      },
    },
    [FOCUSED]: {
      enter: startRestTimer,
      leave: clearRestTimer,
      on: {
        [MOUSE_MOVE]: FOCUSED,
        [MOUSE_LEAVE]: IDLE,
        [MOUSE_DOWN]: DISMISSED,
        [BLUR]: IDLE,
        [REST]: VISIBLE,
      },
    },
    
	
...
```

- At the end of the day, Reach UI has a great user experience because it's designed from a component standpoint.

## Research of Git History

- Chance went back through the Reach UI git history to analyze and understand in-depth how each component has evolved over time. Then he re-engineered a new component following the Reach UI style.

State Management in React with Chance Strickland

Joel and David chat about the big ideas and the essential questions of State Management and State Machines. Additionally, David also gives a walkthrough of XState, XState Visualizer, and the upcoming dev tools for XState.

## Key Terms

**XState -** is a library for creating, interpreting, and executing finite state machines and statecharts, as well as managing invocations of those machines as actors.

**State Machines** - a mathematical model of computation. It is an abstract machine that can be in exactly one of a finite number of states at any given time.

**Combinatorial Explosion -**  is the rapid growth of the complexity of a problem.

## Resources

- [davidkpiano/xstate](https://github.com/davidkpiano/xstate)

- [David K. 🎹](https://twitter.com/DavidKPiano)

- [davidkpiano - Overview](https://github.com/davidkpiano)

- [Stately Newsletter](https://www.stately.dev)

## Visuals Explanation

![](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1618253832/transcript-images/state-management-2021-descriptions/state-machine-states-events-transitions-actions.jpg)

Source: [https://www.stately.dev](https://www.stately.dev/)

**These notes include:** highlights, expansion of key terms, code blocks, and links to additional resources. **They follow the same structure as the recording.**

## What are the big ideas of State Management?

- It all comes down to applying big ideas from the past, for example, State Machines.
- One of the biggest problems related to State Machines is performance.
- The problems with States are not new.

## Why is this hard to understand these problems?

- **There's a mathematical explication to this.** Once you have more than one piece of State in different places, you faced Combinatorial Explosion.
- **Combinatorial Explosion**

    A combinatorial explosion is the rapid growth of the complexity of a problem due to how the combinatorics of the problem is affected by the input, constraints, and bounds of the problem.

    Combinatorics is an area of mathematics primarily concerned with counting, both as a means and an end in obtaining results.

- An example of this is having ten main ingredients and having the output be 100 different dishes.
- **The most neglected variable is time when it comes to managing State.** We can only think about this in abstract ways.
- "We (developer) do most of the State management in our heads."
    - There's no concrete way to communicate our understanding of States. This is one of the reasons why we have State Machines.

## What are the Essential Questions when people work with State Management?

- First, identify all the pieces of State that you're dealing with.
    - How is this information organized?
    - How can this data change over time?
    - How can you model this data?

## What's a Finite State Machines?

- "XState is like Redux with Rules"
- A finite state machine is a mathematical model of computation that describes the behavior of a system that can be in only one state at any given time.
- Finite State, you can only be in one State at a time.
    - It's more of a mode, "I'm awake & I'm asleep."
- It also describes how one can move from one State to another.

## What's the difference between a State Machine and Statecharts?

- Finite State Machines can represent everything.
- Statecharts are a formalism for modeling stateful, reactive systems.
- David Harel presented this formalism as an extension to state machines in his 1987 paper [Statecharts: A Visual Formalism for Complex Systems](http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf).
    - A way to organize your states. "Sub-States."
- **More resources:**
    - **[Finite-state machine](https://en.wikipedia.org/wiki/Finite-state_machine)** article on Wikipedia
    - **[Understanding State Machines](https://www.freecodecamp.org/news/state-machines-basics-of-computer-science-d42855debc66/)** by Mark Shead
    - **[▶️ A-Level Comp Sci: Finite State Machin](https://www.youtube.com/watch?v=4rNYAvsSkwk)**

## How are State Machine addressing the big ideas of State management?

- Event-Action approach doesn't always make sense. A State Machine has a specific way of transitioning.
    - A state transition defines what the next state is, given the current state and event. State transitions are defined on state nodes.
- **Communication** with humans and machines.
- **More resources:**
    - **[Statecharts: A Visual Formalism for Complex Systems](http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf)** by David Harel
    - **[The World of Statecharts](https://statecharts.github.io/)** by Erik Mogensen
    - [Constructing the User Interface with Statecharts](https://www.amazon.com/Constructing-User-Interface-Statecharts-Horrocks/dp/0201342782) by Ian Horrocks
- **Combinatorial Explosion**
    - State Machines is not something new; it has been implemented across different industries.

## The Overlap of music and State Machines and Statecharts

- When you look at music, there are infinite ways to express a melody; inherently, there are rules.
- **Music makes you a better visual thinker.**
    - This is an example when it comes to modeling State solutions.
- Music is centuries old; its theory is old. Computer science is the music theory of programming.
    - Music theory answers why "this" works, much like when you start using a library, and you realized that it's an elegant solution to a specific problem.

## Building a Statecharts for JavaScript

- The inspiration came from David's first job working with repetitive workflows. Wanting to solve this problem led to researching State Machines.
- Early days it was called "Estado," the Spanish word for State.

## Demo of XState

[Code sandbox demo](https://codesandbox.io/s/exciting-tereshkova-cjpdf?from-embed)

- Normal React Development:

```html
    <div className="App">
      <h1>{toggled ? "Toggled" : "Nope"}</h1>
      <h2>
        {state.value} ({state.context.count})
      </h2>
      <button
        onClick={() => {
          send("TOGGLE");
        }}
      >
        Toggle
      </button>
    </div>
...
```

- The problem is the all the business logic is inside the event handle.
- If you have more business requirements, you'll need to add 'defense logic' to handle more use cases.

## Adding XState

```js
import { createMachine, assign } from "xstate";
import { useMachine } from "@xstate/react";

const toggleMachine = createMachine({
  initial: "untoggled",
  context: {
    count: 0
  },
  states: {
    untoggled: {
      on: { TOGGLE: "toggled" }
    },
    toggled: {
      entry: assign({
        count: context => context.count + 1
      }),
      on: {
        TOGGLE: "untoggled"
      },
      after: {
        1000: "untoggled"
      }
    }
  }
});
```

- `useMachine(machine, options?)` - a React hook that interprets the given machine and starts a service that runs for the component's lifetime.

```js
const [state, send] = useMachine(toggleMachine, { devTools: true });
console.log(state);
const [toggled, setToggled] = useState(false);
```

- We are creating an event-driven approach to handling toggles.
- All the logic is handle inside `toggleMachine`
- With State Machines everything is an event (time is an event).
- Existing machines can be configured by passing the machine options as the 2nd argument of `useMachine(machine, options).`

```jsx
context: {
    count: 0
  },
```

- We can add a side-effects `count: context => context.count + 1` without affecting our main State.

## XState Visualizer

![](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1618256533/transcript-images/state-management-2021-descriptions/xstate-visualizer.png)

## What's the workflow for design States?

- Pen and paper work pretty well. Modeling the behavior of a user is complicated.

![](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1618256586/transcript-images/state-management-2021-descriptions/workflow-for-design-states.png)

- **Dev Tools for XState (coming soon)**
    - CodeSandbox also works pretty well for prototyping state.

## When is XState not appropriate?

- You don't need a library to implement State Machines. You can use patterns in each language.
- XState becomes more valuable when representing Statecharts.
- XState version 5 will be smaller. It will be explicit, small, and fast.
- [See Twitter](https://twitter.com/DavidKPiano/status/1226182960111591426?s=20)

XState for State Management in React Apps with David Khourshid

Joel and Mark Erikson chat about the motivation behind Redux. The historical context and the future of Redux. How Redux Toolkit solves community pain points. Additionally, Mark Erikson gives a walkthrough of how Redux Toolkit works and how to use createSlice, createAsyncThunk, and createEntityAdapter.

## Key Terms

**Redux** - Redux is an open-source JavaScript library for managing application state.

**Immer** - a library created based on the “copy-on-write” mechanism — a technique used to implement a copy operation in on modifiable resources.

**Flux** - is an architecture for creating data layers in JavaScript applications. It was designed at Facebook along with the React library.

**Redux Toolkit** - an add-on package to Redux, which includes opinionated defaults.

## Resources

- [https://twitter.com/acemarke](https://twitter.com/acemarke)
- [Redux Toolkit](https://redux-toolkit.js.org)
- [Mark's Dev Blog](https://blog.isquaredsoftware.com)
- [Redux - A predictable state container for JavaScript apps](https://redux.js.org)

## What keeps you excited about Redux?

- The motivation: people are still using Redux and will continue to use Redux for a long time.

## How do people criticize Redux?

- This blog post was a result of responding to the endless waves of “Redux is dead...”
- People don’t understand the context and history behind why a particular tool exists—for example, jQuery, Angular, Backbone, etc.
- All these tools were created at a specific time, in a particular place, by people trying to solve particular problems.
    - And they were written using the knowledge that existed at that particular time.
    - Understanding the context will help you know where it belongs in the larger picture.
- **Example of this:** "Things You Should Never Do, Part I" by Joel Spolsky.

    “When you throw away code and start from scratch, **you are throwing away all that knowledge**. All those collected bug fixes. Years of programming work.”

## Redux in 2020

- In the **context of Redux**, it came out in 2015. And currently, people ask:
    - Why do I have to dispatch things?
    - Why is it called actions?
    - Why do I need to have separation between data and UI?
- Here, it’s essential to understand that Flux inspired Redux.
    - Like Flux, Redux prescribes that you concentrate your model update logic in a particular layer of your application. Instead of letting the application code directly mutate the data, both tell you to describe every mutation as a plain object called an “action.”
    - The idea was to have access to a single function and not worry about synchronization.
- People learning Redux today don’t see the historical context of those patterns.
- **Another criticism of Redux:** verbosity.
    - The reality is that Redux lets us choose how verbose we’d like your code to be, depending on personal style, team preferences, longer-term maintainability, and so on.
- The **three fundamental principles** of Redux has been over-interpreted:
    - **Single source of truth**: The state of your whole application is stored in an object tree inside a single store.
    - **State is read-only**: The only way to mutate the state is to emit an action, an object describing what happened.
    - **Mutations are written as pure functions**: To specify how the state tree is transformed by actions, you write pure reducers.

## Redux Toolkit

- People have assumed that they need to put everything into Redux. But that’s overkilled. It’s quickly going to become unmaintainable.
- Link to doc: [When should I use Redux?](https://redux.js.org/faq/general#when-should-i-use-redux)
- The approach to dealing with Boilerplate in Redux was to use Immer.
    - **Michel Weststrate** builds Immer - simplifies writing immutable update logic:

[Docs:](https://immerjs.github.io/immer/docs/introduction) “The basic idea is that you will apply all your changes to a temporary draftState, which is a proxy of the currentState. Once all your mutations are completed, Immer will produce the nextState based on the mutations to the draft state.”

[Michel Weststrate creator of Mobx and Immer Libraries for JavaScript](https://egghead.io/podcasts/michel-weststrate-creator-of-mobx-and-immer-libraries-for-javascript)

- Putting everything together changed how Redux Toolkit was created. It addressed three common concerns about Redux:
    1. “Configuring a Redux store is too complicated.”
    2. “I have to add a lot of packages to get Redux to do anything useful.”
    3. “Redux requires too much boilerplate code.”
- Redux Toolkit was built to be beneficial to all Redux users, not just someone new to Redux.
    - It’s very opinionated.

## What are the big ideas of State Management?

- First, ask yourself, what type of app am I building?
    - Where is the data coming in from?
    - How am I interacting with that data?
    - How long does the data need to live?
    - Does the data need to change over time?
- Those questions will dictate what tools to use.
- An **example** of this: Building a MEAN.js AngularJS Project with Create-React-App.

## What does the future look like for Redux?

- "Redux is here to stay..."
- Many downloads are coming from Wordpress’s Gutenberg (block editor) and other larger projects such as Gatsby.

During Gatsby’s bootstrap & build phases, the state is stored and manipulated using the Redux library. The fundamental purpose of using Redux in Gatsby’s internals is to centralize all of the state logic.

- Lots of tools overlap with Redux. It has passed the peak of popularity, and usage will shrink over time. But at the same time, people are going to keep using Redux. Technologies don’t just disappear.
- **Questions to be answered:**
    - How will Redux fit with Concurrent Mode and other features from the React team?
    - Redux will probably make use of `useMutableSource` for compatibility purposes.

[useMutableSource](https://github.com/facebook/react/pull/18000) - enables React components to safely and efficiently read from an unreliable external source in Concurrent Mode. The API will detect mutations that occur during render to avoid tearing, and it will automatically schedule updates when the source is mutated.

## Redux Toolkit

The recommended way to start new apps with React and Redux Toolkit is by using the official Redux+JS template for Create React App.
- The first problem that it’s trying to solve: it takes too many steps to set up a store.

- The solution is to create Reducers that specify how the application’s state changes in response to actions sent to the store.
- Actions only describe what happened but don’t explain how the application’s state changes.
    - With Flux, they had individual stores. In Redux, you have a single Object decided up.
    - It’s generally agreed that functions should be relatively short and ideally only do one specific thing.
- One key/value section of that object is a “slice,” We use the term “slice reducer” to describe the reducer function responsible for updating that slice of the state.

### Structure files as "Ducks":

- Redux itself does not care about how your application’s folders and files are structured. However, co-locating logic for a given feature in one place makes it easier to maintain that code.
- Redux Toolkit addressed a pain point from the community: having several files for one feature.

## Working with `createSlice`

As `createSlice` creates your actions and your reducer for you, you don’t have to worry about type safety here. Action types can just be provided inline.

## Working with `createAsyncThunk`

- This API focuses on creating a standard recommended approach for handling async request lifecycles. Link to documentation of  `createAsyncThunk`:
- If you need to cancel a `thunk` before the payload creator is called, you may provide a condition callback as an option after the payload creator.

## Working with `createEntityAdapter`

- It provides a set of functions that handles the “entity state” structure.
- This API was ported from the `@ngrx/entity library` created by the NgRx maintainers and significantly modified for Redux Toolkit.
- You can decide what `actions` to pass. And the CRUD methods may be used in multiple ways.

## Pull Request #3740

- The Redux documentation needs to be re-written. The current documentation was written in 2015; it’s no longer relevant for new developers.
- **The Master List.**
- Goals:
    - Just Enough of Redux.
    - Learn the basics of Redux and the fastest way to get going, + “the right way.”
    - Show enough real-world patterns that you can build an app.

## Instructional Design

- Egghead has focused on taking subject matter experts and systematically designing, developing, and delivering instructional products.
- The outputs can be a video course, documentation, etc.; what’s important is the output.
- There is no downside to having an instructional design session on the Redux documentation.

## Roam Research

- Roam as a tool for networked thought.
- Powered by bi-directional links.

## Redux Toolkit 1.0

"Redux is not designed to be the most performant or the most concise way of writing mutations. Its focus is on making the code predictable." 

- **Tradeoffs of React Hooks:**

    [https://www.youtube.com/watch?v=xiKMbmDv-Vw&feature=youtu.be](https://www.youtube.com/watch?v=xiKMbmDv-Vw&feature=youtu.be)

    **Recap:** It's about tradeoffs.

    Neither approach is "right" or "wrong" - it's about what tradeoffs you want to make:
       - How much do you want to "separate concerns"?
       - Do you prefer "shallow" testing of components, or fully "mounting/integrating" them?
       - How important are shallow component trees and static typing? 

    [Source to Slides.](https://blog.isquaredsoftware.com/presentations/2019-09-hooks-hocs-tradeoffs/#/16)

Using Redux in Modern React Apps with Mark Erikson

Managing state in a UI is challenging. It's genuinely difficult and the solutions require a depth of knowledge and experience to understand. Everything is a balance of tradeoffs in complexity, performance, and user experience.


This is a series of interviews with experts, open-source maintainers, and UI developers that have combined decades of experience building stateful UI applications for millions of users. 

Part interview, part screen share, these videos should benefit you if you're building web applications.

They focus on React, but the underlying principles are valid for UI work in general (and beyond).

React State Management Expert Interviews

RxJS is a library for composing asynchronous and event-based programs by using observable sequences. 


rxjs

André shows us how to build a minimum functioning RxJS and teaches us some important concepts about reactive programming.




JavaScript has multiple APIs that use callback functions that all do nearly the same thing with slight variations. Event listeners, array methods such as `.forEach`, promises, and NodeJS streams all are very close in the way they are written. Instead, in RxJS you'd unify all of these APIs under one abstraction. 

[Toy Rx](https://github.com/staltz/toy-rx) is an interesting library to go beyond this livestream.


André Staltz Presents: Build your own RxJS

To help accelerate our understanding of React Hooks, Kent is going to live-code a tic-tac-toe app from the ground up taking a Hooks first approach! 

Hooks allow you to better separate your app's visual components from its state and functionality. Kent takes an accessibility and readability first approach to React development, so using hooks to separate your concerns makes your app easier to debug as well as reducing the mental and visual overhead when you are making sense of the code, making your code all around more maintainable. 

- [useHooks.com](https://usehooks.com/)

- Data is static information, state changes over your component's lifetime

- Reducers let you move logic from your component to your pure reducer function. Changes to state always go to the same function, it's great for debugging. 

- Reducer concepts are covered excellently in [Dan Abramov's Getting Started with Redux course](https://egghead.io/courses/getting-started-with-redux)

Using React Hooks to Build a Tic-Tac-Toe Game with Kent C. Dodds

Kent walks us through the internals of dom-testing-library and react-testing-library. 

There is a lot of set-up and tear down when testing UI components. These two libraries take away a lot of the work required to test React components well. 

Jest is commonly used in tandem with react-testing-library to assert results of your components. Jest simulates most browser apis with jsdom. react-testing-library helps you get values out of your components the same way your end users will. 

Links from the show:
- [Testing Library](https://testing-library.com)
- [Testing Javascript](https://testingjavascript.com)
- [Unit vs Integration vs E2E](https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests)
- [Why you shouldn't ReactDOM.render to the body](https://medium.com/@dan_abramov/two-weird-tricks-that-fix-react-7cf9bbdef375)
- [Effective Snapshot Testing]( https://kentcdodds.com/blog/effective-snapshot-testing/)
- [Dev Tips with Kent](https://youtu.be/ttmvAm6esSc)
- https://kcd.im/news

Understanding how react-testing-library works with Kent C. Dodds

Jared Palmer is the creator and maintainer of Formik, the premiere forms solution for React applications. Formik makes forms in React easy by managing your form's state and providing validation on all of your fields. Under the hood, Formik is using **React Hooks**, and today we are going to make our own mini Formik with them! 

`useReducer` is the hook to use for any complex state management. `useReducer` follows the redux principle of returning a modified copy of the state. Writing a custom hook with `useReducer` lets you decouple your handlers and state from the component into a testable function. 

- The `useEffect` hook isn't the same as the `componentDid...` lifecycle hooks. It runs on each render, and you can pass an array that tells it to not run if the value hasn't changed from the previous render. 

- `onBlur` should be used over `onMouseDown` so that errors aren't shown before the user types

- [useHooks.com](https://usehooks.com/)

- [Formik Overview](https://jaredpalmer.com/formik/docs/overview)

Build Your Own Formik Using React Hooks with Jared Palmer

Gatsby is a blazing fast static site generator built with React. Gatsby gives you all of the modern JavaScript tools you want; set up and ready to go out of the box.

gatsby

We take the [gatsby-starter-egghead-blog](https://github.com/eggheadio/gatsby-starter-egghead-blog) and convert it to a Gatsby theme. The process uses Yarn workspaces and is a great demonstration of the flexibility Gatsby gives us for creating and sharing our work.

Creating a Gatsby Theme with John Otander

Bite-size video tutorials for badass web developers.

egghead

Visual Studio Code is an amazing tool for developers. It's lightweight and highly customizable, and perfect for creating web applications.

In this video Burke Holland gives us an overview of VS Code, and shows us a lot of the powerful tools that you can use to increase your productivity and enhance your developer experience.

VS Code for JavaScript with Burke Holland


Using Cursor Chat, you can easily reference an entire directory of files and ask it to generate anything based on those files. This opens up the possibility of using your current code as a reference guide to create new code that follows existing patterns. With this approach, the result can be a polished prompt you can use with any AI to generate consistent and reliable output.

Focus less on crafting the perfect prompt upfront - what matters most is testing and iterating based on the AI's responses. The more results you see from the prompt, the more you can reinforce the good results and prune out the bad results until your prompt is polished enough that you can rely on the prompt to give you consistent quality results.


Create AI Prompts Based on a Directory of Files


With Cursor's "Composer" feature, you can select and entire directory and make changes to every file. This video walks through the process of selecting a folder and refactoring all the files from JavaScript to TypeScript. It also demonstrates other tips around generating terminal commands and customizing your main Cursor "Rules for AI".


Run an AI Refactor on Every File in a Directory with Cursor


This lesson breaks down the concept of asynchronous iterators and generators in JavaScript. Using the Node.js glob function as a practical example, you'll learn how Array.fromAsync facilitates the creation of arrays from asynchronous iterables and how generators can improve performance in file processing tasks.

Efficient File Processing in Node.js with Async Generators and Array.fromAsync

Learn the concept of asynchronous iterators and generators in JavaScript and Node.js Array.fromAsync


With the introduction of Svelte 5, the Svelte team has created a CLI, `sv`, that unifies all the tasks that previously spread across a handful of CLIS (create, add plugins, and migrate).

This lesson will create a Svelte project using the new `sv` CLI and build a counter component to showcase the new `$state`, `$derived`, and `$effect` runes that ship with the new version.



Get Started with Svelte 5 using the sv CLI

You'll create a SvelteKit project using the sv CLI and build a counter component showcasing Svelte $state, $derived, and $effect runes.



pnpm ships with a streamlined, easy way of managing Node.js versions for youself and your team. This video demonstrates why pnpm uses a specific version of Node.js, how to configure it globally, and how to set up your project so that anyone who is running your project will automatically use the same version of Node.js even if that version of Node.js is not installed.


use pnpm as a Node.js version manager

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

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.

Joel Hooks

Search Results