
When working with complex GraphQL schemas, it's common to have shared fields across different types. A fragment colocation pattern allows us to define fragments alongside their corresponding components, resulting in a more cohesive and maintainable codebase.

By colocating fragments, we can easily reuse them across components that share common fields, reducing redundant code and promoting consistency. This can be further enhanced by using other layers of tooling, i.e. converting fragments into Typescript interfaces or auto generating React hooks for queries & mutations.

This note aims to discuss such a pattern, made possible with:

- [React](reacthttps/react.dev)>)
- [Apollo GraphQL](https://www.apollographql.com/docs/): Comprehensive state management library for JavaScript that enables you to manage both local and remote data with GraphQL. We can use it to fetch, cache, and modify application data, all while automatically updating the UI.
- [@graphql-codegen/cli](https://www.npmjs.com/package/@graphql-codegen/cli): Auto generation of typed queries, mutations, subscriptions and typed GraphQL resolvers.

First, let's step back & take a quick look at what is a fragment.

## Fragments

A [GraphQL fragment](http://graphql.org/learn/queries/#fragments) is a piece of logic that can be shared between multiple queries and mutations.

Here's the declaration of a `NameParts` fragment that can be used with any `Person` object:

```graphql
fragment NameParts on Person {
  firstName
  lastName
}
```

Every fragment includes a subset of the fields that belong to its associated type. In the above example, the `Person` type must declare `firstName` and `lastName` fields for the `NameParts` fragment to be valid.

We can now include the `NameParts` fragment in any number of queries and mutations that refer to `Person` objects, like so:

```graphql
query GetPerson {
  people(id: "7") {
    ...NameParts
    avatar(size: LARGE)
  }
}
```

You precede an included fragment with three periods (`...`), much like JavaScript [spread syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax).

Based on our `NameParts` definition, the above query is equivalent to:

```graphql
query GetPerson {
  people(id: "7") {
    firstName
    lastName
    avatar(size: LARGE)
  }
}
```

If we later *change* which fields are included in the `NameParts` fragment, we automatically change which fields are included in operations that *use* the fragment. This reduces the effort required to keep fields consistent across a set of operations.

That's it for fragment. Let's move on to how we actually implement a colocation pattern with fragments and React.

## Example: Animal Cards and Lists

Let's consider an example where we're building an application that showcases cats and dogs. We want to implement reusable components to display individual animal cards (`CatCard` and `DogCard`) as well as lists of animals (`CatList` and `DogList`).

For backend, let's say we are using [NestJS](nestjs-a-progressive-node.js framework](https:/nestjs.com). The schema consists of the following types:

```ts
interface AnimalModel {
  id: string
  name: string
  bread: string
}

interface CatModel extends AnimalModel {
  age: number
}

interface DogModel extends AnimalModel {
  weight: number
}
```

We'll define fragments for the shared fields (`id`, `name`, and `breed`) within the `AnimalModel` type, and define two other fragments for cat & dog that extend from the animal fragment:

```jsx
import { gql } from '@apollo/client'

const ANIMAL_FRAGMENT = gql`
  fragment AnimalFragment on AnimalModel {
    id
    name
    breed
  }
`

const CAT_FRAGMENT = gql`
  fragment CatFragment on CatModel {
    ...AnimalFragment
    age
  }
  ${ANIMAL_FRAGMENT}
`

const DOG_FRAGMENT = gql`
  fragment DogFragment on DogModel {
    ...AnimalFragment
    weight
  }
  ${ANIMAL_FRAGMENT}
`
```

By this point, we are still missing something until we can build the `CatCard` and `DogCard` components - the Typescript types.

With `@graphql-codegen/cli`, we can convert these fragments into Typescript interfaces by running a CLI script. I will not go into details into how the tool work so you should also give [this link](home-graphql-code-generator-the-guild.dev)](https://the-guild.dev/graphql/codegen)) a look - they provide an interactive example.

Basically `@graphql-codegen/cli` will:

- Call our GraphQL backend to fetch the schema
- Scan our codebase for query, mutation and fragment definitions to convert
- Put the output into a file that we have specified

After running the CLI, the typing output will look like below:

```ts
// Output file: graphql/generated.ts

export type AnimalFragment {
	__typename?: 'AnimalModel';
	id: Scalars['String'];
	name: Scalars['String'];
	bread: Scalars['String'];
}

export type CatFragment {
	__typename?: 'CatModel';
	id: Scalars['String'];
	name: Scalars['String'];
	bread: Scalars['String'];
	age: Scalars['Int'];
}

export type DogFragment {
	__typename?: 'DogModel';
	id: Scalars['String'];
	name: Scalars['String'];
	bread: Scalars['String'];
	weight: Scalars['Int'];
}
```

Now that we have everything we need, let's build the `CatCard` and `DogCard` components:

```ts
import { CatFragment } from 'graphql/generated'

// const ANIMAL_FRAGMENT = gql`...`

// const CAT_FRAGMENT = gql`...`

// const DOG_FRAGMENT = gql`...`

const CatCard = (props: { cat: CatFragment }) => {
  const { cat } = props

  // Component rendering logic
}

const DogCard = (props: { cat: DogFragment }) => {
  const { cat } = props

  // Component rendering logic
}
```

The properties `cat` and `dog` will have the types we have defined for the fragments they are actually using - an exact map from GraphQL models to Typescript types that we can be sure will always be accurate as long as the fragments we define match the schema from GraphQL backend.

Next, let's build the `CatList` and `DogList` component and see how we handle queries. Let's defined 2 queries to get cats and dogs:

```ts
// ... import needed stuff
import { gql } from '@apollo/client'

gql`
  query GetCatList {
    cats {
      ...CatFragment
    }
  }
  ${CAT_FRAGMENT}
`

gql`
  query GetDogList {
    dogs {
      ...DogFragment
    }
  }
  ${DOG_FRAGMENT}
`
```

Then we run `@graphql-codegen/cli` again. Depending on how we set-up the CLI, output will vary so the below are what I normally work with:

- `useGetCatListQuery`: A hook that fires a request to fetch cat list & return the data.
- `useGetCatListQueryLazy`: A hook that returns a function to fetch cat list in case we want to manually get the list.
- A variety of Typescript types for query document, variables or return result.

Core features of Apollo such as request state management, caching & revalidating are all functional through these custom hooks.

Now that we have the queries, let's build the `CatList` and `DogList` components:

```ts
// ... import needed stuff
import { useGetCatListQuery, useGetDogListQueryLazy } from 'graphql/generated';

const CatList = () = {
	const data = useGetCatListQuery();
	const cats = data.data?.cats || [];

	if (data.loading) {
		return null;
	}

	return cats.map(cat => <CatCard cat={cat} />);
}

const DogList = () = {
	const [getDogList] = useGetDogListQueryLazy();
	const [dogs, setDogs] = useState<DogFragment[]>([]);

	useEffect(() => {
		getDogList().then(res => setDogs(res.data?.dogs || []));
	}, [])

	return dogs.map(dog => <DogCard dog={dog} />);
}

```

In the above code, the `CatList` and `DogList` are using the query hooks generated in the previous step. `CatList` and `DogList` are using `CatCard` and `DogCard` components, while the queries are using `CatFragment` and `DogFragment` defined together with the card components.

All the types match perfectly.

## The Benefits

This pattern offers several benefits:

- **Code Reusability:** By defining fragments alongside their respective components, we can reuse the fragments in multiple queries and components. This avoids duplicating field definitions and promotes modular and reusable code.
- **Consistency:** Colocating fragments ensures that components sharing common fields always use the same fragment definition. This eliminates inconsistencies and makes it easier to maintain and update the codebase.
- **Readability:** By having fragments colocated with their components, developers can easily understand which fields are being used by a component without having to navigate to a separate file or location.
- **Overfetching Prevention**: This pattern enforces one of GraphQL core values which is to not overfetch. Children components define what they need through fragments, and "bubble" that up to parent components where the queries take place. This make sure that we'll always fetch only what we need.
- **Automatic, Strict Typing**: Instead of manually defining types for the components, we are using types generated based on the fragments they are consuming. This ensure the types we are using will always map to a valid GraphQL model. Whenever we update a fragment, the corresponding type will also be updated.

## The Disadvantages

While the Fragment Colocation Pattern provides several advantages, it's important to consider its limitations:

- **Fragment Duplication:** If fragments are not organized and managed effectively, there is a risk of duplicating fragments across different components. This can lead to maintenance challenges and inconsistencies if modifications are required.
- **Increased Complexity:** As the number of fragments and components grow, managing and organizing the fragments may become more complex. It's crucial to establish clear conventions and guidelines to keep the codebase manageable.
- **Inconventional Approach**: Even though this pattern might look clear on paper, it might be challenge when engineers are new to it, especially if they are used to the REST mindset. Most often this pattern (or maybe GraphQL in general) demands engineers to adopt a completely different mindset when looking at building components.
  - _Personal take:_ _When we bubble types from children to parent, as the component trees grow bigger, it could become harder and harder to trace the fragments back to where they actually begin, especially when we couldn't organize or reuse the components effectively. It's a top-down vs bottom-up way of looking at components. We can quickly find the top, but we might need to dig around for a bit to find the bottom._

## Conclusion

The pattern we have discussed provides an effective way to colocate fragments with their corresponding components, while also provides strict typing and other quality-of-life features with extra toolings.

This pattern enhances code reusability, consistency, and readability. By reusing fragments across components that share common fields, we can avoid duplication and ensure a more maintainable codebase.

On the other hand, we also need to keep in mind its limitations, such as potential fragment duplication and increased complexity with larger codebases, and a steep learning curve.

All in all, personally I think this a pattern that's _easy to adopt, hard to master_ (thus also easy to mess up). It's true to the sprit of GraphQL, and worth a try to see for ourselves how it can give us a different approach to building optimized, well-organized code-bases.


When working with complex GraphQL schemas, it's common to have shared fields across different types. A fragment colocation pattern allows us to define fragments alongside their corresponding components, resulting in a more cohesive and maintainable codebase.

A Fragment Colocation Pattern with React & Apollo GraphQL


## Definition

A definition to Atomic CSS:

> Atomic CSS is the approach to CSS architecture that favors small, single-purpose classes with names based on visual function.

Some might also call it Functional CSS, or [CSS utilities](https://designsystem.digital.gov/utilities/). Basically, you can say an Atomic CSS framework is a collection of the CSS like these:

```css
.m-0 {
  margin: 0;
}

.text-red {
  color: red;
}
```

We have quite a few utilities-first CSS framework like [Tailwind CSS](https://tailwindcss.com/), [Windi CSS](https://windicss.org/) and [Tachyons](https://tachyons.io/), etc. And there are also some UI libraries that come with some CSS utilities as the complement to the framework, for example [Bootstrap](https://getbootstrap.com/docs/5.1/utilities/api/) and [Chakra UI](https://chakra-ui.com/docs/features/style-props).

## Variations

### Static

Similar to how we write normal CSS, we define a unit-based design system for spacing, color, typography, etc. Take a look at these default utility classes from Tailwind:

```css
# 1 unit ~ 0.25rem .m-4 {
  margin: 1rem;
}

.m-8 {
  margin: 2rem;
}
```

**Advantages**

- Easy to set up and use.
- Immutable styles that speak for themselves (by good naming convention).

### Programmatic

This style involves using a build tool to automatically generate styles based on what it finds in the HTML.

For example, given this:

```html
<div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div>
```

The following CSS would be generated:

```css
.Bgc$#0280ae$ {
  background-color: #0280ae;
}
.C$#fff$ {
  color: #fff;
}
.P$20px$ {
  padding: 20px;
}
```

Another example would be Tailwind's JIT mode:

```html
<div className="bg-[#FFF] font-[24px]">...</div>
```

**Advantages**

- Easy to use.
- Stylesheets generated during the build process are fully optimized with no unused styles.
- Much more flexible & spontaneous (... just like inline style).

## Purposes

### Atomic CSS keeps things simple

- Classes are immutable. They only do one thing.
- Naming is straight forward. It's easy to tell what a class does at a glance.
- Using a utility class in an HTML file is unambiguous - we know what we are changing, without concern of breaking something, somewhere else.
- Easy to pick-up without diving too deep into actual stylesheets.

### Atomic CSS keeps things consistent

- Unit-based so styles are consistent & scalable. Let's look into how Tailwind setup their default styles again:
  - `m-4 -> margin: 1rem`, `m-8 -> margin: 2rem` -> 1 unit ~ 0.25rem. With this, when we see `m-40`, we can easily deduce that it's `10rem`.
- Designs that follow an atomic system will be easier for developers to implement.
  - An offset of 1 or 2 pixels while dragging components around in Figma might be neglectible, but applying those styles to the app will bloat it with "magic numbers" that feel random & irrelevant.
  - With designers & developers agreeing on a common styling system, developers still know what they have to use when encountering "magic numbers" in the design. They can see a `padding: 63px` and know the designers actually meant `padding: 64px` (divisible by 4).

### Atomic CSS is not inline styles

Inline styles have long been deemed a bad practice, and many people dislike Atomic CSS because they think _it shares the same suffer with inline styles_.

Here’s an example:

> What if we want to change everything with a `.black` class to be navy instead?

An easy solution would be finding all instances of `.black` with our Text Editor and replace them manually. However, it's a _tedious_ deed, and exactly what is frowned upon by the community. People value _reusability_.

**But we do have reusability with Atomic CSS** (along with many other things).

#### Reusability

Reusability of Atomic CSS comes from the way we use them. With libraries such as React, it's easy to define a _reusable_ component, with all the styles bundled inside. Now changing the color of a widely-used button is a one-line operation:

```jsx
export const CommonButton = () => {
  return (
    <button type="button" className="bg-primary">
      Button
    </button>
  )
}
```

Combining with suitable tools, we can make it even more flexibile:

```jsx
import { css } from '@linaria/core'

const reusableButtonClassName = css`
  @apply p-2 rounded bg-white font-base border-secondary;
  line-height: 1;

  @screen md {
    @apply font-xl;
  }
`

const reusableActiveButtonClassName = css`
  @apply border-primary;
`

export const CommonButton = ({ isActive }) => {
  return (
    <button type="button" className={['reusableButtonClassName', isActive && 'reusableActiveButtonClassName']}>
      Button
    </button>
  )
}
```

As you can see, we are utilizing the strength of both Atomic CSS and [css-in-js]().

#### Abstraction

With atomic classes, it is possible to create abstractions that would be impossible with inline styles.

```html
<p style="font-family: helvetica; color: rgb(20, 20, 20)">Inline styles suck.</p>
<p class="helvetica rgb202020">Badly written CSS isn't very different.</p>
<p class="sans-serif color-dark">Utility classes allow for abstraction.</p>
```

The first two examples shown above would require a manual find-and-replace in order to update styling were the design to change. The styles in the third example can be adjusted in a single place within a stylesheet.

#### Tooling

Sass, Less, PostCSS, Autoprefixer… The CSS community has created a lot of useful tools that weren’t available for inline styles.

#### Brevity

Rather than writing out verbose inline styles, atomic classes can be terse abbreviations of declarations. It’s less typing: `mt-0` vs `margin-top: 0`, `flex` vs `display: flex`, etc.

#### Specificity

Inline styles have the 2nd highest level of specificity (only less than `!important`) .The lower specificity of atomic classes compared to inline styles is a good thing. It allows more versatility.

#### Possibilities

Utility classes can do things inline styles can't.

Inline styles do not support media queries, pseudo selectors, `@supports`, or CSS animations. Perhaps you have a single hover effect you want to apply to disparate elements rather than to only one component.

```css
.circle {
  border-radius: 50%;
}

.hover-radius-0:hover {
  border-radius: 0;
}
```

Simple reusable media query rules can also be turned into a utility class. Its common to use a classname prefix for small, medium and large screen sizes. Here is an example of a flexbox class that will only apply on medium and large screen sizes:

```css
@media (min-width: 600px) {
  .md-flex {
    display: flex;
  }
}
```

## Atomic CSS is not all or nothing

There's no doubt CSS utilities can cover a lot of common use-cases, but it's not all we need. There are plenty of cases where utility classes aren’t the best option:

- If you need to change a lot of styles for a particular component inside of a media query.
- If you want to change multiple styles conditionally during run-time, based on a component's state.

Refer back to [this section](#Reusability) for a sample scenario. Utility classes can coexist with other approaches. It's just a good idea to define base styles and sane defaults globally.

## References

- https://antfu.me/posts/reimagine-atomic-css
- https://css-tricks.com/growing-popularity-atomic-css/
- https://css-tricks.com/lets-define-exactly-atomic-css/


This article provides an overview of Atomic CSS, including its definition, variations, purposes, and how it compares to other CSS approaches.

An Introduction to Atomic CSS


## Introduction

Mock Service Worker (MSW) is an API mocking library that leverages the Service Worker API to intercept requests. It offers unique features that set it apart from traditional mocking libraries, making it a go-to choice for developers. With MSW, you can seamlessly mock both RESTful and GraphQL APIs, providing flexibility for various API architectures. Additionally, MSW supports both Node.js and browser environments, enabling consistent API mocking across different parts of your application. Let's explore how MSW empowers developers to reliable web applications by seamlessly working in both Node.js and browser environments

## Applying MSW for API Interception in Development

MSW operates client-side by using a Service Worker to intercept requests. However, we don't have to write any of the worker's code by ourselves, but rather copy the worker file distributed by the library. This CLI will help us to do that

```bash
npx msw init <PUBLIC_DIR> --save
```

To configure the worker:

```js
// src/mocks/browser.js
import { setupWorker } from 'msw'
import { handlers } from './handlers' // list of request handlers

// This configures a Service Worker with the given request handlers.
export const worker = setupWorker(...handlers)
```

To start the worker:

```js
// src/index.js
import React from 'react'
import ReactDOM from 'react-dom'
import App from './App'

if (process.env.NODE_ENV === 'development') {
  const { worker } = require('./mocks/browser')
  worker.start()
}

ReactDOM.render(<App />, document.getElementById('root'))
```

Let's consider a scenario where we have an `App` component, as shown in the code snippet below. This component makes an API request, which may not be fully implemented on the backend side, or we might want to test how our component handles in different response data or error responses

```js
// src/App.js
function App() {
  const { data, error } = useFetch('https:/example.com/api/usage')
  if (error) {
    return <div className="error">{error.message}</div>
  }
  return (
    <div className="App">
      <h1>API mocking example</h1>
      <div>{data.firstName}</div>
    </div>
  )
}
```

Now, we can mock api response by adding MSW handlers

```js
// src/mocks/handlers.js
import { rest } from 'msw'

export const handlers = [
  //respond with mock data
  rest.get('https:/example.com/api/usage', (req, res, ctx) => {
    return res(
      ctx.status(301),
      ctx.json({
        id: 1,
        firstName: 'Dwarves',
      }),
    )
  }),
  // Alternatively, throw an error
  rest.get('https:/example.com/api/usage', (req, res, ctx) => {
    return res(ctx.status(500), ctx.json({ message: 'Internal Server Error' }))
  }),
]
```

This allows us to verify that our component behaves correctly and handles various API responses or errors gracefully, even if the backend is not fully implemented or we want to test different scenarios without relying on the actual API response.

## Applying MSW for React Testing

One of the most common use cases for MSW is leveraging its request handlers for integration tests. MSW allows you to seamlessly incorporate mocking into any Node process To configure the server:

```js
// src/mocks/server.js
import { setupServer } from 'msw/node'
import { handlers } from './handlers'

// This configures a request mocking server with the given request handlers.
export const server = setupServer(...handlers)
```

Before running your test, start the MSW server:

```js
beforeAll(() => server.listen())
```

After each test, make sure to clean up by stopping the server and resetting any request handlers that were added on runtime:

```js
afterEach(() => {
  server.resetHandlers()
  cleanup()
})

afterAll(() => server.close())
```

Basic example of an integration test over the `App` component.

```js
import React from 'react'
import { render, screen } from '@testing-library/react'
import App from './App'

test('passes', async () => {
  render(<App />)

  expect(
    // Expect the mocked response to be present in the DOM.
    await screen.findByText(`Dwarves`),
  ).toBeInTheDocument()
})
```

you also can add additional handlers during runtime to handle different scenarios in different tests. Here's an example:

```js
test('handle error responses', async () => {
  render(<App />)
  // a runtime handler which
  server.use(
    rest.get('https:/example.com/api/usage', (req, res, ctx) => {
      return res(ctx.json({ message: 'Internal Server Error' }))
    }),
  )
  const errorElement = screen.getByText('Internal Server Error', { className: 'error' })
  expect(errorElement).toBeInTheDocument()
})
```

The `server.use` function allows us to add a runtime handler to our mock server. However, it's important to note that any handlers added in runtime will be removed when `server.resetHandlers()` is called.

## Reference

- [Mocking API Servers with Mock Service Worker (MSW)](https://blog.openreplay.com/mocking-api-servers-with-mock-service-worker-msw/)
- [MSW Documentation](https://mswjs.io/docs/)


Mock Service Worker (MSW) is an API mocking library that leverages the Service Worker API to intercept requests. It offers unique features that set it apart from traditional mocking libraries, making it a go-to choice for developers. With MSW, you can seamlessly mock both RESTful and GraphQL APIs, providing flexibility for various API architectures. Additionally, MSW supports both Node.js and browser environments, enabling consistent API mocking across different parts of your application.

Applying Mock Service Worker (MSW) for Seamless Web Development


## Atomic design pattern

Atomic design is a methodology for crafting design systems with five key fundamental building blocks, which, when combined, promote consistency, modularity, and scalability.

### Why use atomic design

- Atomic design provides frontend engineers with flexible and consistent designs from the beginning.
- We can move from the abstract to the concrete thanks to Atomic design. As a result, we can design systems that encourage consistency and scalability while also displaying information in its final context. Additionally, by putting a system together rather than taking it apart, we avoid picking out the best patterns later.
- The method fits incredibly well with component-based architectures like React, Vue,...

## How does it work?

There are 5 distinct levels of atomic design which are: atoms, molecules, organisms, templates, and pages.

![](assets/atomic-design-pattern_atom-design-structure.webp)

### Atoms

- Atoms are the basic building blocks of matter. When applied to web interfaces, they are our `HTML` tags like an `input` or a `button`.
- These are fairly abstract elements which are often not useful on their own but are good references in the context of a pattern if seen on a bigger picture.

![](assets/atomic-design-pattern_atom-atomic-design.webp)

**Molecules**

Just like in chemistry, molecules are a set of atoms combined. This could include a form input with a title and input standing next to each other or a header containing multiple atoms like icons, buttons, or inputs.

![](assets/atomic-design-pattern_molecule-atomic-design.webp)

### Organisms

Molecules give us some functional building blocks to work with, and they are a sub-set of organisms. Molecules when joined together create organisms which is a relatively complex and distinct section of an interface.

![](assets/atomic-design-pattern_organisms-atomic-design.webp)

### Templates

Templates consist mostly of groups of organisms to form pages, keep in mind that these template doesn't contain data and only contain props.

Templates begin their life as HTML wireframes, but over time become the final deliverable.

t this stage we can really see the design coming together and making more sense for the clients to see the layout of the interface before finalizing it.

![](assets/atomic-design-pattern_template-atomic-design.webp)

### Pages

Pages are specific instances of templates. Here, placeholder content is replaced with real representative content to give an accurate depiction of what a user will ultimately see.

![](assets/atomic-design-pattern_page-atomic-design.webp)

### Atomic design folder structure

This is an example of an application folder structure using atomic design, as you can see there are 5 distinct layers and you can organize them in anyway you want following your own preference.

![](assets/atomic-design-pattern_folder-structure-atomic-design.webp)

## Reference

- https://bradfrost.com/blog/post/atomic-web-design/#atoms
- https://andela.com/insights/structuring-your-react-application-atomic-design-principles/
- https://blog.ippon.tech/atomic-design-in-practice/


Atomic design is a methodology for crafting design systems with five key fundamental building blocks, which, when combined, promote consistency, modularity, and scalability.

Atomic Design Pattern


Let's say we want to create a `Text` component with React and Typescript. A basic implementation could look like:

```typescript
import React from 'react'

type TextProps = {
  children: React.ReactNode
  size?: 'sm' | 'md' | 'lg'
  color?: 'default' | 'primary' | 'secondary'
  className?: string
}

const Text = ({ children, className, size, color }: TextProps) => {
  // hooks to return CSS class base on component props
  const classes = useGetClasses('Text', { size, color })

  return <p className={clsx(classes, className)}>{children}</p>
}
```

This component works for simple use-cases but if we care about semantic HTML (use HTML heading tags to display titles or subtitles, `<p/>` for paragraph) it doesn't help. We need to adjust the above implementation by adding a `as` (you can name it anything you like) property to determine which tag we want to render.

```typescript
type TextProps = {
    children: React.ReactNode
    as?: any // We don't know the type of this property yet
}

const Text = ({ children, as, ...rest }: TextProps) => {
    // other code
    ...

    const Component = as || 'p';

    return (
        <Component {...rest}>{children}</Component>
    )
}

// Usage
// display with h1 tag
<Text as='h1'>Title</Text>
// display with p tag
<Text as='p'>Long paragraph</Text>
```

Our `Text` component works as expected but these are some couple of issues:

- `as` property is `any` so we can pass anything we want even invalid tag.
- We want to pass more attributes which belong to the HTML tag we provide

```typescript
<Text as="label" htmlFor="username">
  Username
</Text>
```

To fix the first issue, we need `as` only accepts a valid React element type. Fortunately, we can achieve this by using : `React.ElementType`. Update the implementation:

```typescript
import React from 'react';

type TextProps<C extends React.ElementType> = {
  children: React.ReactNode;
  as?: C;
  // other properties
};

const Text = <C extends React.ElementType>({ children, as }: TextProps<C>) => {
  // other code
    ...

  const Component = as || 'p';

  return <Component>{children}</Component>;
};
```

Now typescript will complain if you try to pass an invalid html tag

```typescript
// It's ok
<Text as='p'>Hello world</Text>
// Error!!!! Type '"vincenzo"' is not assignable to type 'ElementType<any> | undefined'
<Text as='vincenzo'>Hello world</Text>
```

To solve second issue, once again, React provides us a useful type `React.ComponentPropsWithoutRef`.

```typescript
type TextProps<C extends React.ElementType> = {
  children: React.ReactNode
  as?: C
} & React.ComponentPropsWithoutRef<C>
```

Essentially, the type of `TextProps` is an object type containing `children`, `as` and all valid component properties that correlates with `as` tag.

Now, let’s give the solution a try! We try to add `htmlFor` property to a `Text` component with `as` is `p`. That’s wrong, and righty caught by TypeScript with the error: `Property 'htmlFor' does not exist on type...`

```typescript
// It's ok
<Text as='label' htmlFor='username'>
    Username
</Text>
// Error!!!! Property 'htmlFor' does not exist on type 'IntrinsicAttributes & { children: ReactNode; as?: "p" | undefined; }....
<Text as='p' htmlFor='username'>
    Username
</Text>
```

Our component is looking good right now but we still have an issue. The `as` property is optional, if we omit it, the component will render as `p` tag (as we expected) but Typescript can't know about this so it can't check the valid properties for this component.

```typescript
// No error !!! But it should be
<Text htmlFor="username">User</Text>
```

To fix this issue, we need to assign a default type for type parameters in a generic type.

```typescript
const Text = <C extends React.ElementType = 'p' /* default type */>({
  children,
  as,
  ...rest
}: TextProps<C>) => {
  // other code
   ...

  const Component = as || 'p';

  return <Component {...rest}>{children}</Component>;
};
```

The previous example we had should now throw an error, that is when you pass `htmlFor` to the `Text` component without an `as` prop. It's magic. ✨✨

We still can improve our `Text` component. As we know, some html tags have some internal properties like `color`, if we want to provide our own `color` property (or other properties), we just don't want to mess it up. We need to filter our own properties out of internal properties.

```typescript
// our custom text properties
type Props {
    color?: 'primary' | 'secondary',
    size?: 'sm' | 'md' | 'lg'
}
// omit internal properties
Omit<React.ComponentPropsWithoutRef<C>, keyOf Props>
```

The full implementation looks like

```typescript
type Props<C extends React.ElementType> = {
  children: React.ReactNode;
  as?: C;
  color?: 'primary' | 'secondary';
  size?: 'sm' | 'md' | 'lg';
  // other properties...
};

type TextProps<C extends React.ElementType> = Props<C> &
  Omit<React.ComponentPropsWithoutRef<C>, keyof Props<C>>;

const Text = <C extends React.ElementType = 'p'>({
  children,
  as,
  ...rest
}: TextProps<C>) => {
  // other code
    ...

  const Component = as || 'p';

  return <Component {...rest}>{children}</Component>;
};
```

Our `Text` component is strongly typed.

Now, let's take it one step further. We want our solution works for other components not only `Text`. To make our solution reuseable, we can add one more generic type which represent the custom component.

Before going ahead, follow the `separation of concerns` principle, we should move `as` property out of our custom properties and define its own type.

```
type AsProp<C extends React.ElementType> = {
  as?: C;
};
```

Our reuseable solution will look like

```typescript
type AsProp<C extends React.ElementType> = {
  as?: C
}

type PropWithAs<C extends React.ElementType, P = {}> = P & AsProp<C>

export type PolymorphicComponentProps<
  C extends React.ElementType,
  Props = {}, // adding one more generic type
> = PropWithAs<C, Props> & Omit<React.ComponentPropsWithoutRef<C>, keyof PropWithAs<C, Props>>
```

Now we can go ahead and use `PolymorphicComponentProps` on our components as follows:

```typescript
// Text component
type TextProps = {
  children: React.ReactNode;
  color?: 'primary' | 'secondary';
  size?: 'sm' | 'md' | 'lg';
 // other properties...
};

const Text = <C extends React.ElementType = 'p'>({
  children,
  as,
  ...rest
}: PolymorphicComponentProps<C, TextProps>) => {
    // other code
    ...

  const Component = as || 'p';

  return <Component {...rest}>{children}</Component>;
};

// Usage
<Text as='h1'>Heading</Text>
<Text as='label' htmlFor='username'>
Username
</Text>

// Button component
type ButtonProps = {
  children: React.ReactNode;
  color?: 'primary' | 'secondary';
  size?: 'sm' | 'md' | 'lg';
 // other properties...
};

const Button = <C extends React.ElementType = 'button'>({
  children,
  as,
  ...rest
}: PolymorphicComponentProps<C, ButtonProps>) => {
    // other code
    ...

  const Component = as || 'button';

  return <Component {...rest}>{children}</Component>;
};

// Usage
<Button>Submit</Text>
<Button as='a' href='/login'>Login</Text> // act as a link

```

Everything works like a charm. ✨✨

## How about `ref`?

To write a functional component which support Ref forwarding, we can use `React.forwardRef` function. The `Button` component will be look like

```typescript
const Button = React.forwardRef<HTMLButtonElement, ButtonProps>((props, ref) => {
  const { children, ...rest } = props

  return (
    <button ref={ref} {...rest}>
      {children}
    </button>
  )
})
```

To create polymorphic component, we need to replace `HTMLButtonElement` with a generic type `C`. Unfortunately we can't do that, `forwardRef()` is a function call so we can't define a generic type. So we came up with defining type for the function inside `forwardRef()`.

```typescript
const Button = React.forwardRef(
  <C extends React.ElementType = 'button'>(
    props: PolymorphicComponentProps<C, ButtonProps>,
    ref: unknown, // we still don't know yet
  ) => {
    const { as, children, ...rest } = props
    const Component = as || 'button'
    return (
      <Component ref={ref} {...rest}>
        {children}
      </Component>
    )
  },
)
```

So what type of the`ref` object? Remember this guy `React.ComponentPropsWithoutRef`? he has a brother named `React.ComponentPropsWithRef` which includes all the relevant component props based on the element type, plus the ref object. Let's define a new helper type, `PolymorphicRef`, that returns the type of the ref object for the polymorphic component.

```typescript
type PolymorphicRef<C extends React.ElementType> = React.ComponentPropsWithRef<C>['ref']

const Button = React.forwardRef(<C extends React.ElementType = 'button'>(props: PolymorphicComponentProps<C, ButtonProps>, ref: PolymorphicRef<C>) => {
  const { as, children, ...rest } = props
  const Component = as || 'button'
  return (
    <Component ref={ref} {...rest}>
      {children}
    </Component>
  )
})
```

Our `Button` component still isn't strongly typed. We need to explicitly defined the type annotation for it. `Button` component will be receive `ButtonProps` and return a JSX

```typescript
type ButtonComponent = (props: ButtonProps) => React.ReactElement | null
```

The final step is to update `ButtonProp` to support `PolymorphicRef`

```typescript
// new helper type which includes the `ref` property for the polymorphic component
type PolymorphicComponentPropsWithRef<
  C extends React.ElementType,
  Props = {}
>
 = PolymorphicComponentProps<C, Props> & { ref?: PolymorphicRef<C> }

type CustomButtonProps = {
  children: React.ReactNode;
  color?: 'primary' | 'secondary';
  size?: 'sm' | 'md' | 'lg';
};

type ButtonProps<C extends React.ElementType> = PolymorphicComponentPropsWithRef<
  C,
  CustomButtonProps
>

type ButtonComponent = <C extends React.ElementType = 'button'>(
  props: ButtonProps<C>,
) => React.ReactElement | null

const Button: ButtonComponent = React.forwardRef(
  <C extends React.ElementType = 'button'>(
    props: ButtonProps<C>,
    ref: PolymorphicRef<C>
  ) => {
    const { as, children, ...rest } = props;

    const Component = as || 'button';
    return (
      <Component ref={ref} {...rest}>
        {children}
      </Component>
    );
  }
);

// Useage
const buttonRef1 = React.useRef<HTMLButtonElement | null>(null);
const buttonRef2 = React.useRef<HTMLDivElement | null>(null);

// It's ok
<Button ref={buttonRef1}>Button1</Button>
// Error!!!! Type 'MutableRefObject<HTMLDivElement | null>' is not assignable to type 'RefObject<HTMLButtonElement>'...
<Button ref={buttonRef2}>Button2</Button>

```

Finally, we now have a complete solution.

```typescript
import React from 'react'

// base types
type AsProp<C extends React.ElementType> = {
  as?: C
}

type PropWithAs<C extends React.ElementType, Props = {}> = Props & AsProp<C>

type PolymorphicComponentProps<C extends React.ElementType, Props = {}> = PropWithAs<C, Props> & Omit<React.ComponentPropsWithoutRef<C>, keyof PropWithAs<C, Props>>

type PolymorphicRef<C extends React.ElementType> = React.ComponentPropsWithRef<C>['ref']

type PolymorphicComponentPropsWithRef<C extends React.ElementType, Props = {}> = PolymorphicComponentProps<C, Props> & { ref?: PolymorphicRef<C> }

// Usage

// Text component
type CustomTextProps = {
  children: React.ReactNode
  color?: 'primary' | 'secondary'
  size?: 'sm' | 'md' | 'lg'
}

type TextProps<C extends React.ElementType> = PolymorphicComponentProps<C, CustomTextProps>

const Text = <C extends React.ElementType = 'p'>({ children, as, ...rest }: TextProps<C>) => {
  const Component = as || 'p'

  return <Component {...rest}>{children}</Component>
}

// Button component
type CustomButtonProps = {
  children: React.ReactNode
  color?: 'primary' | 'secondary'
  size?: 'sm' | 'md' | 'lg'
}

type ButtonProps<C extends React.ElementType> = PolymorphicComponentPropsWithRef<C, CustomButtonProps>

type ButtonComponent = <C extends React.ElementType = 'button'>(props: ButtonProps<C>) => React.ReactElement | null

const Button: ButtonComponent = React.forwardRef(<C extends React.ElementType = 'button'>(props: ButtonProps<C>, ref: PolymorphicRef<C>) => {
  const { as, children, ...rest } = props

  const Component = as || 'button'
  return (
    <Component ref={ref} {...rest}>
      {children}
    </Component>
  )
})
```

Congratulation, we have successfully built a strongly typed Polymorphic React Component with Typescript. 🎉🎉🎉🎉


This article provides a step-by-step guide on how to build polymorphic React components with Typescript, covering the necessary concepts and techniques to create flexible and reusable components.

Build polymorphic React components with Typescript


![](assets/continuous-translation_eaf982ca480d0677ec9d8fd34553b51a_md5.webp)

Continuous Translation (CT) is a modern approach to translation management that involves synchronizing software development and translation workflows. This means that developers, translators, and product owners work together in a continuous cycle to ensure that all translations are up-to-date and aligned with the latest software developments.

Unlike traditional translation workflows, Continuous Translation eliminates the need for file and space synchronization between different stakeholders, streamlining the translation process and promoting better collaboration. By implementing Continuous Translation, companies can achieve faster development cycles, higher-quality translations, and a better user experience for their customers.

## Working with localization

### How localization generally works

![](assets/continuous-translation_0ca3440b9dbd840d349d587dd7fd6a1d_md5.webp)

The classical or typical approach in any software project will have translated data be coupled with the repository (plus its software release) and its access to the data. This data could exist in a database or directly as a file. Changes to the data would be dependent on the coupling of the git repository and the translation management system, which becomes a blocker for translation teams.

### Alternative solutions to localization

In order to reduce the friction between the developing team and the translation team, we can remove data and process coupling between systems of both teams by centralizing the data to allow for continuous translation. In this article we’ll discuss 2 possible solutions to integrate continuous translation into our current system:

- **Solution 1**: implement an ad-hoc solution ourselves with help from Google Sheets (using Google Translator under the hood).
- **Solution 2**: translation as a service - we use a third party service for manage our translations.

### Solution 1: Google Sheets

Google Sheets is a free and easy-to-use tool that allows us to manage translations with all stakeholders. Before deploying the app, developers can use Git actions to fetch the latest version of the Google Sheets and generate the locale translation files.

Here are what the steps to use Google Sheets would look like for managing translations:

**Step 1:** Create a Google Sheet that contains all supported translation items. Here is an example **[template](https://docs.google.com/spreadsheets/d/1jjVDCMAmS6WySmB7L25yNCZX-X3jEwrrqLhqOBzVEs0/edit?usp=sharing)** you can use. **Step 2:** Fetch data from Google Sheets using the following code:

_Make sure to replace the _`***sheetId***`_ and _`***sheetName***`_ with your own values_

```javascript
// Save on './public/spreadsheet.ts' file
const sheetId = '<Sheet-ID>'
const sheetName = '<sheet-name>'
const baseUrl = `https://opensheet.elk.sh/${sheetId}/${sheetName}`

// Path to store all translation data
const translateDataPath = './public/locales/translate-data.json'

export const getJsonData = async () => {
  const res = await fetch(baseUrl, {
    method: 'GET',
    headers: {
      'Content-Type': 'application/json',
      accept: '*/*',
      authority: 'opensheet.elk.sh',
    },
    mode: 'cors',
    credentials: 'omit',
  })

  if (res.ok) {
    return await res.json()
  }
}

getJsonData().then((data) => {
  const fs = require('fs')
  let myObject = data

  // Writing to our JSON file
  var newData = JSON.stringify(myObject, null, 2)
  fs.writeFile(translateDataPath, newData, (err) => {
    // Error checking
    if (err) throw err
    console.log('New data added')
  })
})
```

**Step 3: **After having obtaining the translation data, generate locale files for supported languages using the following code:

```javascript
// Save on './public/manage-translations.ts' file
import path from "path";
import fs from "node:fs/promises";
import fsExtra from "fs-extra";
import _ from "lodash";

import dotenv from "dotenv";
dotenv.config({ path: ".env.local" });
dotenv.config({ path: `.env.${process.env.NODE_ENV}` });
dotenv.config();

const validLang = ["en-US", "de-DE", "fr-FR"];
const defaultLanguage =
	process.env.LOCALE == null ? "en-US" : validLang.includes(process.env.LOCALE) ? process.env.LOCALE : "en-US";

const configs = {
	defaultLanguage,
	otherLanguages: validLang.filter((lang) => lang !== defaultLanguage),
	rootExportPath: "./public/locales",
};

const allLocales = [];

async function generateJSONFiles() {
	const data = await fs.readFile("./public/locales/translate-data.json", "utf8");
	const jsonData = JSON.parse(data);
	const locales = Object.keys(jsonData[0]).filter((key) => key !== "elementId");
	const result = locales.map((locale) => {
		const data = {};
		jsonData.forEach((item) => {
			data[item.elementId] =
```

### Solution 2: Use a translation management platform

For this approach, we can use [Locize](https://locize.com/) as our continuous localization management platform. This approach isn’t limited to Locize, but the idea is to have a platform to decouple software release from the translation work and minimize work friction for translation.

![](assets/continuous-translation_5d971ebb8af780ed2ad9e7626daf0d8c_md5.webp)

Locize has integration support for a variety of frontend systems. You can integrate Locize by following steps:

- Follow [https://docs.locize.com/integration/getting-started](https://docs.locize.com/integration/getting-started) to create a Locize account and project.
- After the project is created, we will have `project id` and `api key`.
- Use [https://github.com/locize/locize-cli](https://github.com/locize/locize-cli) to synchronize the existing translations with Locize

There are three ways to use `Locize` in your app:

- **Approach 1**: Use Locize live download on the client-side only. This option involves bundling translations in your app to prevent an elevated amount of downloads on the server-side. Before deploying your app, synchronize your translations with Locize so that they are bundled in your app. This way, your server-side will not generate any downloads to the Locize CDN during runtime, but only on the client-side.
- **Approach 2:** Configure Locize to download translations live on both client (browser) and server (node.js).

> Do not use this option if you have a `serverless environment` as it can generate too many download requests and run up your bill.

- **Approach 3:** Bundle translations with your app. This option involves bundling translations in your app at build time. It's recommended to use this option if you have a small number of translations or if your translations don't change frequently.

### Comparisons between solutions

**Solution 1** recommends using a custom translation file and providing translations for each language in a separate JSON file. The translation file is then loaded on the server side and used to render the content in the appropriate language. This solution is relatively simple and straightforward to implement, but it can become cumbersome to manage as the number of languages and translations grows.

**Solution 2** proposes using a translation management platform, with one example using Locize, which allows for continuous localization management. This solution involves integrating Locize into the application, synchronizing the existing translations with Locize, and then bundling the translations in the application using one of three different possibilities, depending on the specific use case. This solution requires more setup and configuration but can provide a more scalable and streamlined approach to managing translations.

In summary, `Solution 1` is a simpler and cheaper approach to manage translations, while `Solution 2` is a more advanced solution that provides more flexibility and scalability in managing translations.

### Pros and cons when integrating Continuous Translation into your app

**Pros**

- **Faster development cycles**: With Continuous Translation, developers and translators work together in a continuous cycle, ensuring that translations are updated in real-time as new features are developed. This leads to faster development cycles and quicker time-to-market.
- **Improved translation quality**: Continuous Translation promotes better collaboration between developers and translators, which can lead to higher-quality translations that accurately reflect the intended meaning of the original content.
- **Better alignment between teams**: By eliminating file and space synchronization issues, Continuous Translation helps to align developers, translators, and product owners more closely, reducing communication errors and promoting better collaboration.
- **Reduced costs**: Traditional translation workflows can be time-consuming and costly. By streamlining the translation process, Continuous Translation can help to reduce translation costs and improve return on investment.

**Cons**

- **Requires significant coordination**: Continuous Translation requires a high level of coordination between different teams, including developers, translators, and product owners. This can be challenging to manage, particularly for larger projects.
- **Potential for errors**: Continuous Translation requires real-time updates to translations, which can increase the risk of errors and miscommunication. This requires careful management and quality control.
- **Requires specialized tools**: Implementing Continuous Translation requires specialized tools and technologies, which can add to the overall cost of the project.
- **Not suitable for all projects**: Continuous Translation may not be suitable for all projects, particularly those with limited budgets or resources. Traditional translation workflows may be more appropriate for smaller projects or those with less frequent updates.

## Conclusion

Multilingual support is a very important function for web or mobile applications nowadays. Users will come from all over the world and always ask for support for their language. The two options above have different advantages and disadvantages, so you need to consider the exact scope of the product to have the best choice for your team. Both methods can meet the needs of constantly translating products to support new features or new products, but it will cost production as well as quality assurance.


Continuous Translation (CT) is a modern approach to translation management that involves synchronizing software development and translation workflows. This means that developers, translators, and product owners work together in a continuous cycle to ensure that all translations are up-to-date and aligned with the latest software developments.

Continuous Translation


Published on August 30, 2022, Chrome 105 included Container Queries, one of the most highly requested features in CSS.

## The Problem With Media Queries

When we want to create a responsive layout, we can use media queries to adjust styles based on the screen size of the device viewing our site. However, media queries have some limitations. For example, we cannot use them to style individual components based on their parent's width; we can only adjust the entire page. This is problematic because we cannot create responsive components; only responsive pages.

## What is Container Queries?

The CSS3 property "container queries" allows us to style elements based on the size of a container. It is similar to a Media Query, except it evaluates against the size of a container instead of the size of the viewport.

## How to use Container Queries?

To query a component based on its parent width, we need to use the `container-type` property with possible values: `size`, `inline-size`, `block-size`, `style`, `state`.

```css
.sidebar {
  container-type: inline-size;
}
```

Now we can start to query a container using `@container`. This will query the nearest containment context.

```css
@container (min-width: 300px) {
  .content {
    display: none;
  }
}
```

Additionally, Containers can be named with `container-name` property. This allows us to query a specific container.

```css
.sidebar {
  container-type: inline-size;
  container-name: my-sidebar;
}
```

or shorthand syntax

```css
.sidebar {
  container: my-sidebar / inline-size;
}
```

Then, to query a specific container, we can use `@container` with `container-name`.

```css
@container my-sidebar (min-width: 300px) {
  .content {
    display: none;
  }
}
```

## Browser Support

Currently, Container Queries is only available in [modern browsers](https://caniuse.com/?search=Container%20Queries):

- Chrome 105+
- Safari 15+
- Edge 105+

Universal support can be achieved by using [Polyfill](https://github.com/GoogleChromeLabs/container-query-polyfill).

## Reference

- https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries
- https://javascript.plainenglish.io/css-container-queries-3393fbeb6ea8
- https://ishadeed.com/article/container-queries-are-finally-here/
- https://developer.chrome.com/docs/devtools/css/container-queries/


Container Queries is a CSS feature that allows us to style elements based on the size of a container.

CSS Container Queries


**CSS-in-JS** is a styling technique where Javascript is used to style the component. These are multiple implementations of this concept in the form of libraries such as [emotion](https://emotion.sh), [styled-component](https://styled-components.com/), [JSS](https://cssinjs.org). They aim to tackle the limitations of CSS, such as lack of dynamic functionality, scoping, and portability.

## Benefits

### Scoping

With CSS-in-JS, writing new styles cannot affect anything else in other places on the site, so there’s no need to worry about writing a style that has bad or unintended consequences elsewhere due to a selector in the global scope.

### Avoid naming collisions

[Naming is hard](https://hilton.org.uk/blog/why-naming-things-is-hard). CSS-in-JS libraries automatically generate unique selectors for what’s being styled. We don't need to think about naming.

### Dynamic Functionality

As CSS-in-JS is essentially JavaScript code, you can apply complex logic to your style rules, such as loops, conditionals, variables, state-based styling, and more.

### Dead code elimination

CSS-in-JS helps with removing dead code. The only styles that are loaded are the styles for the components in use at any given time. There’s no shipping of any unused styles. When a component dies, so does its style.

### Developer ergonomics

It can be nice to have styles in the same file (or otherwise very close to) the component itself. In the same way, some developers feel very comfortable in JSX. Also, being able to style things without any scoping worry means developers may feel empowered about styling rather than intimidated by it.

## Disadvantages

### Runtime cost

When CSS is generated from JavaScript at runtime, in the browser, there is an inherent overhead. Some CSS-in-JS libraries try to overcome this overhead by extracting CSS files during the build time (like [linaria](https://linaria.dev)), but it comes with other [trade-offs](https://github.com/styled-components/styled-components/issues/2377)

### Learning curve

CSS-in-JS definitely has a learning curve, especially if you have used neither component-based frameworks nor web components before. Besides learning the new syntax, you also need to pick up a new way of thinking, which needs time and might slow down your development workflow for a while.

### Unreadable class names

Automatically generated selectors significantly worsen code readability. This can be a huge concern for you if you regularly use your browser’s developer tools for debugging. Currently, many CSS-in-JS libraries try to provide meaningful class names based on the declaration name or component name in development mode. Some of them even let you customize the class name generator function. In production mode, though, the class names are still hard to read and debug.

### Extra bundle size

Adding another library to a web page increases the page size, which can negatively impact page load time.

## Reference

- https://en.wikipedia.org/wiki/CSS-in-JS
- https://webdesign.tutsplus.com/articles/an-introduction-to-css-in-js-examples-pros-and-cons--cms-33574
- https://medium.com/dailyjs/what-is-actually-css-in-js-f2f529a2757
- https://github.com/styled-components/styled-components/issues/2377


CSS-in-JS is a styling technique where Javascript is used to style the component.

CSS in JS


The dark mode feature uses local storage to store a user's preference for future usage. The problem is that when the dark mode is enabled and the page is reloaded, there's a flicker of white background all over the page before it turns dark. This happens for a fraction of a second and doesn't look natural.

Following is the implementation we normally do when setting up this feature. This works by detecting if the dark mode is enabled from `localStorage` and adding a CSS class called `dark` to the `<html>` tag so all elements that are descendants of that element will turn to dark styling.

```html
<html>
  <head>
    ...
    <link href="./light.css" />
    <link href="./dark.css" />
  </head>
  <body>
    ...
    <script src="./main.js" />
  </body>
</html>
```

```js
// main.js
//...
if (window.localStorage.getItem('theme') === 'dark') {
  document.documentElement.classList.add('dark')
}
```

However, the dark styling is only applied if the `main.js` file is called so it will be expected to see the flash of light styling.

To fix this, put the scripts inside the `<head>` tag, even before the `<link>` or `<style>` tags:

```html
<html>
  <head>
    <script type="text/javascript">
      if (window.localStorage.getItem('theme') === 'dark') {
        document.documentElement.classList.add('dark')
      }
    </script>
    ...
    <link href="./light.css" />
    <link href="./dark.css" />
  </head>
  <body>
    ...
    <script src="./main.js" />
  </body>
</html>
```

By doing this, the page rendering will be blocked when the engine detects the `<script>` inside the `<head>` tag. While the renderer is idle, the JavaScript interpreter will assign the `dark` value to the CSS class list of `<html>` before the `dark.css` is loaded.

## Reference

- https://stackoverflow.com/questions/63033412/dark-mode-flickers-a-white-background-for-a-millisecond-on-reload


The dark mode feature uses local storage to store a user's preference for future usage. The problem is that when the dark mode is enabled and the page is reloaded, there's a flicker of a white background all over the page before it turns dark. This happens for a fraction of a second and doesn't look natural.

Dark mode flickers a white background for a fraction of a second


Focus trap is a web technique to improve accessibility by forcing keyboard focus inside a DOM element, to prevent the user navigating outside that element. This technique normally applies for an open modal dialog, when user interaction is trapped inside the dialog. This makes sense because allowing the focus to escape outside the modal would possibly create a state where the user doesn't know which element is in focus.

#### Reference

- https://css-tricks.com/a-css-approach-to-trap-focus-inside-of-an-element/


Focus trap is a web technique to improve accessibility by forcing keyboard focus inside a DOM element, to prevent the user navigating outside that element.

Focus trap


Inside a web browser, there exists a software component responsible for determining the content to show you based on the data it receives. This component is known as the browser engine.

The browser engine is a fundamental element present in all major web browsers, and various browser manufacturers give their engines distinct names. For instance, Firefox's browser engine is known as [Gecko](https/enwikipedia.org/wiki/gecko_software)>), while Chrome uses [Blink](https/enwikipedia.org/wiki/blink_browser_engine)>), a derivative of [WebKit](https://en.wikipedia.org/wiki/WebKit).

## From raw bytes of HTML to DOM

We are all familiar with the term **Document Object Model** or DOM, but it's always helpful to revisit how this crucial component is constructed: It starts with **bytes** of data that the browser reads from the HTML files, which are then transformed into readable **characters**.

But that bunch of text doesn't produce an actual website. Those characters are parsed into **tokens**, such as the start or end HTML tags, the content characters and so on. The browser then organizes those tokens into **nodes**, and assembles into the hierarchical structure known as the DOM.

> Check out this article for a more detailed understanding about this process: [How web browsers work - parsing the HTML (part 3, with illustrations)](https://dev.to/arikaturika/how-web-browsers-work-parsing-the-html-part-3-with-illustrations-45fi).

![](assets/from-markup-to-pixels---a-look-inside-the-dom,-cssom,-and-render-tree_html-parser.webp)

_Image Source: [How web browsers work - parsing the HTML (part 3, with illustrations)](https://dev.to/arikaturika/how-web-browsers-work-parsing-the-html-part-3-with-illustrations-45fi)_

## How about CSS?

As soon as the browser begins to parse the HTML, once encountering a `link` tag to a CSS file, it simultaneously makes a request to fetch that. As you may anticipate, the procedure mirrors the way browsers form the DOM (from bytes to the object model). This process forms a tree structure called the **CSS Object Model** (CSSOM).

> For further information, please check out this article: [How web browsers work - parsing the CSS (part 4, with illustrations)](https://dev.to/arikaturika/how-web-browsers-work-parsing-the-css-part-4-with-illustrations-4c).

![](assets/from-markup-to-pixels---a-look-inside-the-dom,-cssom,-and-render-tree_cssom.webp)

_Image Source: [How web browsers work - parsing the CSS (part 4, with illustrations)](https://dev.to/arikaturika/how-web-browsers-work-parsing-the-css-part-4-with-illustrations-4c)_

As you can see in the example above, the elements have both inherited styles from the parent (depicted in white), and their own styles that overwrite the inherited ones (depicted in black). And since we can have several CSS files linked to our HTML, that's when the [Specificity](https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity) comes in handy for the browser in determining which style to apply to a particular node.

## Combining the DOM with the CSSOM

The browser traverses every visible node starting from the root of the DOM tree. Certain nodes are ignored by default (such as script or meta tags), while for others, the browser seeks the relevant rules within the CSSOM and proceeds to paint them on the screen. The browser will also ignores the nodes that are hidden due to their CSS property (`display: none` for example).

Now the Render Tree holds the information of the **visibility** of each node and its **styles**, but what needs to be done next to calculate the exact position of those elements and paint them to the screen?

![](assets/from-markup-to-pixels---a-look-inside-the-dom,-cssom,-and-render-tree_render-tree.webp)

_Image Source: [How web browsers work - the render tree (part 7, with illustrations)](https://dev.to/arikaturika/how-web-browsers-work-the-render-tree-part-7-with-illustrations-24h3)_

## The Layout/Reflow stage

The **Layout**/**Reflow** is a process to find the **geometry** of elements. The main thread walks through the DOM and constructs a layout tree that stores details such as **x and y coordinates**, as well as **bounding box dimensions**.

![](assets/from-markup-to-pixels---a-look-inside-the-dom,-cssom,-and-render-tree_layout-tree.webp)

_Image Source: [Inside look at modern web browser (part 3)](https://developer.chrome.com/blog/inside-browser-part3/)_

This process happens every time we change something in the DOM that affects the layout, which may include:

- Adding or deleting elements from the DOM
- Resizing the browser window
- Changing the width, the position of an element or floating it

## The Painting stage

Despite having a DOM, style information, and a layout, these elements alone do not suffice for rendering a web page. Once the browser determines which nodes should be visible and calculates their positions within the viewport, the next step is to actually draw (render) them. Similar to the layout phase, the painting process doesn't occur just once but repeatedly whenever there are changes to the appearance of on-screen elements.

**Painting** means the browser needs to draw every visual part of an element to the screen, including text, colors, borders, shadows, and elements like buttons and images. To ensure repainting can be done even faster than the initial paint, the drawing to the screen is generally broken down into several **layers**. When this happens, compositing becomes necessary.

## Compositing

**Compositing** is a method used to divide different elements of a webpage into distinct layers, independently rendering each layer, and then combining them to form a complete page in a separate thread known as the compositor thread. When scrolling occurs, this approach becomes efficient because the layers are already rendered, requiring only the composition of a new frame. Similarly, animation can be achieved by repositioning these layers and composing a new frame, enabling smooth and responsive animations.

To determine which elements should be placed within specific layers, the main thread goes through the layout tree to generate the **Layer tree**.

> Learn more about the **Layers panel** of DevTools [here](https://blog.logrocket.com/eliminate-content-repaints-with-the-new-layers-panel-in-chrome-e2c306d4d752/).

![](assets/from-markup-to-pixels---a-look-inside-the-dom,-cssom,-and-render-tree_layer-tree.webp)

_Image Source: [Inside look at modern web browser (part 3)](https://developer.chrome.com/blog/inside-browser-part3/)_

Once the Layer tree is established and the orders of rendering are determined, the main thread transfers that information to the compositor thread. The compositor thread then begins the process of rendering each layer. Some layers, such as those having the entire length of a webpage, can be quite extensive. To handle this, the compositor thread breaks them down into smaller sections known as **tiles** and dispatches each tile to **raster threads**. These raster threads are responsible for rendering each tile and storing the results in the memory of the GPU.

![](assets/from-markup-to-pixels---a-look-inside-the-dom,-cssom,-and-render-tree_compositing.webp)

_Image Source: [Inside look at modern web browser (part 3)](https://developer.chrome.com/blog/inside-browser-part3/)_

## Reference

- https://developer.chrome.com/blog/inside-browser-part3/
- https://blog.logrocket.com/how-browser-rendering-works-behind-scenes/
- https://dev.to/arikaturika/series/17842
- https://twitter.com/alexxubyte/status/1534201516063461376


A deep dive into the rendering process of a web page, exploring the Document Object Model (DOM), CSS Object Model (CSSOM), and the Render Tree.

From Markup to Pixels - A look inside the DOM, CSSOM, and Render Tree


Frontend engineers use Hexadecimal color codes to represent colors, but they have some limitations:

- Hexadecimal color codes are difficult to write and adjust, requiring the use of a third-party application to get right.
- Hexadecimal color codes can be difficult to remember and use, especially for designers.

HSL is the answer to resolving all of the painful points.

## What is HSL?

**HSL** stands for **hue**, **saturation**, and **lightness**. It’s based on the RGB color wheel. Each color has an angle and a percentage value for the saturation and lightness values.

- **Hue**: Think of a color wheel. Around 0<sup>o</sup> and 360<sup>o</sup> are reds. 120<sup>o</sup> is where greens are and 240<sup>o</sup> are blues. Use anything in between 0-360. Values above and below will be modulus 360.

  ![](assets/hsl-color_hls-color.webp)

- **Saturation**: 0% is completely desaturated (grayscale). 100% is fully saturated (full color).

  ![](assets/hsl-color_hls-hue.webp)

- **Lightness**: 0% is completely dark (black). 100% is completely light (white). 50% is average lightness.

  ![](assets/hsl-color_hls-lightest.webp)

## Using HSL

### Darker/lighter colors

Imagine you're creating a button component and you want it to appear darker on hovering to increase its contrast. You can do this easily with the help of HSL.

![](assets/hsl-color_using-hls.webp)

```css
:root {
  /* brand color: #E13F5E */
  --primary-h: 349;
  --primary-s: 73%;
  --primary-l: 56%;
}

.button {
  background-color: hsl(var(--primary-h), var(--primary-s), var(--primary-l));
}

.button:hover {
  --primary-l: 40%;
}
```

### Color palette

By altering the `lightness`, we can create a set of shades for a color that can be used throughout the UI where possible.

![](assets/hsl-color_hls-color-pallete.webp)

## HSL transparency (HSLa)

It works exactly the same as with RGB, just add `alpha` channel with a value from 0 to 1. 0 is fully transparent. 1 is fully opaque. 0.5 is 50% transparent.

```css
hsla(349, 73%, 56%, 0.5)
```

## References

- https://css-tricks.com/hsl-hsla-is-great-for-programmatic-color-control/
- https://www.smashingmagazine.com/2021/07/hsl-colors-css/
- https://tsh.io/blog/why-should-you-use-hsl-color-representation-in-css/


HSL is the answer to resolving all of the painful points of Hexadecimal color codes.

HSL Color

`inert` is a boolean HTML property that makes the browser ignore the user input events for an element, including focus events and events from assistive technologies.

When an element has `inert` attribute, it will be removed from the tab order (interactivity), and from the accessibility tree (discoverability). While discoverability, previously, could be suppressed by `aria-hidden=true`, interactivity is more difficult as developers normally have to combine with `tabindex="-1"` to get it disabled.

The born of `inert` helps to eliminate the need for [ focus trap]() which is being combined with `aria-hidden` to improve the accessibility of a web page containing an open dialog (see the attachment), though we still have to manually move the focus to the dialog and return focus the element that triggered it after the dialog is closed.

![](assets/html-inert_pasted-image-20220612104313.webp)

```html

<div id="main" aria-hidden="true">...</div>
<div class="dialog">...</div>
<script>
  // ...initiate focus trap for .dialog
</script>


<div id="main" inert>...</div>
<div class="dialog">...</div>
```

#### References

- https://web.dev/articles/inert
- https://patrickhlauke.github.io/aria/demos/modal/index-aria-inert.html

`inert` is a boolean HTML property that makes the browser ignore the user input events for an element, including focus events and events from assistive technologies.

HTML inert


## Overview & When to use IndexedDB

**IndexedDB** is a low-level API for client-side storage like [_localStorage_](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) and [_cookies_](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies). But this built-in **non-relational database** is much more powerful than those 2 counterparts.

If you want to build a traditional client-server app with a moderate amount of data needed to store in the client side (browser), simply use localStorage or cookies for their ease of implementation and usage. IndexedDB is intended for **offline** apps, when you want to store and retrieve some data even without connection to the Internet. An example might be a to-do list or saved games that are played locally. In this case, the user data is in local side, and the web site is just the vehicle for delivering it.

Beside that, IndexedDB has some important characteristics and much more powerful supplementations:

- Stores almost any kind of key-value pairs, including **complex objects**
- It is mostly **asynchronous**
- Can store **significant volumes** of structured data, much bigger than localStorage
- Supports **transactions** for reliability
- Does not use Structured Query Language (SQL)

Like most web storage solutions, IndexedDB follows a [same-origin policy](https://www.w3.org/Security/wiki/Same_Origin_Policy) i.e. while you can access stored data within a domain, you cannot access data across different domains.

## Important terminologies

### Database

Database in IndexedDB contains the object stores, which in turn contain the data you would like to persist. You can create multiple databases with the following must-have information:

- Name: identifies the database and must stay constant
- Current version: with default value of 1

```javascript
const openRequest = indexedDB.open('shelf' /* name */, 1 /* version */)
...
openRequest.onsuccess = () => {
	const db = openRequest.result
	...
}
```

> [Read more](https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase) about methods, attributes and how to use **IDBDatabase**.

### Object store

Object store is an individual bucket to store data. It is the **core concept** of IndexedDB. You can think of object stores as being similar to tables in traditional relational databases. A database may have multiple stores and each of them must have a name that is **unique** within its database.

![](assets/cYgLD5U.png)

```javascript
db.createObjectStore('books' /* name */, { keyPath: 'id' })
```

> [Read more](https://developer.mozilla.org/en-US/docs/Web/API/IDBObjectStore) about **IDBObjectStore**, an interface of IndexDB API that represents object stores.

### Transaction

An atomic set of _data-access_ and _data-modification_ operations on a particular database, they should either **all succeed** or **all fail**. It is how you interact with the data in a database. **Any reading or changing of data in the database must happen in a transaction**.

A database connection can have several active transactions associated with it at a time, so long as the writing transactions do not have overlapping scopes. The scope of transactions gives us information of during the transaction, which object stores are involved (and are expected to be modified) and which of them remain.

```javascript
const trans = db.transaction("books" /* store */, "readwrite" /* type */)

// start operating on this store
const objStore = trans.objectStore("books")

const book = {
	id: 'Remote - Office not required',
	price: 10,
}

const request = objStore.add(book /* value */) // operations must happen in a transaction

request.onsuccess = () => {
	...
}
```

> [Read more](https://developer.mozilla.org/en-US/docs/Web/API/IDBTransaction) about **IDBTransaction**, an interface of the IndexedDB API that provides a static, asynchronous transaction on a database.

### Index

An **index** is a specialized object store for looking up records in another object store (often called the *referenced object store*). The **index** is a key-value storage where all its values are the keys of the referenced object store. Hence all its records are automatically populated when a new record is inserted, updated or deleted.

> [Read more](https://developer.mozilla.org/en-US/docs/Web/API/IDBIndex) about **IDBIndex** interface of the IndexedDB API.

**Searching by a field using an index**:

```javascript
...
openRequest.onupgradeneeded = () => {
	const books = db.createObjectStore('books', {keyPath: 'id'})
	const index = books.createIndex('price_idx', 'price')
}
```

Search the `books` object store by `price` key: ![](assets/TjHErHh.png)

### Cursor

With a huge object store, bigger than the available memory, `getAll` might fail to get all records as an array. Cursors provide the means to work around that.

**A cursor is a special object that traverses the object storage using a given query, and returns one key/value at a time, thus saving memory**.

```javascript
const request = store.openCursor('id' /* query */, ['next' /* or 'prev', 'nextunique'... */])

// to get keys only, you can use 'openKeyCursor' instead of 'openCursor'
```

> [Read more](https://developer.mozilla.org/en-US/docs/Web/API/IDBCursor) about **IDBCursor**, an interface of IndexedDB API that represents a cursor.

## Limitation

IndexedDB is designed to cover most cases that need client-side storage. However, it is not designed for a few cases like the following:

- Not all languages sort strings in the same way, so internationalized sorting is not supported
- The API is not designed for synchronizing with a server-side database
- It does not have an equivalent of the `LIKE` operator in SQL for full text searching

Moreover, errors that are **out of developers' control** can happen for a variety of reasons. For example, some browsers like **Firefox** or **Edge** currently don't allow writing to IndexedDB when in private browsing mode. There's also the possibility that a user is on a device that's almost out of disk space, and the browser might not allow storing anything else at all.

Using IndexedDB is also likely to require **a lot more coding** than localStorage or cookies. But if the values you’re storing are complex JavaScript objects that would be difficult to serialize, or if you need a transactional model, then it may be worthwhile.

> Detailed information about Limitations of IndexedDB from MDN site [[here](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Terminology#limitations)]

## Reference

- https://javascript.info/indexeddb
- https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB
- https://www.javascripttutorial.net/web-apis/javascript-indexeddb/
- https://web.dev/indexeddb/


IndexedDB is a low-level API for client-side storage like localStorage and cookies. But this built-in non-relational database is much more powerful than those 2 counterparts.

Intro to IndexedDB

**Modules** have always been a part of JavaScript development and providing mechanisms for splitting JavaScript programs up into separate modules that can be imported when needed was the absolutely necessity for JavaScript developers.

> "Modules are like building blocks that we can create software by combining."

### So what is a module?

A module is just simply a file that exports its own code.

### Why do we need it?

- Modules gives our code **structure** and **boundaries**. One's code will be hard to organize and maintain if they don't use modules and no one wants all the codes mingling with each others.
- Modules also allow developers share code to the world through a package manager like NPM.

## History of JavaScript's modules

In order to understand about the development of JavaScipt's modules, we need to walk through 4 stages: Vanilla, IIFEs, CommonJS and ESM.

### Vanilla (1990s - early 2000s)

When JavaScript was first invented by Brendan Eich in 1995, it was known to have been created in 10 days and the creator himself doesn't think that his programing language would be as popular as today.

> “No one thought JavaScript would be used at the wide scale it is. Not just reaching lots of people on the Web, but large application like Gmail… To write large code, you don’t just want this little snippet language that I made for beginners…“ Bredan Eich (Creator of JavaScript)

So modules aren't a thing back then, developers would mostly used inline-scripting and script-tags and no one would think of scalability, maintaining a large code base would be a nightmare because there is no structures and organizations.

#### YAHOO manifesto

Around 2006, a global manifesto was raised by a team of UI developers from YAHOO which was **"Global Variable are dangerous"**. The point they trying to make is that using global variable is a risky practice and all the people back then are engaging in. Global variables can spark conflict between naming if there are many people involving in developing the same program and since everyone can access it, it is not very secure.

#### YAHOO Solution?

Create a huge Global namespace object and parse all the variables in that object.

> **Example**: YAHOO.value.getValue

### IIFEs (early to late 2000s)

IFFEs or Immediately invoked function expression was used with closures to keep the private data hidden, basically the ideal is that you only need to care of what the function returns and not what happen inside it.

#### Example

```js
var Dialogue = function () {
  //private variables
  var dialogue
  //exposed functions
  return {
    hello: function () {
      dialog = 'Hello Dwarves!'
      console.log(dialogue)
    },
    goodbye: function () {
      dialog = 'Goodbye Dwarves!'
      console.log(dialogue)
    },
  }
}
```

At this stage we have solve the Global namespace pollution problem but we haven't got to the point that we can swapping modules with one another and copy/paste function happens all the time.

### CommonJS (early to mid 2010)

Around 2009, people are hype about the potential of JavaScript, you can now run JavaScript on the server-side. And come with that a proposal was made for JavaScript to have a standard way to include other modules. Node created a module implementations name CommonJS.

#### Implementation of CommonJS:

- **Import**: using `require()` method.
- **Export**: **module** object using `module.exports`.

This was design for server development.

#### Synchronus modules loading

- **MODULE.\_LOAD**: Node caches it's modules (Node check for cache files, if it not there it will create an instance and caches it).
- **MODULE.\_COMPILE**: Create a `require` function that speciffic for each modules and generate a wrapper function to scope variables the run the wrapper function.

#### Node module wrapper function

```js
;(function (exports, require, module, __filename, __dirname) {
  // Module code actually lives in here
})
```

#### Example

```js
//dialogue.js
var getDialog (function (){
    console.log("Hello Dwarves!");
})
module.exports = getDialogue;
```

```js
//main.js
const sayHello = require('./dialogue.js')
```

At this time, CommonJs is a real noviation, organizing files and maintaining code has become much easier.

### ESM (2010s - present)

ESM or ES modules was supported by all major browsers and was the first **built-in module** in JavaScript and introduce top-level `await` functionality for module imports.

#### Top-level await

A feature accessible within modules is top level await. This implies that the await keyword is functional. It enables modules to function as sizable asynchronous functions, allowing code to be assessed before usage in parent modules without preventing the loading of siblings.

#### ESM Asynchronus ?

The loading and parsing for ESM modules is indeed asynchronous, but the execution of the code in them is synchronous and serialized based on the order they are imported.

#### Implementation ESM:

- **Import**: using `import` method.
- **Export**: using `export` method.

#### Example

```js
//Export syntax

//dialog.js
export default const dialog = "Hello Dwarves!";

//utils.js
export const getHours = () => //do something;
export const getMinutes = () => //do something;
```

```js
//Import syntax

import dialog from './dialog.js'

import * as utility from './utils.js'
import { getHours, getMinutes } from './utils.js'
```

#### ESM in the browsers

ESM has a specfic module type in the browser which they are processed differently and create a fallback for older browsers using bundle.

```html

<script type="module" src="main.js"></script>

<script nomodule src="bundle.js"></script>
```

### CommonJS vs ESM

- Right now ESM was supported on all browsers and the latest version of Node except version below version 12.
- ESM waits to execute any code in a module until all of it's imports have been loaded and parsed, then does the binding/side-effects stuff in the relative order that they happen.
- ESM imports are asynchronous (which also allows for top-level `await`).
- CJS executes imports as it finds them, blocking until they finish.
- CJS works in Node but does **not** work in browsers.

### Conclusion

Although CommonJS can still be used for server development since synchronous wasn't an issue and it was built by Node, using ESM is still the better way to keep the syntax consistent if you were to develop client-side and server-side with JavaScript.

#### Reference

- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
- https://dev.to/adamcoster/commonjs-and-esm-importexport-compatibility-by-simple-example-50pl
- https://www.w3schools.com/js/js_modules.asp
- https://nodejs.org/api/modules.html
- https://www.infoworld.com/article/2653798/javascript-creator-ponders-past--future.html

Modules have always been a part of JavaScript development and providing mechanisms for splitting JavaScript programs up into separate modules that can be imported when needed was the absolutely necessity for JavaScript developers.

JavaScript modules

## What is Micro-frontend ?

> An architectural style where independently deliverable frontend applications are composed into a greater whole

## Benefits

- Smaller, more cohesive, and maintainable codebases
- More scalable organizations with decoupled, autonomous teams
- The ability to upgrade, update, or even rewrite parts of the frontend in a more incremental fashion than was previously possible
- Easier maintenance: Keeping frontend repositories small and specialized allows them to be more easily understood, and this simplifies long-term maintenance and testing.

## Micro frontends in actions

### Build-time integration

- Publish each micro frontend as a package and have the container application include them all as library dependencies.

```javascript
{

  "name": "@shop/container",

  "version": "1.0.0",

  "description": “Ecommerce website",

  "dependencies": {

    "@shop/products": "^1.0.0",

    "@shop/order": "^1.0.0",

    "@shop/user-profile": "^1.0.0"

  }

}
```

### Cons

- Have to re-compile and release every single micro frontend in order to release a change to any individual part of the product.

## Run-time integration via iframes

- Use `iframe` to connect other micro frontends

````javascript
	<html>

	  <head>

	    <title>Shop</title>

	  </head>

	  <body>

	    <h1>Welcome to Shop</h1>

	    <iframe id="app-container"></iframe>

	    <script type="text/javascript"> const microFrontendsByRoute = {

	        '/': 'https://products.shop.com/index.html',

	        '/order': 'https://order.shop.com/index.html',

	        '/user-profile': 'https://profile.shop.com/index.html',

	      };

	      const iframe = document.getElementById('app-container');

	      iframe.src = microFrontendsByRoute[window.location.pathname]; </script>

	  </body>

	</html>
	````  
  

### Cons

- Difficult to make the page responsive
- Difficult to integrate between different parts of an application, make routing, history, and deep-linking more complicated

## Run-time integration via JavaScript

-  Each micro frontend is included on the page using a `<script>` tag, and upon load exposes a global function as its entry-point. The container application then determines which micro frontend should be mounted, and calls the relevant function to tell a micro frontend when and where to render itself.

```javascript
<html>

  <head>

    <title>Shop</title>

  </head>

  <body>

    <h1>Welcome to Shop</h1>

    

    

    <script src="https://products.shop.com/bundle.js"></script>

    <script src="https://order.shop.com/bundle.js"></script>

    <script src="https://profile.shop.com/bundle.js"></script>

    <div id="app"></div>

    <script type="text/javascript"> // These global functions are attached to window by the above scripts

      const microFrontendsByRoute = {

        '/': window.renderProducts,

        '/order': window.renderOrder,

        '/user-profile': window.renderUserProfile,

      };

      const renderFunction = microFrontendsByRoute[window.location.pathname];

      // Having determined the entry-point function, we now call it,

      // giving it the ID of the element where it should render itself

      renderFunction('app'); </script>

  </body>

</html>
````

## Run-time integration via [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components)

- Define each micro frontend as an HTML custom element for the container to instantiate.

```javascript
<html>

  <head>

    <title>Shop</title>

  </head>

  <body>

    <h1>Welcome to Shop</h1>

    

    

    <script src="https://products.shop.com/bundle.js"></script>

    <script src="https://order.shop.com/bundle.js"></script>

    <script src="https://profile.shop.com/bundle.js"></script>

    <div id="app"></div>

    <script type="text/javascript">

  // These element types are defined by the above scripts

      const webComponentsByRoute = {

        '/': 'micro-frontend-products',

        '/order': 'micro-frontend-order',

        '/user-profile': 'micro-frontend-user-profile',

      };

      const webComponentType = webComponentsByRoute[window.location.pathname];

      // Having determined the right web component custom element type,

      // we now create an instance of it and attach it to the document

      const root = document.getElementById('app');

      const webComponent = document.createElement(webComponentType);

      root.appendChild(webComponent);

</script>

  </body>

</html>
```

### Cons

- Don't support server-side rendering
- No 100% [browser support](https://caniuse.com/#search=custom%20elements)

## Cross-application communication

1. [Custom event](https://developer.mozilla.org/en-US/docs/Web/Events/Creating_and_triggering_events)
1. Cross-application communication via routing

## Serverside Rendering / Universal Rendering

- Server-side rendering is always a tricky problem.
- Use [Server Side Includes](https://en.wikipedia.org/wiki/Server_Side_Includes) to plug in page-specific content from fragment HTML files

# Conclusion

- Duplication of dependencies => increase payload size
- App performance
- Learning curve
- Only suitable for medium, large projects

## References

- [Micro frontends](https://micro-frontends.org/)
- [Micro Frontends from Martinfowler](https://martinfowler.com/articles/micro-frontends.html)
- [Micro frontends—a microservice approach to front-end web development](https://www.tomsoderlund.com/programming/micro-frontends-a-microservice-approach-to-front-end-web-development)
- [Awesome Micro Frontends](https://github.com/ChristianUlbrich/awesome-microfrontends)

Micro Frontends is an architectural style where independently deliverable frontend applications are composed into a greater whole.

Micro Frontends Microservices For Frontend Development


We all know that for web applications, perceived performance is highly importance for our users. For data intensive SPAs with CPU-intensive tasks, the single-threaded nature of Javascript starts to hinder the application's perceived performance when you cannot fit those CPU-intensive tasks into a 16.67 ms/frame window (translates to 60fps). That doesn't even account for code execution time of frameworks (React, Vue...etc), which then leaves you with approximately only a 10 ms/frame window or less to complete all your tasks on the main thread to make user interaction feel smooth and snappy.

Fortunately for us, JavaScript provides a couple of tools to solve these problems with some new features: Threading (through Web Worker) and Coroutines (through generators).

## Threading with Web Worker

If you don't know what a Web Worker is, check out [parallelism-in-javascript]() for a quick introduction.

With Web Worker we can offload a bunch of processing to another thread and it will not impact the performance of the main thread. Sounds perfect, but it comes with a cost: `serialization`.

Because of the heavy sandboxing of JS environment, using web workers only works well if we have small to medium inputs and outputs. Because all of the data transported between the main thread and worker thread is going to be serialized, which blocks the main thread while that happens (unless you are using binary formats like Shared Array Buffer or Typed Arrays, which comes with other caveats that is outside of the scope of this note).

If `serialization` is not a problem for your app then Web Worker will probably do a great job to enhance your app's performance and UX.

For real time apps that require continuously recalculation of data when new data comes, you can implement a game-loop-like updater function inside the web worker code to periodically emit data to main thread once per an interval time limit. That pattern works well because it allows you to control how often main thread should receive new data and UI should rerender.

## Coroutines with generators

When you have a serialization problem with Web Worker, another tool you can reach for is coroutines.

You are most likely already aware of coroutines in one form or another. A coroutine is basically a thread of programming logic that is working its way to completion at the same time as other things are doing the same. Or to put it simply: a coroutine is an execution that can be suspended and resumed.

Generators was introduced in ES6, adding the capability of suspending and resuming code execution. Here's a number generator that generates from 1 to 99:

```javascript
function* numberGen(maxValue = 100) {
  let currentValue = 0
  while (currentValue < maxValue) {
    currentValue++
    yield currentValue
  }
}

// Generate and get numbers
const sequence = numberGen()
console.log(sequence.next()) // Prints : { value: 1, done: false }
console.log(sequence.next()) // Prints : { value: 2, done: false }
// When it reaches the 99th call
console.log(sequence.next()) // Prints : { value: 99, done: true }
```

So, ES6 generator allows us to run code and yield values whenever we like but it's still a rough tool, for our problem we need to combine generator with browser's `requestIdleCallback()` to request main thread to do an amount of work when it's idle, then see if there is enough time left to do more work, if not yield control back to main thread then queue another run the next time main thread is idle. Luckily somebody smart already thought of that, you can checkout [js-coroutines](https/github.com/miketalbot/js-coroutines) for a complete implementation and evaluate if it solves your app's problem.

## References

- https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Generator
- https://javascript.info/generators
- https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback


We all know that for web applications, perceived performance is highly importance for our users. For data intensive SPAs with CPU-intensive tasks, the single-threaded nature of Javascript starts to hinder the application's perceived performance when you cannot fit those CPU-intensive tasks into a 16.67 ms/frame window (translates to 60fps). That doesn't even account for code execution time of frameworks (React, Vue...etc), which then leaves you with approximately only a 10 ms/frame window or less to complete all your tasks on the main thread to make user interaction feel smooth and snappy.

Mitigate blocking the main thread


Mixpanel is a powerful analytics platform that assists companies in monitoring and analyzing user behavior on their websites and mobile applications. With Mixpanel, you can analyze user activity, evaluate the performance of your products, and improve user experience through data-driven decisions. ![](assets/mixpanel_dashboard.webp)

## Key features

Some key features of Mixpanel include:

1. **Real-time analytics**: Mixpanel offers data on user activity in real-time, enabling organizations to instantly see patterns and take wise decisions.
2. **Custom Event Tracking**: Businesses can better understand how customers engage with their products by tracking custom events like button clicks, form submissions, and in-app payments using Mixpanel.
3. **Funnels and Retention**: Mixpanel offers robust tools for funnel analysis to assist companies better understand how customers interact with their products and how to increase user retention.
4. **People Analytics**: Mixpanel allows businesses to segment and understand their user base by tracking user behavior, demographics, and other key metrics.
5. **Mobile Analytics**: Mixpanel offers robust mobile **analytics** **that** enable businesses to track user behavior on both iOS and Android platforms.
6. **Segmentation**: Mixpanel enables businesses to create custom segments of users, based on specific behaviors or attributes, to understand how different groups of users engage with their products.
7. **Integration**: Mixpanel integrates with a wide range of tools, including popular CRM and marketing automation platforms, making it easy to use alongside other technologies.

## Integration with React

1. Create a Mixpanel account and get a Mixpanel project token. To use Mixpanel, you need to sign up for an account and create a project. When you create a project, you receive a unique token that is used to identify your project.
2. Install the Mixpanel library: You can install the Mixpanel library by running the following command in your terminal:

```zsh
yarn add mixpanel-browser
```

3. Import the Mixpanel library into your React component: In your React component, import the Mixpanel library as follows:

```ts
import mixpanel from 'mixpanel-browser'
```

4. Initialize Mixpanel: In your component's constructor or useEffect hook, initialize Mixpanel with your project token:

```ts
//index.tsx
mixpanel.init('YOUR_MIXPANEL_PROJECT_TOKEN')
```

5. Track events: To track events in your React application, you can use the Mixpanel `track` method. For example:

```ts
mixpanel.track('Button clicked')
```

6. Use Mixpanel's identify method to track unique users: The Mixpanel `identify` method allows you to track unique users in your application. You can call this method with a unique identifier for the user, such as an email address or user ID:

```ts
mixpanel.identify('user_id')
```

7. Additionally you could use people.set.method to create a profile for the users

```ts
mixpanel.people.set({
  $name: profile?.fullName,
  $email: profile?.email,
  $company_name: profile?.company?.name,
  $company_id: profile?.company?.id,
  $user_id: profile?.id,
})
```

As you can see in the images bellow all users interact with the app will be listed. ![](assets/mixpanel_user_profiles.webp)

You can observe all the events created by the users. ![](assets/mixpanel_user_activites.webp)

## References

- <https://developer.mixpanel.com/docs>
- <https://www.npmjs.com/package/mixpanel-browser>


Mixpanel is a powerful analytics platform that assists companies in monitoring and analyzing user behavior on their websites and mobile applications.

Mixpanel


If you've been on Twitter lately, you might've seen the term "Partial Hydration" as well as MPA going along and hyped by web advocates, wondering what about them?

## MPA

"Multi-page-app", opposes the more commonly known "Single-page-app". The idea is now that we're back to the web era of 10 years ago of truly "static" websites. Each link navigation triggers a full-page reload to the new HTML page with no SPA-style navigation (a navigation style that doesn't trigger a full page reload, but replace the current page with the new page, similar to an app-like experience).

### Why?

The web community has spent huge efforts to make SPA faster and more SEO friendly than how it was originally introduced: SSR and streaming mechanisms allow for making meaningful content visible as fast as possible. But we've come to a realization: nothing beats an MPA in terms of speed of page loading and SEO.

SSR did a wonderful job bringing faster page loads to SPA, but the problem still exists: we've been sending really huge, mostly unused, JavaScript payloads to users.

## Why not SPA?

With the current advanced web technologies, mainly web libraries/frameworks like React, Preact, Vue, Svelte, etc - most companies opt to build their web products completely with those libraries. Since these frameworks are excellent in building SPAs, we've been seeing a lot more SaaS products as SPA now more than ever.

SPA isn't technically a bad thing, it makes navigation feels more "native" and smooth - with features like preloading and background fetching for new pages that the user might likely visit. In fact, it's so great that a lot of recognizable web software are built as an SPA: Facebook, Twitter, Notion, etc...

However, SPA does come with a cost that is not so obvious at first glance: **a large initial bundle size**.

### The SPA story

The way most SPAs works is that (almost) everything in our web UI is composed with JavaScript (with or without frameworks). JavaScript is run this way to create HTML at run-time, with the most basic form of this pattern being `document.createElement("div")`. Now, imagine if every text, button, section, popup, and relevant UI components of our website were built using this pattern. Why is it not-so-good to use SPA?

The answer: [It's the cost of JavaScript](https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/). Unlike raw HTML, using JavaScript to create HTML implies unseen overhead. This amounts to the cost of downloading, parsing, and executing JavaScript. Even before we can see anything on the screen, the browser has to run all of this to completion in order to show us something meaningful. Depending on the context, this effect can cause long delays between when a user visits a site and when a meaningful content is visible to that user. Nowadays, web performance tools measures and categorizes this delay as one of the most [important metric for frontends: (LCP)](https://web.dev/lcp/).

### SSR & hydration

Then we have SSR "Server Side Rendering" - used to improve LCP and provide better SEO capability for SPAs. In React, this feature is handled with `ReactDOMServer.renderToString`. The idea is simple: render the whole React tree to raw HTML on server and return it to browser. The user will then be able to see content immediately after HTML is downloaded.

Now we have the best of both worlds, with SPA & SSR - an app-like experience with fast content delivery time!

Not so fast. We’re still missing one final piece - the raw HTML returned by our server won't be fully interactive (e.g: the "counter" state won't change when we click buttons). In order to make our page interactive, we have to "hydrate" it.

**Hydration** is the process of turning the raw HTML we returned earlier to a fully interactive React tree of components. For React, this can be done using the `ReactDOM.hydrate` method. So full process would be:

1. `renderToString` & send the (html) string to clients on the server
2. Loads the corresponding React component and hydrate it on the client:
   - `import Page from "pages/home"`
   - `hydrate(Page, document.getElementById("app"))`

"Sooo that’s still all good!". Yes, except for one thing: do we really need ALL our components to be interactive? Probably not, especially for cases when we're building a basic landing/marketing site using React, where most of our content is static except for subscribe forms, sliders, etc. Hydrating the whole page in this scenario is called _hydration waste_: only some components are actual interactive components, yet we hydrate everything from the top down, which in turn makes our [time-to-interactive (TTI)](https://web.dev/interactive/) longer.

## Partial hydration

This concept proposes hydrating only parts of the entire site - parts where we need interactivity, this in turn help us to ship less JavaScript to the client by only hydrating demanding components. Thus, we improving page load time & time-to-interactive. As of now, only some static site frameworks support this out of the box: [Astro](https://docs.astro.build/core-concepts/component-hydration) & [Marko](https://markojs.com/).

To implement this from scratch in a React project, although doable, requires [quite a lot of implementation](https://medium.com/@luke_schmuke/how-we-achieved-the-best-web-performance-with-partial-hydration-20fab9c808d5), and it may be hard to debug issues in the process.

## MPA, SPA or Partial Hydration?

Same old answer: it depends. If you’re building an analytics dashboard, sports betting portal, or just a better version of PowerPoint, stick with SPA (and SSR, if needed). These types of websites have lots of interactive UI to make Partial Hydration just not worth it.

Otherwise, if it's your landing site, similar to [netlify.com](http://netlify.com/) or [dwarves.foundation](https://dwarves.foundation/), which essentially just has only 1-2 pieces of UI that require JavaScript to run, and you’re building it with React: try to apply Partial Hydration where possible. While `react-static` or `gatsby` does not (yet) support partial hydration, you can try out [astro.build](https://astro.build/). Here, partial hydration is a first class citizen, and it comes with a decent static site generator with good React support.

For MPA, if you prefer to keep building your site with React, you can still make it with an MPA. Just do SSR on the server and AVOID hydrating the whole page on the client. Obviously interactive components won't be interactive, but at least it's a good start.


MPA, SPA and Partial Hydration are three different approaches to building web applications.

MPA, SPA and Partial Hydration


Most of applications nowadays are created with the aim to be on the web. JavaScript has become a mainstream programming language to support the direction. However, being designed as a single-threaded language doesn't give JavaScript the power to support heavyweight applications as when we talk about image/video processing, online games or even data mining. This naturally creates a demand to support Parallelism in the language.

### Web Worker

Web Worker is one of the initial attempts that successfully brings the concept of parallelism to browsers. A web worker creates a JavaScript thread performing tasks, without interfering with the user interface.

Web workers run in a different context from the main thread. Because of that, `document` and `window` objects of the main thread are not accessible in web workers. However, it is possible to use XMLHttpRequest, WebSocket or data storage mechanism.

There are two kinds of workers: shared and dedicated. A dedicated worker can be only accessed from the script that initiated it while the state of shared workers can be accessed from multiple scripts.

Communication between the worker thread and the main thread is via a system of messages where both sides send data using the `postMessage()` method, and respond to messages via the `onmessage` even handle. The data is serializable. It means data is copied rather than shared. So, there is a performance bottleneck if the amount of transferred data is huge.

```javascript
# main.js
const myWorker = new Worker('./worker.js');

myWorker.postMessage(1);

myWorker.onmessage = function(event){
	console.log(`Receieved ${event.data} from web worker`)
}
```

```javascript
# worker.js
onmessage = function(event){
	console.log(`${event.data} received from main script`);

	if(event.data === 1){
		postMessage(2);
	}
}
```

### WebCL and other OpenCL based frameworks

Another approach to apply the concurrency model for web applications is [WebCL](https://www.khronos.org/webcl). It is a JavaScript binding to the OpenCL standard that enables web applications to harness GPU and multi-core CPU parallel processing from within a web browser, thus, enabling the possibility to deploy computationally intensive applications. Currently, no browsers natively support WebCL but non-native add-on can be used to embed WebCL in web browsers.

[RiverTrail](https://github.com/IntelLabs/RiverTrail/) is another framework that relies on OpenCL to provide support for data parallel programming in JavaScript. It works by extending JavaScript with new data-parallel constructs that are translated at runtime into a low-level hardware abstract layer.

However, most of OpenCL based frameworks developed during the period are no longer being in active development as no browser vendors have a concrete plan to implement it in their environment at the moment. It seems the attention to boost the performance of the web is bet on different approaches such as [WebAssembly](https://developer.mozilla.org/en-US/docs/WebAssembly) or [WebGPU](https://www.w3.org/TR/webgpu/). So, at the time of writing, Web Worker is the only approach to bring parallelism in web applications in production.

#### References

- https://www.khronos.org/registry/webcl/specs/latest/1.0/#3.1
- https://en.wikipedia.org/wiki/WebCL
- https://intellabs.github.io/RiverTrail/


Parallelism in JavaScript is a technique to improve the performance of web applications by executing multiple tasks simultaneously.

Parallelism in JavaScript


The _**"parse, don't validate"**_ approach is all about processing incoming data and failing in a controlled manner if parsing fails. It is all about leveraging trustworthy, secure, and typed data structures within your code and ensuring that all incoming data is handled at the very edges of your systems. Instead of passing receiving data deep into your code, parse it immediately and fail quickly if necessary.

Parsing is better than validation because it requires you to explicitly handle every incoming data. It provides a type-safe method of working and makes it difficult to spread harmful material throughout your apps and data storage. However, it is true that parsing frequently incorporates data validation.

## Overview

### What is parsing?

- **Parsing** is the process of analyzing a string or symbol either in natural language, computer languages or data structures, conforming to the rules of a formal grammar.
- The **"_process of analyzing_"** and **"_conforming to the rules of a_ [_thingy_]"** are crucial here. _Thingy_ is our schema and type, which in this instance may be thought of as forming our _formal grammar_ (don't worry if you don't know what it means). _Process of analyzing_ is the work our code does when trying to fit data to the schema & type. The reason why we are saying “schema & type” is that we want them somehow to be the same thing, instead of two separate things that may or may not be in sync.

### Examples in Typescript with yup

#### Example

```ts
import * as yup from 'yup'

let schema = yup.object().shape({
  name: yup.string().required(),
  age: yup.number().required().positive().integer(),
  email: yup.string().email(),
})
// data from an API, from user, etc. Note that the type would be `any`
// (or perhaps `unkown`) as we don't really know what it looks like
// if it comes from outside
const data: any = {
  name: 'jimmy',
  age: 24,
}
// check validity
schema.isValid(data).then(function (valid) {
  console.log('isValid?', valid) // => true
  // do something with the data, however, it's still `any`/`unkown`....
})
```

We still don't have a _type_ for our 'data,' as you can see. It remains 'any/unknown'. Sure, we can typecast it, but it introduces a problem: we now have to maintain a'schema' and a 'type' separately, by hand, with nothing ensuring they match.

#### Example with Typecast

```ts
let userSchema = yup.object().shape({
  name: yup.string().required(),
  age: yup.number().required().positive().integer(),
  email: yup.string().email(),
})

type UserType = {
  name: string
  age: number
  email: string
}
// check validity
schema.isValid(data).then(function (valid) {
  const user = data as UserType // it's valid so let's cast!
})
```

Still, how can you ensure that 'userSchema' and 'UserType' are in sync? Do they even stand for the same thing?

#### Example with parsing function

```ts
// Let's use some custom type aliases for readability
type PositiveInteger = number
type Email = string
type URL = string
// Type guards to validate invidiual values, fields
const isPositiveInteger = (x: any): x is PositiveInteger => yup.number().required().positive().integer().isType(x)
const isEmail = (x: any): x is Email => yup.string().required().email().isType(x)
const isString = (x: any): x is string => yup.string().required().isType(x)
// UserType again, now with our custom type aliases
type UserType = {
  name: string
  age: PositiveInteger
  email?: Email
}
/**
parse, don't validate
compiler can help us quite a bit here to make sure the parsing
is actually correct
*/
const parseToUserType = (x: any): UserType | Error => {
  let { name, age, email, website, createdOn } = x
  if (!isString(name)) return new Error('invalid name')
  if (!isPositiveInteger(age)) return new Error('invalid age')
  email = isEmail(email) ? email : undefined // optional, silently drop invalid values
  return { age, name, createdOn, email, website }
}
// Business logic is pretty awesome now!
function myHandler(): Response {
  const userType: UserType | Error = parseToUserType(data)

  if (userType instanceof Error) return { error: 'Ohh there was a 400 error' }
  // use UserType normally, do what ever you want
  return { message: `Welcome, ${userType.name}` }
}
```

- Business logic can now parse any data to `UserType`. \_Just remember to check whether there’s an Error or not.
- We are using more precise types than `string` or `number`\_ due to how type aliases work.
- The error-prone, dangerous, not-that-well-type-checked code is limited to type guards.
- TS compiler makes sure our parser actually works. _We can safely write our_`_(x: any) => UserType | Error` parser function with good support from the type checker.

### Reference

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://en.wikipedia.org/wiki/Parsing https://itnext.io/parse-dont-validate-incoming-data-in-typescript-d6d5bfb092c8


The "parse, don't validate" approach is about processing incoming data and failing in a controlled manner if parsing fails.

Parse, don't validate in TypeScript


## Why should you read this article?

- Understand how state in React works

```jsx
const [isPlayerA, setIsPlayerA] = useState(true)

function Counter(name) {
  const [score, setScore] = useState(0)
  return (
    <>
      <div>
        {name}: {score}
      </div>
      <button onClick={() => setScore(score + 1)}>+1</button>
    </>
  )
}

// ----------

// Do you think they are the same?
// ----- Approach 1
{
  isPlayerA ? <Counter name="A" /> : <Counter name="B" />
}

// ----- Approach 2
{
  isPlayerA && <Counter name="A" />
}
{
  !isPlayerA && <Counter name="B" />
}
```

## The UI Tree

![](assets/preserving-and-resetting-state-in-react_ui_tree.webp)

As you can see in the below picture, the rendering flow of React should be:

JSX --_(React)_--> UI trees --_(React DOM)_--> DOM

## State is tied to a position in the tree

- Actually, the component has _no state_. The state is stored in React and associated with the correct component based on its **position** in the UI tree.
- React preserves a component’s state for as long as it’s being rendered at its position in the UI tree.
- For example:

```js
function Counter() {
  const [score, setScore] = useState(0)

  return <div>...</div>
}

return (
  <div>
    <Counter />
    <Counter />
  </div>
)
```

- Q: Is the two `<Counter />` components the same?
- A: **No!** **These are two separate counters because each is rendered at its own position in the tree** => each of them will get its own, independent `score` state.
- In case the `<Counter />` get removed -> React discards its state

## Preserves state

- Take a look on the below example

```js
const [isFancy, setIsFancy] = useState(false);

 return (
  <div>
    {isFancy ? (
      <Counter isFancy={true} />
    ) : (
      <Counter isFancy={false} />
    )}
  </div>
  ...
)
```

- Q: Are `<Counter isFancy={true} />` and `<Counter isFancy={false} />` the same component?
- A: **Yes!** Because: same component + same position + with React's perspective -> it's the same Counter.
- Q: Why do I say it is the same position?
- A: Take a look at the UI Tree section, that it's the **position of the UI tree**, not in the JSX markup

=> **Same component + Same position -> Preserve state**

## Different components at the same position reset state

```js
const [isPaused, setIsPaused] = useState(false);

 return (
  <div>
    {isPaused ? (
      <p>See ya!</p>
    ) : (
      <Counter />
    )}
  </div>
  ...
)
```

- In this example, we switch between _different_ component types at the same position. Initially, the first child of `<div>` contained a `Counter`. But when swapped in a `p`, React removed the `Counter` from the UI tree and destroyed its state

![](assets/preserving-and-resetting-state-in-react_diff-comp-same-position.webp)

=> **Different component + Same position -> Reset the state of its entire subtree**

## Resetting state at the same position

By default, React preserves state of a component while it stays at the same position. But we have ability to reset the state.

Back to the example at the beginning of the article

```js
// Approach 1
{
  isPlayerA ? <Counter name="A" /> : <Counter name="B" />
}
```

- Q: If we use approach 1, what happens?
- A: Because the counter component in two case is the same component + same position => The state still the same. That makes a bug, although the name props changed, but the `score` still stay. It's normal in React, but it isn't what we want, right? We have 2 options for it

### Option 1: Rendering component with different positions

- It's exactly what Approach 2 does, rendering component with different positions

```js
{
  isPlayerA && <Counter name="A" />
}
{
  !isPlayerA && <Counter name="B" />
}
```

![](assets/preserving-and-resetting-state-in-react_opt1-diff-position.webp)

### Option 2: Resetting state with a key (recommendation)

```js
{
  isPlayerA ? <Counter name="A" key="A" /> : <Counter name="B" key="B" />
}
```

- Keys aren’t just for lists! You can use keys to make React distinguish between any components. By default, React uses order within the parent (first Counter component, second Counter component,...). By using key, React will know A's counter, B's counter => React won't share state between them.

## Reference

- https://beta.reactjs.org/learn/preserving-and-resetting-state


State in React is tied to a position in the UI tree.

Preserving and Resetting state in React


## What is Layout Thrashing

![](assets/prevent-layout-thrashing_layout-thrashing.webp)

Layout thrashing means forcing the browser to calculate a layout that is never rendered to the screen, which hurts performance.

## Why

Layout Thrashing happens, when you request layout information of an element or the document, while the layout is in an **invalidated state**.

```js
// any DOM or CSSOM change flags the layout as invalid
document.body.classList.add('foo')

// reads layout == forces layout calculation
const box = element.getBoundingClientRect()

// write/mutate
document.body.appendChild(someBox)

//read/measure
const color = getComputedStyle(someOtherBox).color
```

Mixing Layout Read & Layout Mutation must wait for the browser to recalculate the layout and reflow to return your Layout value.

![](assets/prevent-layout-thrashing_dont-touch-me.webp)

## How to fix

We can resolve the problem by isolating your reads from your writes. The steps would be:

- Batch Read Layout first
- Then Mutate Layout later

```js
// reads layout
const box = element.getBoundingClientRect()
const color = getComputedStyle(someOtherBox).color

// write
document.body.classList.add('foo')
document.body.appendChild(someBox)
```

Or use a library such as [fastdom](https://github.com/wilsonpage/fastdom) which abstracts those steps:

```js
import fastdom from 'fastdom'

function resizeAllParagraphsToMatchBoxWidth(paragraphs, box) {
  fastdom.measure(() => {
    const width = box.offsetWidth

    fastdom.mutate(() => {
      for (let i = 0; i < paragraphs.length; i++) {
        paragraphs[i].style.width = width + 'px'
      }
    })
  })
}
```

## How to debug

Open `Performance Tab` on Dev tool, slow down your CPU, and click `Start Profiling`.

![](assets/prevent-layout-thrashing_layout-thrashing-debug.webp)

Find purple tasks and get info in detail:

<video src="https://afarkas.github.io/layout-thrashing/material/layout-thrashing-debug.mp4" controls></video>

## List of commands causing Layout Thrashing we need to be careful when using it

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow/layout. Check out [this gist](https://gist.github.com/paulirish/5d52fb081b3570c81e3a) for additional cases and details.

## Reference

- https://gist.github.com/paulirish/5d52fb081b3570c81e3a
- https://afarkas.github.io/layout-thrashing/#/


Layout Thrashing happens, when you request layout information of an element or the document, while the layout is in an invalidated state.

Prevent Layout Thrashing


This article demonstrates how to use CSS transforms, perspective and some scaling trickery to create a pure CSS parallax scrolling website.

## Advantages of using pure CSS over JS

Although using Javascript will give us more flexibility on how we want to construct our parallax effect, it also comes with the cost of performance & implementation complexity. We listen to the `scroll` event & modify the DOM with the handler, triggering needless reflows and paints.

For more simple use cases, with pure CSS, we can:

- Avoid messing with the browser's rendering pipeline
- Allow browsers to leverage hardware acceleration while rendering, ensuring consistent frame rates & a smooth scrolling experience
- Combine with other CSS features (e.g. responsive)

## How it works

First, let's establish some barebones markup:

```html
<div class="parallax">
  <div class="layer layer-1">...</div>
  <div class="layer layer-2">...</div>
  ...
</div>
```

And the basic styles:

```css
.parallax {
  perspective: 1px;
  height: 100vh;
  overflow-x: hidden;
  overflow-y: auto;
}

.layer {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
}

.layer-1 {
  transform: translateZ(0);
}

.layer-2 {
  transform: translateZ(-1px);
}
```

The `parallax` class is where the parallax magic happens:

- Defining the `height` and `perspective` style properties of an element will lock the perspective to its centre, creating a fixed origin 3D viewport.
- Setting `overflow-y: auto` will allow the content inside the element to scroll in the usual way, but now descendant elements will be rendered relative to the fixed perspective. This is the key to creating the parallax effect.

The `layer` class defines a layer of content to which the parallax effect will be applied. The `absolute` position is optional, for the sake of display. You'll see what I meant in a moment.

Finally, the `layer-{{n}}` class is used to set Z offset of the layers. If we consider the `parallax` container is a camera viewport, the Z offset will determine whether a layer is farther away, or closer to the viewport. **The farther away a layer is, the slower it'll appear to be scrolling.**

Check it out in the CodePen below:

<iframe height="400" style="width:100%" scrolling="no" title="Pure CSS Parallax (1) - Barebones" src="https://codepen.io/ngolapnguyen/embed/wvjGRRp?default-tab=result" frameborder="no"></iframe>

## Common practices

### Parallax with multiple sections

Most parallax sites break the page into distinct sections where different effects can be applied. Here's how to do that.

First, we need a `group` element to group our layers together:

```html
<div class="parallax">
  <div class="group">
    <div class="layer layer-1">Layer 1.1</div>
    <div class="layer layer-2">Layer 1.2</div>
    <div class="layer layer-3">Layer 1.3</div>
  </div>
  ...
</div>
```

And now the styles:

```css
.group {
  ...
  transform-style: preserve-3d;
}
```

The property `transform-style: preserve-3d` prevents the browser from flattening the `layer` elements, indicating that children of the element should be positioned in the 3D-space. More on the property [here](https://developer.mozilla.org/en-US/docs/Web/CSS/transform-style).

One important rule to keep in mind when grouping elements is, **we cannot clip the content of a group**. Setting `overflow: hidden` on a `group` will break the parallax effect. Unclipped content will result in descendant elements overflowing, so we need to be creative with the `z-index` values of the groups to ensure content is correctly revealed/hidden as the visitor scrolls through the document.

### Depth correction

True to 3D transforms, elements that are farther away from the viewport will appear smaller than those that are closer. If we want them to appear to be rendered as their original size (e.g. same font-size and all), we can use the `scale` transform to do that:

```css
.layer-2 {
  transform: translateZ(-1px) scale(2);
}
```

The scale factor can be calculated with the following formula:

```
scale = 1 + (translateZ * -1) / perspective
```

### Debugging

When you are working with parallax, it can be easier to get lost among the different layers. Taking a different perspective will allow you to know where everything is in the 3D space - which you can do by applying simple transform to the group elements:

```css
.group {
  transform: translate3d(700px, 0, -800px) rotateY(30deg);
}
```

You can try out all the common practices I have mentioned in the CodePen below:

<iframe height="400" style="width: 100%;" scrolling="no" title="Pure CSS Parallax (2) - Common Practices" src="https://codepen.io/ngolapnguyen/embed/XWqdOJr?default-tab=result" frameborder="no" allowfullscreen="true"></iframe>

## References

- https://keithclark.co.uk/articles/pure-css-parallax-websites/
- https://developer.mozilla.org/en-US/docs/Web/CSS/transform-style
- https://www.youtube.com/watch?v=1wfeqDyMUx4


This article demonstrates how to use CSS transforms, perspective and some scaling trickery to create a pure CSS parallax scrolling website.

Pure CSS Parallax


Code splitting is a technique used to optimize JavaScript bundles by breaking them into smaller chunks, loading only the necessary parts when they’re needed. This reduces the initial loading time for users, as they only download the essential code to render the initial view. Code splitting is particularly valuable in large applications where bundling everything together can lead to slow load times and performance issues.

We will explore various code splitting techniques, including their use cases and practical implementation examples.

## Code splitting techniques

### Entry point splitting

Entry point splitting involves separating the main application entry points. In Webpack, you can specify multiple entry points, each generating a separate bundle. This technique is helpful in multi-page applications (MPAs) or if you have clearly separate sections within a single-page app (SPA) that can load independently.

```js
// webpack.config.js
module.exports = {
  entry: {
    home: './src/home.js',
    dashboard: './src/dashboard.js',
  },
  output: {
    filename: '[name].bundle.js',
    path: __dirname + '/dist',
  },
}
```

Here, Webpack creates `home.bundle.js` and `dashboard.bundle.js`, loading only the necessary code when the user navigates to either the home page or dashboard.

**Use case:**

- Ideal for MPAs or complex SPAs where different parts of the app can load independently.

### Route-based code splitting

Route-based code splitting is common in SPAs. Instead of loading the entire app at once, only the components needed for the current route are loaded initially. Additional routes are loaded only when the user navigates to them.

**Example with React Router and React.lazy:**

```jsx
import React, { lazy, Suspense } from 'react'
import { BrowserRouter as Router, Route, Switch } from 'react-router-dom'

const Home = lazy(() => import('./Home'))
const About = lazy(() => import('./About'))
const Contact = lazy(() => import('./Contact'))

function App() {
  return (
    <Router>
      <Suspense fallback={<div>Loading...</div>}>
        <Switch>
          <Route path="/" exact component={Home} />
          <Route path="/about" component={About} />
          <Route path="/contact" component={Contact} />
        </Switch>
      </Suspense>
    </Router>
  )
}
```

Explanation:

- `React.lazy` dynamically imports each component.
- `Suspense` shows a fallback (loading spinner) while the component loads.

**Benefits:**

- Reduces initial load time, as only the code for the first route is loaded.
- Each route loads on demand, improving perceived performance for users.

### Component-level code splitting with React.lazy and Suspense

If you have a large component that doesn’t need to load right away (e.g., a modal or sidebar), you can split it out and load it only when it’s needed. This helps reduce the initial bundle size, as non-essential components load asynchronously.

**Example: Lazy Loading a Component**

```jsx
import React, { lazy, Suspense, useState } from 'react'

const UserProfile = lazy(() => import('./UserProfile'))

function App() {
  const [showProfile, setShowProfile] = useState(false)

  return (
    <div>
      <button onClick={() => setShowProfile((prev) => !prev)}>Toggle User Profile</button>
      <Suspense fallback={<div>Loading...</div>}>{showProfile && <UserProfile />}</Suspense>
    </div>
  )
}
```

Explanation:

- The `UserProfile` component only loads when showProfile is true.
- `Suspense` ensures that a fallback UI (loading spinner) is displayed while `UserProfile` is being loaded.

**Use cases:**

- Large, non-essential components such as modals, drawers, or other sections that users may not access right away.

### Splitting large dependencies or utilities

Sometimes a single library or utility can significantly increase your bundle size. Instead of loading the entire library, use dynamic `import()` to load only the necessary part of the code when needed. This is particularly useful for utilities like date formatting or image processing libraries that may not be required on every page.

**Example: Lazy Loading a utility library**

```jsx
function DateFormatter({ date }) {
  const [formattedDate, setFormattedDate] = useState('')

  useEffect(() => {
    async function loadDateLibrary() {
      const { format } = await import('date-fns')
      setFormattedDate(format(new Date(date), 'yyyy-MM-dd'))
    }
    loadDateLibrary()
  }, [date])

  return <div>{formattedDate}</div>
}
```

Explanation:

- The date-fns library only loads when DateFormatter is rendered.
- This avoids including the entire library in the initial bundle, saving on bundle size.

**Benefits:**

- Reduces initial load time by avoiding unnecessary libraries in the main bundle.
- Load dependencies only when needed, improving performance and responsiveness.

### Library-Based Code Splitting with `react-loadable`

For more complex loading scenarios, `react-loadable` offers additional features such as delayed loading, error boundaries, and preloading. It’s especially helpful if you want to provide a custom loading experience or handle loading errors gracefully.

**Example using react-loadable**

```jsx
import Loadable from 'react-loadable'

const LoadableComponent = Loadable({
  loader: () => import('./HeavyComponent'),
  loading: ({ isLoading, pastDelay, error }) => {
    if (isLoading && pastDelay) return <div>Loading...</div>
    if (error) return <div>Error loading component!</div>
    return null
  },
  delay: 300, // Shows loading only if loading takes longer than 300ms
})

function App() {
  return <LoadableComponent />
}
```

Explanation:

- `react-loadable` provides a loading component that displays based on certain conditions, such as past delay time or error occurrence.
- This allows you to handle cases where loading might take a long time or fail altogether, providing a better user experience.

**Use cases:**

- Components that may take longer to load due to their size or network conditions.
- Error-prone components that need error handling.

## Advanced Code Splitting Techniques

### Preloading and Prefetching Components

Preloading and prefetching are useful when you want to load components in advance, either to improve performance or to anticipate user interactions.

- **Preload**: Load code for a component in the background, without delaying the initial page load.
- **Prefetch**: Load code when the user is likely to need it soon, based on user interaction patterns (e.g., hovering over a link).

```jsx
const UserProfile = lazy(() => import(/* webpackPrefetch: true */ './UserProfile'))
```

**Use case:**

- Preload the next route’s component in the background while the user is interacting with the current route.

### Bundle Splitting

Bundling tools, such as Webpack, that have the `SplitChunksPlugin` component can be configured to automatically separate common dependencies (like react or lodash) into distinct bundles. This avoids redundant code in each chunk and reduces the total bundle size.

**Example configuration in Webpack:**

```js
module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',
      minSize: 30000,
      maxSize: 50000,
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
        },
      },
    },
  },
}
```

Explanation:

- `SplitChunksPlugin` creates a vendors chunk with common dependencies, reducing redundancy and improving caching.

**Use Case:**

- In large applications with many shared dependencies.

### Lazy loading images and assets

For non-JavaScript assets like images and fonts, you can also improve performance by loading them only when they’re in the viewport.

**Example: Lazy Loading Images with `loading="lazy"`**

```jsx
function ImageComponent() {
  return <img src="path/to/image.jpg" loading="lazy" alt="Lazy loaded image" />
}
```

Explanation:

- The `loading="lazy"` attribute ensures the image loads only when it’s about to enter the viewport.

**Benefits:**

- Reduces initial data transfer, helping pages load faster, especially when there are many images.

### Summary

| Technique                      | Best For                                                 | Examples                                               |
| ------------------------------ | -------------------------------------------------------- | ------------------------------------------------------ |
| **Entry Point Splitting**      | Multi-page apps with separate entry points               | Home, Admin, Dashboard entry points                    |
| **Route-Based Splitting**      | Single-page apps, lazy loading route components          | Lazy loading routes with React Router                  |
| **Component-Level Splitting**  | Large components like modals, settings panels            | Lazy loading non-essential components                  |
| **Large Dependency Splitting** | Libraries used infrequently                              | Date formatting utilities, large image processing libs |
| **Library-Based Splitting**    | Components that need advanced loading/error handling     | `react-loadable` for complex loading states            |
| **Preloading and Prefetching** | Anticipating user actions to improve UX                  | Preloading next route or component                     |
| **Bundle Splitting**           | Avoiding redundancy by splitting common dependencies     | Splitting `vendors` bundle                             |
| **Lazy Loading Images**        | Reducing initial page weight for media-rich applications | `loading="lazy"` attribute on images                   |

Each of these techniques targets a specific aspect of load management and bundle optimization, providing flexibility to load only what’s necessary. Applying them strategically improves both the initial load time and the user experience throughout the app, especially as users navigate or interact more deeply with various parts of the application.


Optimize JavaScript performance with code splitting techniques like route-based splitting, lazy loading, and dynamic imports

Code splitting

Code splitting in React


Component composition patterns are foundational for creating scalable, flexible, and reusable React components. They allow us to build UIs by combining smaller, single-purpose components in various ways.

## Key composition patterns in React

### Higher-order components (HOCs)

HOCs are functions that take a component and return a new component, adding additional functionality. They’re particularly useful for cross-cutting concerns like logging, analytics, or authentication.

**Example use case**: Suppose you need to add logging functionality to multiple components. Instead of embedding logging code in each component, you create an HOC that wraps each component and handles the logging logic.

```js
function withLogging(WrappedComponent) {
  return function EnhancedComponent(props) {
    useEffect(() => {
      console.log(`Component ${WrappedComponent.name} mounted`)
    }, [])
    return <WrappedComponent {...props} />
  }
}
```

**When to use HOCs**:

- For injecting props or shared behavior across multiple components.
- To handle cross-cutting concerns that aren’t tightly coupled with the component’s core logic.
- When you want to avoid prop drilling by creating an abstraction layer.

**Trade-offs**:

- Can lead to “wrapper hell” if overused.
- Less popular with modern hooks as custom hooks can sometimes achieve similar results in a more straightforward way.

### Render props

With render props, a component uses a prop as a function to control its output, allowing you to pass dynamic rendering logic.

**Example use case**: If you have a `<DataFetcher />` component that retrieves data, you could use render props to define how that data should be rendered by the consuming component.

```js
function DataFetcher({ render }) {
  const [data, setData] = useState(null)
  useEffect(() => {
    fetchData().then(setData)
  }, [])
  return render(data)
}

// Usage:
;<DataFetcher render={(data) => <DisplayData data={data} />} />
```

**When to use render props**:

- For providing control over how the child component renders data.
- When the consuming component needs flexibility in rendering but also needs the data or logic encapsulated in the parent.

**Trade-offs**:

- Can lead to deeply nested code if not structured thoughtfully.
- Not as widely used with hooks and context, which often simplify sharing functionality across components.

### Compound components

Compound components are components that work together as a single unit but allow for great customization of individual parts.

**Example use case**: A `<Dropdown />` component that lets you use `<Dropdown.Toggle />` and `<Dropdown.Menu />` as children, giving flexibility to control each part while keeping the structure consistent.

```js
function Dropdown({ children }) {
  const [isOpen, setIsOpen] = useState(false)
  return (
    <DropdownContext.Provider value={{ isOpen, setIsOpen }}>
      <div className="dropdown">{children}</div>
    </DropdownContext.Provider>
  )
}

Dropdown.Toggle = function Toggle() {
  const { setIsOpen } = useContext(DropdownContext)
  return <button onClick={() => setIsOpen((open) => !open)}>Toggle</button>
}

Dropdown.Menu = function Menu({ children }) {
  const { isOpen } = useContext(DropdownContext)
  return isOpen ? <div className="menu">{children}</div> : null
}
```

**When to use compound components**:

- When you have related components that need to work together in a coordinated way but require customization for each part.
- Especially effective for components like modals, tabs, or dropdowns.

**Trade-offs**:

- Requires careful management of context to avoid coupling.
- If the API isn’t intuitive, can be confusing for developers unfamiliar with the compound pattern.

### Controlled and uncontrolled components

Controlled components let the parent manage the state, whereas uncontrolled components manage their own state internally. Combining them allows more flexibility in form components.

**Example use case**: A `<TextInput />` component that can work either as a controlled component (with value and onChange passed from the parent) or an uncontrolled component (handling its own state).

```js
function TextInput({ value, defaultValue, onChange }) {
    const [internalValue, setInternalValue] = useState(defaultValue);
    const isControlled = value !== undefined;

    const handleChange = (e) => {
        const newValue = e.target.value;
        if (isControlled) {
            onChange(newValue);
        } else {
            setInternalValue(newValue);
        }
    };

    return (
        <input
            value={isControlled ? value : internalValue}
            onChange={handleChange}
        />
    );
}

// Usage:
<TextInput defaultValue="Uncontrolled" />
<TextInput value={controlledValue} onChange={setControlledValue} />
```

**When to use controlled and uncontrolled components**:

- Controlled components are essential for forms or any element that requires data validation.
- Uncontrolled components are more performant and simpler for elements without validation needs.

**Trade-offs**:

- Controlled components can lead to performance issues in large forms.
- Uncontrolled components lack flexibility for handling validation or dynamic data flow.

### Custom hooks

Custom hooks provide a way to abstract and encapsulate complex logic, making components more modular and readable. They can be used in place of certain HOCs and render props for handling things like async data, complex state, or side effects.

**Example use case**: If you frequently need to fetch data in multiple components, a `useFetch` custom hook encapsulates this logic, making the components cleaner and more testable.

```js
function useFetch(url) {
  const [data, setData] = useState(null)
  useEffect(() => {
    fetch(url)
      .then((response) => response.json())
      .then(setData)
  }, [url])
  return data
}
```

**When to use custom hooks**:

- When encapsulating side effects, data fetching, or complex state logic.
- As a more readable and flexible alternative to HOCs and render props.

**Trade-offs**:

- Dependency management in hooks can be tricky, especially with complex dependencies.
- Not ideal for injecting UI-related functionality that might be easier to handle with HOCs or render props.

## Choosing the right pattern

Selecting the right pattern often depends on:

- **Complexity of data flow**: If your data flow is complex, consider compound components or render props.
- **Component reusability**: HOCs are ideal for reusable logic across unrelated components.
- **Level of control**: Controlled/uncontrolled patterns are great for balancing simplicity and flexibility in form handling.


Learn React composition patterns with coverage of HOCs, render props, compound components, and custom hook

Component composition patterns

Component composition patterns in React


Design system integration in React involves creating a set of reusable, consistent, and easily maintainable components that reflect your app’s design guidelines. Integrating a design system helps ensure visual and functional consistency across your application while allowing for scalability as new components and features are added. Design systems often include UI components, design tokens, typography, colors, icons, spacing guidelines, and accessibility standards.

**Key steps and concepts for design system integration in react**

1. Define the core design tokens (colors, typography, spacing, etc.)
2. Build atomic components (buttons, inputs, typography)
3. Create composable, flexible components
4. Establish and use a component library framework (Storybook)
5. Implement accessibility standards
6. Use context and theming for adaptable designs

### 1. Define core design tokens

**Design tokens** are the fundamental building blocks of your design system. They represent design decisions like colors, typography, and spacing in a consistent, reusable format. By defining tokens, you create a single source of truth that makes updates and adjustments easy across the app.

**Example: Design tokens in a JSON format**

```json
{
  "colors": {
    "primary": "#007bff",
    "secondary": "#6c757d",
    "background": "#f8f9fa",
    "text": "#212529"
  },
  "typography": {
    "fontFamily": "Arial, sans-serif",
    "fontSize": {
      "small": "12px",
      "medium": "16px",
      "large": "24px"
    }
  },
  "spacing": {
    "small": "4px",
    "medium": "8px",
    "large": "16px"
  }
}
```

You can then access and apply these tokens in your components, ensuring they follow consistent visual guidelines.

**In a React component:**

```js
import tokens from './tokens.json'

const Button = ({ children }) => (
  <button
    style={{
      backgroundColor: tokens.colors.primary,
      color: tokens.colors.background,
      padding: tokens.spacing.medium,
      fontSize: tokens.typography.fontSize.medium,
      fontFamily: tokens.typography.fontFamily,
    }}
  >
    {children}
  </button>
)
```

### 2. Build atomic components

Atomic design breaks down UI elements into **atoms**, **molecules**, **organisms**, **templates**, and **pages**. This approach helps in building reusable, low-level components that can be combined and customized to create more complex components and layouts.

**Atomic design hierarchy:**

- **Atoms**: Smallest, single-purpose components like buttons, inputs, or labels.
- **Molecules**: Combinations of atoms, such as an input field with a label.
- **Organisms**: Groups of molecules that form distinct sections, like a header or a form.
- **Templates and pages**: Higher-level layouts or complete screens that use organisms and molecules.

**Example: Button component (atom)**

```jsx
const Button = ({ label, onClick, variant = 'primary' }) => {
  const styles = {
    primary: {
      backgroundColor: tokens.colors.primary,
      color: tokens.colors.background,
    },
    secondary: {
      backgroundColor: tokens.colors.secondary,
      color: tokens.colors.background,
    },
  }

  return (
    <button style={styles[variant]} onClick={onClick}>
      {label}
    </button>
  )
}
```

**Example: Form component (molecule)**

```jsx
const FormField = ({ label, type = 'text', value, onChange }) => (
  <div>
    <label>{label}</label>
    <input type={type} value={value} onChange={onChange} />
  </div>
)
```

### 3. Create composable, flexible components

Design systems benefit from **flexible components** that can adapt to different use cases without being overly rigid. Use **props** and **styled-system** libraries (e.g., styled-components or emotion) to make your components customizable.

```jsx
import styled from 'styled-components'
import tokens from './tokens.json'

const Button = styled.button`
  padding: ${tokens.spacing.medium};
  font-size: ${tokens.typography.fontSize.medium};
  color: ${({ variant }) => tokens.colors[variant]};
  background-color: ${({ bg }) => bg || tokens.colors.background};
`
```

This approach allows the Button component to be reusable, enabling different colors and backgrounds with minimal code.

### 4. Establish and use a component library framework (Storybook)

[Storybook](https://storybook.js.org/) is a popular tool for creating isolated component libraries, documenting components, and allowing team members to interact with components outside of the application environment.

**Set up Storybook**

Install Storybook in your React project.

```sh
npx sb init
```

**Write stories for components**

Each component should have its own story, describing its appearance with various props and states.

```jsx
// Example: Button.stories.js
import React from 'react'
import { Button } from './Button'

export default {
  title: 'Design system/Button',
  component: Button,
}

export const Primary = () => <Button variant="primary" label="Primary Button" />
export const Secondary = () => <Button variant="secondary" label="Secondary Button" />
```

**Benefits:**

- Provides a single source of truth for UI components, where designers and developers can collaborate.
- Enables interactive testing of each component’s variations, ensuring they meet design requirements.
- Encourages consistency across components, as each component variation is clearly documented.

### 5. Implement accessibility standards

Design systems must prioritize accessibility to create inclusive applications. Follow **WCAG guidelines** and use accessible components, ensuring that all users can interact with your app.

- **Color contrast**: Use tokens that meet accessibility standards for contrast. Tools like axe can test for color contrast and other accessibility issues.

- **Aria roles and attributes**: Use ARIA attributes for interactive components like buttons, modals, and dialogs to improve screen reader support.

```jsx
// Example: Accessible button with ARIA
const Button = ({ label, onClick, ariaLabel, variant = 'primary' }) => (
  <button onClick={onClick} style={{ backgroundColor: tokens.colors[variant] }} aria-label={ariaLabel}>
    {label}
  </button>
)
```

- **Keyboard navigation**: Ensure that all components can be navigated via keyboard. Focus management is crucial, especially for modal dialogs or dynamic components like carousels.

```jsx
// Example: Focus management in a modal
import { useEffect, useRef } from 'react'

const Modal = ({ isOpen, onClose, children }) => {
  const closeButtonRef = useRef()

  useEffect(() => {
    if (isOpen) {
      closeButtonRef.current.focus()
    }
  }, [isOpen])

  return isOpen ? (
    <div role="dialog" aria-modal="true" tabIndex={-1}>
      <button ref={closeButtonRef} onClick={onClose}>
        Close
      </button>
      {children}
    </div>
  ) : null
}
```

Tools:

- `axe-core` and `eslint-plugin-jsx-a11y` for testing accessibility issues.
- `Storybook accessibility addon` to validate and fix issues while developing components.

### 6. Use context and theming for adaptable designs

To support **themes** (e.g., dark and light modes), use **context providers** to pass theme values down to components. This enables consistent theming and allows the user to switch themes easily.

**Example: Theming with context**

1. Create theme context:

```jsx
import React, { createContext, useContext, useState } from 'react'
import tokens from './tokens.json'

const ThemeContext = createContext()

export const ThemeProvider = ({ children }) => {
  const [theme, setTheme] = useState('light')

  const toggleTheme = () => setTheme((prev) => (prev === 'light' ? 'dark' : 'light'))

  const themeStyles = theme === 'light' ? tokens.light : tokens.dark

  return <ThemeContext.Provider value={{ theme, themeStyles, toggleTheme }}>{children}</ThemeContext.Provider>
}

export const useTheme = () => useContext(ThemeContext)
```

2. Consume theme context in components:

```jsx
const ThemedButton = ({ label }) => {
  const { themeStyles } = useTheme()
  return (
    <button
      style={{
        backgroundColor: themeStyles.colors.primary,
        color: themeStyles.colors.background,
      }}
    >
      {label}
    </button>
  )
}
```

3. Switch themes in app:

```jsx
function App() {
  const { toggleTheme } = useTheme()
  return (
    <div>
      <ThemedButton label="Click me" />
      <button onClick={toggleTheme}>Toggle Theme</button>
    </div>
  )
}
```

### Summary

| Technique                           | Purpose                                                                                  |
| ----------------------------------- | ---------------------------------------------------------------------------------------- |
| **Design tokens**                   | Centralize colors, typography, and spacing for consistent styling                        |
| **Atomic components**               | Build scalable, reusable components from basic building blocks                           |
| **Composable, flexible components** | Ensure flexibility for various use cases using props and dynamic styling                 |
| **Storybook**                       | Document, test, and showcase all components, ensuring design and functionality alignment |
| **Accessibility standards**         | Improve usability for all users, following WCAG and ARIA best practices                  |
| **Context and theming**             | Support adaptable designs, allowing for light and dark themes or other custom themes     |

By integrating these techniques, you can build a design system that is robust, adaptable, and consistent, making it easier to scale and maintain the UI over time.


Learn how to integrate design systems in React applications with comprehensive coverage of design tokens, atomic components, and accessibility standards.

Design system integration

Design system integration in react


Hooks architecture in React refers to the systematic approach of using hooks to manage state, side effects, and reusable logic across components. **Custom hooks** are one of the most powerful features, allowing you to encapsulate and reuse complex logic independently of component structure. Custom hooks improve code readability, keep components lean, and make stateful logic portable and composable.

### Key concepts in hooks architecture

- Separation of concerns with custom hooks
- Encapsulating side effects
- Dependency management in hooks
- Combining multiple custom hooks

### Separation of concerns with custom hooks

By creating custom hooks, we can isolate specific pieces of logic or state, making components simpler and easier to test. Custom hooks follow the same naming conventions and usage patterns as built-in hooks but encapsulate domain-specific or app-specific logic.

**Example: `useFetch` hook for data fetching**

```jsx
import { useState, useEffect } from 'react'

function useFetch(url) {
  const [data, setData] = useState(null)
  const [loading, setLoading] = useState(true)
  const [error, setError] = useState(null)

  useEffect(() => {
    setLoading(true)
    fetch(url)
      .then((response) => response.json())
      .then((data) => setData(data))
      .catch((error) => setError(error))
      .finally(() => setLoading(false))
  }, [url])

  return { data, loading, error }
}
```

Usage:

```js
function UserProfile({ userId }) {
  const { data, loading, error } = useFetch(`/api/users/${userId}`)

  if (loading) return <p>Loading...</p>
  if (error) return <p>Error loading data.</p>

  return <div>{data.name}</div>
}
```

**Benefits**:

- **Reusability**: The `useFetch` hook can be used in any component needing data from an API.
- **Isolation of concerns**: Data fetching logic is isolated, keeping components focused on UI and presentation.

### Encapsulating side effects

Side effects (like fetching data, managing subscriptions, or setting timeouts) often clutter component code. By moving these side effects into custom hooks, we can encapsulate the logic and improve component readability.

**Example: `useDocumentTitle` hook for updating the document title**

```js
import { useEffect } from 'react'

function useDocumentTitle(title) {
  useEffect(() => {
    document.title = title
  }, [title])
}
```

Usage:

```js
function HomePage() {
  useDocumentTitle('Home - My App')
  return <div>Welcome to the Home Page</div>
}
```

**Benefits**:

- **Isolation of side effects**: The document title logic is separate from the component's main UI, simplifying the component.
- **Reusability**: `useDocumentTitle` can be reused across pages or components that need to set the document title.

### Dependency management in hooks

Custom hooks require careful handling of dependencies to avoid bugs, stale data, or unintended behaviors. `useEffect`, `useMemo`, and `useCallback` hooks depend on stable dependencies to function predictably.

**Example: Managing dependencies with `useMemo`**

Suppose we need to calculate an expensive value in a hook, which depends on certain props or state. Using `useMemo` ensures the computation only runs when necessary.

```js
import { useMemo } from 'react'

function useExpensiveCalculation(data) {
  const result = useMemo(() => {
    // Expensive calculation here
    return data.reduce((sum, num) => sum + num, 0)
  }, [data])

  return result
}
```

Usage:

```js
function Stats({ numbers }) {
  const total = useExpensiveCalculation(numbers)
  return <div>Total: {total}</div>
}
```

**Benefits**:

- **Efficiency**: By memoizing the result, we avoid recalculating every render, improving performance.
- **Stable dependencies**: Carefully setting dependencies ensures the calculation only reruns when `data` changes.

> In the future, this step will be handled automatically by [React compiler](https://react.dev/learn/react-compiler#what-does-the-compiler-do)

### Combining multiple custom hooks

For more complex scenarios, multiple custom hooks can be combined, keeping components modular and avoiding deeply nested hooks. You can chain hooks to build up increasingly complex functionality without cluttering a single hook.

**Example: Using `useAuth` and `useFetch` together**

```js
// useAuth.js import { useState } from "react";

function useAuth() {
  const [user, setUser] = useState(null)

  const login = (userData) => setUser(userData)
  const logout = () => setUser(null)

  return { user, login, logout }
}

// useUserData.js import useFetch from "./useFetch";

function useUserData(userId) {
  const { data, loading, error } = useFetch(`/api/users/${userId}`)
  return { data, loading, error }
}

// Usage in a component

function Dashboard({ userId }) {
  const { user, login, logout } = useAuth()
  const { data: userData, loading } = useUserData(userId)

  return (
    <div>
      {user ? (
        <div>
          <button onClick={logout}>Logout</button>
          {loading ? <p>Loading user data...</p> : <p>Welcome, {userData.name}</p>}
        </div>
      ) : (
        <button onClick={() => login({ id: userId, name: 'John Doe' })}>Login</button>
      )}
    </div>
  )
}
```

**Benefits**:

- **Modularity**: Each hook handles a specific concern (auth or fetching data), so they're independently reusable and testable.
- **Encapsulation**: The component doesn't need to understand the logic inside each hook, only the returned data and functions.

### Best practices for custom hooks

**Use clear naming conventions**: Name hooks descriptively, starting with `use`, such as `useAuth`, `useFetchData`, or `useToggle`. This helps with readability and code consistency.

**Return only necessary data and functions**: Custom hooks should return only the data and functions the component actually needs. This minimizes the hook's API surface and reduces complexity.

```js
// Better: return only what's needed
function useToggle(initialState = false) {
  const [state, setState] = useState(initialState)
  const toggle = () => setState((prev) => !prev)
  return [state, toggle]
}
```

**Handle edge cases and errors gracefully**: Build error handling directly into hooks, where applicable. This keeps components from dealing with low-level error handling, focusing only on displaying relevant information to the user.

```js
function useFetch(url) {
  const [data, setData] = useState(null)
  const [error, setError] = useState(null)

  useEffect(() => {
    fetch(url)
      .then((response) => response.json())
      .then(setData)
      .catch(setError)
  }, [url])

  return { data, error }
}
```

**Encapsulate complex state logic**: If you find yourself managing complex state logic (e.g., multiple variables, resetting state), consider using `useReducer` within the hook.

```jsx
import { useReducer } from 'react'

function formReducer(state, action) {
  switch (action.type) {
    case 'update':
      return { ...state, [action.field]: action.value }
    case 'reset':
      return action.initialState
    default:
      return state
  }
}

function useForm(initialState) {
  const [state, dispatch] = useReducer(formReducer, initialState)

  const updateField = (field, value) => dispatch({ type: 'update', field, value })
  const resetForm = () => dispatch({ type: 'reset', initialState })

  return [state, updateField, resetForm]
}
```

**Testing custom hooks**: Test custom hooks in isolation to ensure they behave as expected under various scenarios. Tools like **React testing library's `renderHook`** make it easy to test hooks directly.

```js
import { renderHook, act } from '@testing-library/react-hooks'
import useToggle from './useToggle'

test('should toggle state', () => {
  const { result } = renderHook(() => useToggle())

  act(() => {
    result.current[1]() // Call toggle function
  })

  expect(result.current[0]).toBe(true) // Assert the toggled state
})
```

### Combining techniques in a custom hook system

Imagine you need a custom hook system for managing user authentication, including login, logout, fetching user data, and handling user permissions. We'll create modular hooks that interact but remain individually reusable.

1.  **`useAuth` for authentication**: Manages login and logout functions and holds user session data.
2.  **`useUserData` for data fetching**: Fetches user-specific data from the server.
3.  **`usePermissions` for role-based access**: Checks permissions based on the user's roles.

**Combining custom hooks**:

```js
// useAuth.js
function useAuth() {
  const [user, setUser] = useState(null)

  const login = (userData) => setUser(userData)
  const logout = () => setUser(null)

  return { user, login, logout }
}

// useUserData.js
import useFetch from './useFetch'

function useUserData(userId) {
  const { data, loading, error } = useFetch(`/api/users/${userId}`)
  return { data, loading, error }
}

// usePermissions.js
function usePermissions(userRoles = []) {
  const hasPermission = (permission) => userRoles.includes(permission)
  return { hasPermission }
}

// Usage in a component
function AdminDashboard({ userId }) {
  const { user, login, logout } = useAuth()
  const { data: userData, loading: dataLoading } = useUserData(userId)
  const { hasPermission } = usePermissions(userData ? userData.roles : [])

  return (
    <div>
      {user ? (
        <div>
          <button onClick={logout}>Logout</button>
          {dataLoading ? <p>Loading user data...</p> : hasPermission('admin') ? <p>Welcome, Admin {userData.name}</p> : <p>Access denied</p>}
        </div>
      ) : (
        <button onClick={() => login({ id: userId, name: 'Jane Doe' })}>Login</button>
      )}
    </div>
  )
}
```

By modularizing each piece of the authentication system into separate custom hooks, we ensure that each hook is individually testable, reusable, and manageable. This approach keeps the `AdminDashboard` component focused on rendering, with minimal logic.

### Summary

Custom hooks provide a powerful way to architect stateful and reusable logic in React applications. By following best practices and focusing on modularity, you can create hooks that are easy to test, maintain, and scale across complex applications. The approach to combining, organizing, and testing these hooks leads to clean, efficient, and high-quality code.


React hooks architecture with in-depth coverage of custom hooks, state management, and side effects handling.

Hook architecture

Hook architecture in react


Client-side rendering (CSR), server-side rendering (SSR), and static-site generation (SSG) are three key rendering strategies in modern web development. Each approach has unique advantages and trade-offs, impacting application performance, SEO, and user experience.

### Client-side rendering (CSR)

CSR is the default rendering approach in React applications, where everything from data fetching to rendering happens in the browser. The server delivers a minimal HTML file with a JavaScript bundle, and React takes over from there, rendering the content on the client's side.

#### How it works

- The browser downloads the JavaScript bundle, which contains the React code.
- React builds the UI on the client by executing the JavaScript code.
- Data fetching happens after the page loads, potentially leading to a delay before content appears.

#### Advantages

- **Fast initial deployment**: Easier to deploy and manage since there's no server-rendering setup.
- **Rich interactivity**: Great for SPAs (single page applications) with dynamic, highly interactive UI elements.
- **Simplified development**: Client-side data fetching and rendering simplify development in many scenarios.

#### Disadvantages

- **Initial load time**: Users may experience a blank page or loading spinner until the JavaScript bundle downloads and renders.
- **SEO challenges**: Since the HTML is minimal, search engines may struggle to crawl and index content, although some modern crawlers can render JavaScript.
- **Performance**: Large bundles can lead to slow page load times, especially on low-bandwidth connections.

#### Example in React

In CSR, data fetching happens on the client side, typically using hooks like `useEffect`.

```jsx
import { useState, useEffect } from 'react'

function UserProfile({ userId }) {
  const [user, setUser] = useState(null)

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then((response) => response.json())
      .then((data) => setUser(data))
  }, [userId])

  return user ? <div>{user.name}</div> : <div>Loading...</div>
}
```

### Server-side rendering (SSR)

SSR generates HTML on the server for each request. When the user requests a page, the server processes the JavaScript, fetches any necessary data, and returns a fully-rendered HTML page. React components are rendered to HTML strings on the server and sent to the client, where React "hydrates" (attaches event listeners) to the HTML.

#### How it works

- The server generates HTML with the initial content and sends it to the client.
- The client receives a fully-rendered HTML page and hydrates it, enabling interactivity.
- Additional JavaScript for further user interactions loads in the background.

#### Advantages

- **Improved SEO**: The initial HTML page is fully rendered, making it easily crawlable by search engines.
- **Faster time to interactive (TTI)**: The user sees the fully-rendered content sooner, as it doesn't rely solely on client-side JavaScript for initial render.
- **Content accessibility**: Even users on slow networks or with JavaScript disabled can see the initial page content.

#### Disadvantages

- **Server load**: Each request requires the server to render the page, increasing server workload, especially with many requests.
- **Complexity**: Requires server infrastructure and additional setup, which can increase complexity.
- **Hydration time**: The browser still needs to download JavaScript and hydrate the page, which can create a slight delay for interactivity.

#### Example in Next.js

Next.js is a React framework that simplifies SSR. With Next.js, you can use `getServerSideProps` to fetch data and render it on the server.

```jsx
// pages/profile/[id].js

import React from 'react'

export async function getServerSideProps(context) {
  const { id } = context.params
  const res = await fetch(`https://api.example.com/users/${id}`)
  const user = await res.json()

  return { props: { user } }
}

export default function UserProfile({ user }) {
  return <div>{user.name}</div>
}
```

### Static-site generation (SSG)

SSG generates HTML at build time. Unlike SSR, which renders HTML on each request, SSG pre-renders pages as static files and serves them on request. This is ideal for content that doesn't change frequently, as it combines the benefits of SSR with the speed of serving static files.

#### How it works

- The pages are pre-rendered at build time, creating static HTML files.
- When a user requests a page, the server serves the static HTML directly from a CDN or hosting server.
- Any dynamic content or interactivity can be added client-side, often using JavaScript to fetch data or modify the UI after load.

#### Advantages

- **Fast performance**: Since the pages are static files, they load very quickly from a CDN or server.
- **SEO-friendly**: Like SSR, the static HTML is crawlable by search engines.
- **Low server load**: No need to generate HTML per request, reducing server resources.

#### Disadvantages

- **Less flexibility**: Pages are generated at build time, so content updates require a new build and deployment.
- **Not ideal for highly dynamic content**: SSG is less suitable for frequently changing content, as updates won't appear until the next build.
- **Extra build time**: Large sites can have long build times if each page needs to be generated statically.

#### Example in Next.js

In Next.js, `getStaticProps` generates static pages at build time. This is perfect for content like blog posts or product pages.

```jsx
// pages/posts/[id].js

import React from 'react'

export async function getStaticProps({ params }) {
  const res = await fetch(`https://api.example.com/posts/${params.id}`)
  const post = await res.json()

  return { props: { post } }
}

export async function getStaticPaths() {
  const res = await fetch('https://api.example.com/posts')
  const posts = await res.json()

  const paths = posts.map((post) => ({
    params: { id: post.id.toString() },
  }))

  return { paths, fallback: false }
}

export default function Post({ post }) {
  return <div>{post.title}</div>
}
```

### Comparing CSR, SSR, and SSG

| Feature               | CSR (client-side rendering)                     | SSR (server-side rendering)                             | SSG (static-site generation)                      |
| --------------------- | ----------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------- |
| **Data fetching**     | Client-side (after page load)                   | Server-side (on each request)                           | Server-side (at build time)                       |
| **Rendering**         | Browser                                         | Server for initial, browser for subsequent interactions | Server at build time, browser for interactions    |
| **Best for**          | Highly interactive apps, SPAs                   | SEO-sensitive, frequently updated content               | Static content, rarely changing pages             |
| **SEO**               | Limited SEO (due to initial blank HTML)         | Great SEO (initial HTML contains full content)          | Great SEO (pre-rendered HTML at build time)       |
| **Initial load time** | Depends on bundle size, slower initial load     | Faster initial load, HTML is pre-rendered               | Fastest (serving static files), low latency       |
| **Content freshness** | Real-time updates                               | Real-time updates                                       | Stale until next build                            |
| **Hosting cost**      | Lower hosting cost (only needs a static server) | Higher hosting cost (server processes each request)     | Lower hosting cost (can use CDN for static files) |

### Choosing between CSR, SSR, and SSG

- **CSR** is best for SPAs or applications with highly interactive interfaces that don't rely heavily on SEO, such as dashboards and internal tools.
- **SSR** is suitable for applications that require both SEO and dynamic content, like e-commerce sites or blogs with frequently updated content.
- **SSG** is ideal for static content that doesn't change often, like documentation sites, blog pages, or marketing landing pages.

### Combining CSR, SSR, and SSG

In some cases, applications use a **hybrid approach** to leverage the strengths of each technique. For instance:

- **Next.js** allows you to use SSG for pages with static content, SSR for dynamic pages, and CSR for client-specific interactions.
- **Incremental static regeneration (ISR)** in Next.js enables automatic regeneration of static pages at a specified interval, combining the benefits of SSG and SSR for frequently updated content.

**Example hybrid approach in Next.js**

In this example, we use SSG with ISR for product pages and CSR for interactive features like adding items to a cart.

```jsx
// pages/product/[id].js

import { useState } from 'react'

export async function getStaticProps({ params }) {
  const res = await fetch(`https://api.example.com/products/${params.id}`)
  const product = await res.json()

  return { props: { product }, revalidate: 60 } // ISR: regenerates every 60 seconds
}

export async function getStaticPaths() {
  const res = await fetch('https://api.example.com/products')
  const products = await res.json()

  const paths = products.map((product) => ({
    params: { id: product.id.toString() },
  }))

  return { paths, fallback: 'blocking' }
}

export default function Product({ product }) {
  const [cart, setCart] = useState([])

  const addToCart = () => {
    setCart((prevCart) => [...prevCart, product])
  }

  return (
    <div>
      <h1>{product.name}</h1>
      <button onClick={addToCart}>Add to Cart</button>
    </div>
  )
}
```

- **SSG with ISR** serves the product page with updated data every 60 seconds.
- **CSR** is used for the cart functionality, allowing client-side interactions without reloading the page.

### Summary

Choosing between CSR, SSR, and SSG depends on your application's needs for SEO, content freshness, interactivity, and performance. In many modern apps, a hybrid approach allows you to take advantage of each strategy where it's most beneficial, creating a fast, SEO-friendly, and interactive experience. Leveraging frameworks like Next.js simplifies managing these different rendering methods in a single React application, making it easier to build performant, user-friendly applications.


React rendering strategies with in-depth coverage of client-side rendering (CSR), server-side rendering (SSR), and static site generation (SSG).

Rendering strategies

Rendering strategies in React


State management is a core architectural topic in React, especially as applications grow in complexity. While local component state (using `useState` or `useReducer`) is suitable for small to medium apps, more sophisticated state management strategies become essential as your app scales.

### Local component state with hooks

React’s native `useState` and `useReducer` are sufficient for managing state at the component level and are efficient for isolated, reusable components. However, challenges arise when dealing with deeply nested or cross-component data dependencies.

**Example use case**

Use `useReducer` for managing local form state with multiple dependent fields.

```js
const initialFormState = { name: '', email: '', password: '' }

function formReducer(state, action) {
  switch (action.type) {
    case 'UPDATE_FIELD':
      return { ...state, [action.field]: action.value }
    case 'RESET':
      return initialFormState
    default:
      return state
  }
}

function SignupForm() {
  const [state, dispatch] = useReducer(formReducer, initialFormState)

  const handleChange = (e) => {
    dispatch({
      type: 'UPDATE_FIELD',
      field: e.target.name,
      value: e.target.value,
    })
  }

  return (
    <form>
      <input name="name" value={state.name} onChange={handleChange} />
      <input name="email" value={state.email} onChange={handleChange} />
      <input name="password" type="password" value={state.password} onChange={handleChange} />
      <button type="button" onClick={() => dispatch({ type: 'RESET' })}>
        Reset
      </button>
    </form>
  )
}
```

**When to use local state**:

- Isolated components with minimal data dependencies.
- Simple, short-lived UI states, such as form inputs, toggles, or animations.

### Global state with context API

The React Context API is suitable for small to medium global state needs, such as user authentication or theme settings. It’s lightweight but can cause re-rendering issues if used improperly in large applications.

**Example of centralized authentication state**

```jsx
const AuthContext = React.createContext()

function AuthProvider({ children }) {
  const [user, setUser] = useState(null)

  const login = (userData) => setUser(userData)
  const logout = () => setUser(null)

  return <AuthContext.Provider value={{ user, login, logout }}>{children}</AuthContext.Provider>
}

function useAuth() {
  return useContext(AuthContext)
}

// Usage:
function Navbar() {
  const { user, logout } = useAuth()
  return user ? <button onClick={logout}>Logout</button> : <button>Login</button>
}
```

**When to use context API**:

- Lightweight global state, like theme, user, or language settings.
- Avoid for complex or frequently updated data, as it can lead to excessive re-renders.

### Redux or Zustand for complex global state

Redux is well-suited for applications with highly structured, complex, or cross-cutting state needs. It provides predictable state management via a single store and supports middleware for logging, async actions, and more. Alternatively, **Zustand** is a lightweight state management library that’s simpler to set up and more flexible than Redux.

**Example of global cart management with Redux Toolkit**

Using Redux Toolkit, you can simplify Redux by automatically generating action creators and reducers.

```js
import { createSlice, configureStore } from '@reduxjs/toolkit'

const cartSlice = createSlice({
  name: 'cart',
  initialState: [],
  reducers: {
    addItem: (state, action) => {
      state.push(action.payload)
    },
    removeItem: (state, action) => {
      return state.filter((item) => item.id !== action.payload)
    },
  },
})

const store = configureStore({ reducer: { cart: cartSlice.reducer } })

// Actions for dispatching:
export const { addItem, removeItem } = cartSlice.actions
export default store
```

**Redux vs. Zustand**:

- **Redux**: More verbose but provides structure, middleware support, and a strong ecosystem (dev tools, middleware for async actions).
- **Zustand**: Minimal boilerplate, straightforward API, and avoids creating a global Redux-like store by encouraging state encapsulation.

**When to use Redux or Zustand**:

- Cross-cutting data dependencies that multiple components need access to.
- Scenarios that benefit from immutability (Redux) or a reactive, hook-based approach (Zustand).

### Async data and server state with React Query or SWR

Tools like `React Query` and `SWR` are ideal for handling server data. They help manage caching, re-fetching, and synchronization with server data, which is particularly useful in data-intensive applications.

**Example use case**: React Query simplifies handling server state by caching data and re-fetching when necessary. It also manages states like loading, error, and refetching automatically.

```jsx
import { useQuery, QueryClient, QueryClientProvider } from 'react-query'

const queryClient = new QueryClient()

function fetchUser(userId) {
  return fetch(`/api/user/${userId}`).then((res) => res.json())
}

function UserProfile({ userId }) {
  const { data, error, isLoading } = useQuery(['user', userId], () => fetchUser(userId), {
    staleTime: 5 * 60 * 1000, // Data remains fresh for 5 minutes
  })

  if (isLoading) return <LoadingSpinner />
  if (error) return <ErrorDisplay message={error.message} />
  return <div>User: {data.name}</div>
}

// Usage in App:
;<QueryClientProvider client={queryClient}>
  <UserProfile userId={1} />
</QueryClientProvider>
```

**React Query vs. SWR**:

- **React Query**: More feature-rich and configurable; supports pagination, optimistic updates, and complex cache invalidation.
- **SWR**: Lightweight with a more declarative approach; suitable for simpler use cases.

**When to use React Query or SWR**:

- Server-side data that needs caching, synchronization, and refresh-on-focus.
- Use React Query for applications with complex server data dependencies and SWR for simpler needs.

### Combined approach with context + React Query

For scalable applications, a hybrid approach works well, where:

- Context handles small, rarely-changing global state (like theme or user settings).
- React Query or SWR manages server state (API data).
- Local state and custom hooks organize isolated or ephemeral component-specific state.

**Example hybrid structure**:

```jsx
const UserContext = React.createContext()

function AppProvider({ children }) {
  const [user, setUser] = useState(null)
  return <UserContext.Provider value={{ user, setUser }}>{children}</UserContext.Provider>
}

function useUserData(userId) {
  return useQuery(['user', userId], () => fetchUser(userId), { staleTime: 5 * 60 * 1000 })
}

function UserComponent() {
  const { user, setUser } = useContext(UserContext)
  const { data: userData } = useUserData(user.id)

  useEffect(() => {
    if (userData) setUser(userData)
  }, [userData, setUser])

  return <div>Welcome, {user ? user.name : 'Guest'}!</div>
}

// Usage:
;<AppProvider>
  <UserComponent />
</AppProvider>
```

**Benefits of the combined approach**:

- Avoids overloading context with complex state management.
- Improves separation of concerns by delegating responsibilities: local state for UI, context for global app state, and React Query for async/server state.

### Key takeaways

- **Local state** for isolated, ephemeral data.
- **Context API** for lightweight global state that rarely changes.
- **Redux/Zustand** for structured, complex state management across large applications.
- **React Query/SWR** for async data, caching, and server-side synchronization.
- **Combined approach** for scalable, maintainable architecture.


Discover state management strategies, best practices, and when to use each approach for scalable, efficient React applications

State management strategy

State management strategy in React


Testing is essential for ensuring that your code works as expected, is maintainable, and doesn't introduce bugs with future changes. React testing involves **unit tests, integration tests, and end-to-end (e2e) tests**, each targeting different aspects of your application's functionality.

Key testing strategies for React applications:

- **Unit testing** with Jest and React testing library
- **Integration testing** for component interactions
- **End-to-end (e2e) testing** with Cypress
- **Snapshot testing** for UI consistency

### Unit testing with Jest and React testing library

**Unit testing** focuses on testing individual components or functions in isolation, ensuring they work as expected independently of other parts of the application. **Jest** is a popular testing framework for JavaScript that's fast and powerful, while **React testing library** provides utilities to interact with and assert on component output based on how a user would interact with it.

#### Setting up Jest and React testing library

Install Jest and React testing library:

```sh
npm install --save-dev jest @testing-library/react
```

Add a basic test configuration in your `package.json`:

```js
{ "scripts": { "test": "jest" } }
```

#### Example unit test for a button component

Suppose we have a `Button` component that accepts a label and an onClick handler.

```js
// Button.js
export default function Button({ label, onClick }) {
  return <button onClick={onClick}>{label}</button>
}
```

**Unit test for button component:**

```jsx
// Button.test.js
import { render, screen, fireEvent } from '@testing-library/react'
import Button from './Button'

test('renders the button with a label', () => {
  render(<Button label="Click me" />)
  expect(screen.getByText('Click me')).toBeInTheDocument()
})

test('calls the onClick handler when clicked', () => {
  const handleClick = jest.fn()
  render(<Button label="Click me" onClick={handleClick} />)
  fireEvent.click(screen.getByText('Click me'))
  expect(handleClick).toHaveBeenCalledTimes(1)
})
```

Explanation:

- `screen.getByText("Click me")` selects the button by its text, simulating how a user would identify it.
- `fireEvent.click` simulates a click event, testing that `onClick` is called when expected.

**Benefits**:

- **Isolation**: Tests each component individually, ensuring independent functionality.
- **User-centric testing**: React testing library encourages testing from a user's perspective, improving test relevancy.

### Integration testing for component interactions

Integration tests verify that multiple components work together as expected. For instance, testing a form component with multiple fields and a submit button ensures that they interact correctly and trigger the proper behaviors.

#### Example: testing a form submission

Suppose we have a form component with name and email fields and a submit button.

```jsx
// Form.js
import { useState } from 'react'

export default function Form({ onSubmit }) {
  const [name, setName] = useState('')
  const [email, setEmail] = useState('')

  const handleSubmit = (e) => {
    e.preventDefault()
    onSubmit({ name, email })
  }

  return (
    <form onSubmit={handleSubmit}>
      <input placeholder="Name" value={name} onChange={(e) => setName(e.target.value)} />
      <input placeholder="Email" value={email} onChange={(e) => setEmail(e.target.value)} />
      <button type="submit">Submit</button>
    </form>
  )
}
```

**Integration test for form component:**

```jsx
// Form.test.js
import { render, screen, fireEvent } from '@testing-library/react'
import Form from './Form'

test('submits form with name and email', () => {
  const handleSubmit = jest.fn()
  render(<Form onSubmit={handleSubmit} />)

  fireEvent.change(screen.getByPlaceholderText('Name'), { target: { value: 'John' } })
  fireEvent.change(screen.getByPlaceholderText('Email'), { target: { value: 'john@example.com' } })
  fireEvent.click(screen.getByText('Submit'))

  expect(handleSubmit).toHaveBeenCalledWith({ name: 'John', email: 'john@example.com' })
})
```

Explanation:

- We simulate typing into both input fields, then trigger the form submission to ensure `onSubmit` is called with the correct data.

**Benefits**:

- **Interaction testing**: Validates that components interact correctly, ensuring data flows as expected.
- **Form and input testing**: Particularly useful for forms and multistep processes, verifying that all parts work in sequence.

### End-to-end (e2e) testing with Cypress

E2E tests simulate real user scenarios, covering the entire flow from start to finish, including interactions with the backend if needed. **Cypress** is a powerful tool for e2e testing in JavaScript applications, allowing for testing of full workflows across pages.

#### Setting up Cypress

Install Cypress:

```sh
npm install --save-dev cypress
```

Open Cypress for the first time:

```sh
npx cypress open
```

#### Example e2e test for a login flow

Suppose we have a login form where users enter an email and password to authenticate.

```jsx
// cypress/integration/login.spec.js
describe('Login Flow', () => {
  it('logs in a user with valid credentials', () => {
    cy.visit('/login')
    cy.get('input[name=email]').type('john@example.com')
    cy.get('input[name=password]').type('password123')
    cy.get('button[type=submit]').click()

    cy.url().should('include', '/dashboard')
    cy.contains('Welcome, John').should('be.visible')
  })
})
```

Explanation:

- **`cy.visit("/login")`** navigates to the login page.
- **Assertions** check that the login was successful by verifying the URL and checking for a welcome message.

**Benefits**:

- **Real user simulation**: Tests full workflows, covering real user interactions with the application.
- **Cross-page coverage**: Ensures that transitions between pages work as expected and user data is preserved.

### Snapshot testing for UI consistency

Snapshot tests capture the current state of a component's output (i.e., its rendered HTML) and compare it to a saved version. Snapshot testing is helpful for detecting unintended changes in the component's visual structure.

#### Snapshot testing with Jest

```jsx
// Header.test.js
import { render } from '@testing-library/react'
import Header from './Header'

test('renders the header correctly', () => {
  const { asFragment } = render(<Header title="Hello, World!" />)
  expect(asFragment()).toMatchSnapshot()
})
```

Explanation:

- `asFragment()` captures the component's current rendered state.
- `toMatchSnapshot()` checks the current output against a previously saved snapshot.

**Benefits**:

- **UI consistency**: Ensures that the UI remains visually consistent across updates.
- **Quick regression detection**: Quickly identifies changes to the component's structure, ideal for components with complex styles or markup.

**Limitations**:

- Snapshots can be too sensitive to minor changes, so they are best used for components with stable layouts or infrequent updates.

### Best practices for effective testing

- **Follow the testing pyramid**: Focus primarily on unit tests, followed by integration tests, and finally e2e tests. This balances test coverage with performance and maintainability.
- **Test from the user's perspective**: Use React testing library's queries like `getByText`, `getByRole`, and `getByLabelText` to mimic how users interact with your UI. Avoid testing internal implementation details, focusing on behavior instead.
- **Avoid overuse of snapshot tests**: Snapshot tests are helpful but can become brittle if overused. Use them selectively for components with complex or static UI.
- **Mock external dependencies**: For unit and integration tests, mock API calls, third-party libraries, and other dependencies to isolate the code under test. Libraries like **msw** (Mock Service Worker) can be used to mock API responses.
- **Run tests in CI/CD**: Automate tests in your CI/CD pipeline to catch bugs early in the development process. Run unit and integration tests for each commit and e2e tests periodically or before release.
- **Structure tests closely to source files**: Place each test file alongside its component or module. This structure makes it easy to locate and update tests when refactoring.

### Summary

Incorporating a comprehensive testing strategy helps ensure code quality, user experience, and long-term maintainability. Here's a quick summary:

- **Unit testing**: Focus on individual components and functions with Jest and React testing library.
- **Integration testing**: Test multiple components together, ensuring they work in harmony.
- **End-to-end testing**: Use Cypress to cover full workflows and user journeys, verifying app behavior across pages.
- **Snapshot testing**: Capture and compare UI structures, helpful for components with complex, static layouts.
- **Best practices**: Adopt the testing pyramid, test from the user's perspective, mock dependencies, and automate tests in CI/CD


React testing with unit, integration, and end-to-end approaches

Testing strategies

Testing strategies in React


React 18 was released in March 2022. This release focuses on performance improvements and updating the rendering engine.

## React 18 Feature Quick Guide

Now let's look at each of these updates in more detail.

## Concurrency in React

- Concurrency is not a feature, per se. It’s a new behind-the-scenes mechanism that enables React to prepare multiple versions of your UI at the same time.
- A key property of Concurrent React is that rendering is interruptible. React may start rendering an update, pause in the middle, then continue later. It may even abandon an in-progress render altogether.
- Another example is the reusable state. Concurrent React can remove sections of the UI from the screen, then add them back later while reusing the previous state.

## New React 18 Features

### Automatic Batching

- Batching is when React groups multiple state updates into a single re-render for better performance. For example, if you have two state updates inside of the same click event, React has always batched these into one re-render.

```plain_text
function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    setCount(c => c + 1); // Does not re-render yet
    setFlag(f => !f); // Does not re-render yet
    // React will only re-render once at the end (that's batching!)
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

```

- However, React wasn’t consistent about when it batches updates. For example, if you need to fetch data, and then update the state in the `handleClick` above, then React would not batch the updates, and perform two independent updates.
- Starting in React 18, all updates will be automatically batched, no matter where they originate from. This means that updates inside of timeouts, promises, native event handlers or any other event will batch the same way as updates inside of React events.

```plain_text
function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}

setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}, 1000);

fetch(/*...*/).then(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
})

```

### What if I don’t want to batch?

- You can use `ReactDOM.flushSync()` to opt out of batching:

```plain_text
import { flushSync } from 'react-dom'; // Note: react-dom, not react

function handleClick() {
  flushSync(() => {
    setCounter(c => c + 1);
  });
  // React has updated the DOM by now
  flushSync(() => {
    setFlag(f => !f);
  });
  // React has updated the DOM by now
}

```

## Transitions

- Transitions allow you to mark updates as transitions, which tells React that they can be interrupted and avoid going back to Suspense fallbacks for already visible content.

```plain_text
import {startTransition} from 'react';

// Urgent: Show what was typed
setInputValue(input);

// Mark any state updates inside as transitions
startTransition(() => {
  // Transition: Show the results
  setSearchQuery(input);
});

```

- Updates wrapped in startTransition are handled as non-urgent and will be interrupted if more urgent updates like clicks or key presses come in. If a transition gets interrupted by the user (for example, by typing multiple characters in a row), React will throw out the stale rendering work that wasn’t finished and render only the latest update.
- `useTransition`: a hook to start transitions, including a value to track the pending state.
- `startTransition`: a method to start transitions when the hook cannot be used.

## Suspense on the server

- Server-side rendering (abbreviated to “SSR” in this post) lets you generate HTML from React components on the server, and send that HTML to your users. SSR lets your users see the page’s content before your JavaScript bundle loads and runs. SSR in React always happens in several steps:
- On the server, fetch data for the entire app.
- Then, on the server, render the entire app to HTML and send it in the response.
- Then, on the client, load the JavaScript code for the entire app.
- Then, on the client, connect the JavaScript logic to the server-generated HTML for the entire app (this is “hydration”).
- The key part is that each step had to finish for the entire app at once before the next step could start. This is not efficient if some parts of your app are slower than others, as is the case in pretty much every non-trivial app.
- React 18 lets you use `<Suspense>` to break down your app into smaller independent units which will go through these steps independently from each other and won’t block the rest of the app. As a result, your app’s users will see the content sooner and be able to start interacting with it much faster. The slowest part of your app won’t drag down the parts that are fast. These improvements are automatic, and you don’t need to write any special coordination code for them to work.

## Strict mode

- Strict Mode is a tool that helps identify coding patterns that may cause problems when working with React, like impure renders.
- React 18 introduces a new development-only check to Strict Mode. This new check will automatically unmount and remount every component, whenever a component mounts for the first time, restoring the previous state on the second mount.
- Before this change, React would mount the component and create the effects:

```plain_text

* React mounts the component.
  * Layout effects are created.
  * Effects are created.

```

- With Strict Mode in React 18, React will simulate unmounting and remounting the component in development mode:

```plain_text

* React mounts the component.
  * Layout effects are created.
  * Effects are created.
* React simulates unmounting the component.
  * Layout effects are destroyed.
  * Effects are destroyed.
* React simulates mounting the component with the previous state.
  * Layout effects are created.
  * Effects are created.

```

## How to upgrade to React 18

- React 18 introduces a new root API which provides better ergonomics for managing roots. The new root API also enables the new concurrent renderer, which allows you to opt-into concurrent features.

```plain_text
// Before
import { render } from 'react-dom';
const container = document.getElementById('app');
render(<App tab="home" />, container);

// After
import { createRoot } from 'react-dom/client';
const container = document.getElementById('app');
const root = createRoot(container); // createRoot(container!) if you use TypeScript
root.render(<App tab="home" />);

```

## Conclusion

- In a summary, React 18 comes with a few breaking changes, depending on how you use it. But all in all, it also brings out-of-the-box performance improvements including batching more by default, which removes the need to manually batch updates in application or library code.
- Upgrading to React 18 should be straightforward, give it a try and let us know what you think.


React 18 was released in March 2022. This release focuses on performance improvements and updating the rendering engine.

React 18


## React Server Components, NextJs Route and Data Fetching

React Server Components (RSCs) offer the flexibility to decide where to render components based on their purpose, diverging from the client-side rendering approach of Single-Page Applications. By breaking down the page into smaller components, it becomes evident that many components are non-interactive and can be rendered on the server as Server Components. This can improve performance, reduce bundle size and also improve the initial page loading time.

### What are React Server Components?

- React Server Components are server-side components that facilitate seamless collaboration between server and Client Components (”use client”) for rendering React applications. RSCs are stateless components designed to run on the server, enhancing the transition between server-rendered content and client-side interactivity.
- RSCs also allow data fetching to be part of the component tree, using top-level await and server-side data serialization.
- RSCs prioritize server-side rendering and generate static content on the server.
- They use a protocol that lets the client request parts of the component tree from the server, enabling a hybrid of Single-Page Application (SPA) and Multi-Page Application (MPA) architectures.
- They depend on frameworks to implement them, and the React team expects them to become widely used and change the ecosystem.
- They also support async/await for data fetching and plan to add a “use()” hook for client-side data loading.

### Why Server Components?

Server Components make your app load faster and use less JavaScript. The base runtime is fixed and cacheable, and more JavaScript is only added when you need client-side interactivity with Client Components.

Next.js renders the initial HTML on the server and sends it to the browser. The browser then enhances the HTML with interactivity by loading the Next.js and React runtime asynchronously. This lets the client take over the app and handle user interactions.

## How to use Server Components in Next.js?

In the latest release of Next.js, they have introduced Server Components as essential requirements to be utilized in the construction of their single-page applications (SPAs).

To enhance code maintainability and readability, it is recommended to use the file naming convention of **`.server.(jsx|tsx)`** for Server components, and **`.client.(jsx|tsx)`** for Client components.

In Client components use the `use client` directive at the top of any file that contains client-side components or logic. This will mark the boundary between server-only and client.

![](assets/react-server-component_server-components-1.webp)

Here is an example of a simple RSC that fetches some data from a database and renders it on the server:

```jsx
// app/Greeting.server.js
import db from './db'

export default function Greeting({ name }) {
  // Fetch data from the database on the server
  const message = db.getGreeting(name)

  // Return a plain object with the data
  return { message }
}
```

And here is how you can use it in your client-side component:

```jsx
// app/Homepage.client.js
'use client' // Mark this file as client-only
import Greeting from './Greeting.server' // Import the RSC

export default function Homepage() {
  // Use the RSC as a regular component
  return (
    <div>
      <h1>Welcome to Next.js!</h1>
      <Greeting name="Alice" /> // Render the RSC
    </div>
  )
}
```

![](assets/react-server-component_server-components-2.webp)

`use client` marks the transition from server-only to client code. It goes at the top of a file, before any imports, to indicate that everything below it belongs to the client bundle. This includes any modules or components that are imported in the file.

Server Components are incompatible with custom hooks that use state, effects, or browser-only APIs.

## What are the benefits of using Server Components with Next.js?

Using RSC with Next.js can bring several benefits to your application, such as:

- Improved performance: reduce the amount of data that needs to be transferred between the server and the client, as well as the amount of code that needs to be parsed and executed on the client. This can result in faster page loads and better user experience.
- Reduced bundle size: this allows you to move large dependencies or logic that are only needed on the server to RSC files, which are not included in the client bundle. This can reduce the size of your client-side code and improve performance and caching.
- Simplified data fetching: eliminate the need for using APIs or fetching data on the client for some parts of your application via access directly to backend resources. This can simplify your code, reduce dependencies complexity, errors and keep sensitive information on the backend.

### Pattern for using Server Components

- To optimize our component tree, we aim to relocate client components to the leaf nodes whenever feasible. Rather than designating the entire component as a client component, we extract the interactive logic and place it in a client-specific component, such as `<SearchBar />, <Input />...` and so on. Meanwhile, we maintain static components like `<Layout />, <List />...` as server components. This approach eliminates the need to transmit the entire JavaScript code for the layout to the client.
- Server and Client Components can be combined in the same component tree, which means:
  - On the server, React renders **all** Server Components **before** sending the result to the client.
  - On the client, React renders Client Components and *slots in* the rendered result of Server Components, merging the work done on the server and client.
- Importing Server Components in Client Components is **not supported**, so Server Components will treat as **Client Components.**

```jsx
'use client';

<ClientComponents>
  <ServerComponents>
</ClientComponents>
```

- We suggest passing Server Components as `children` props to Client Components and importing and nesting `<ClientComponent>` in a parent component. We can use this way for both libraries and context that only work on the client or was not added `use client` in their files.

```jsx
<ClientComponents>{children} // The children is Server Components</ClientComponents>
```

- Both Server and Client Components can share JavaScript modules, but this can cause security issues if some code with sensitive data that should only run on the server gets exposed to the client. To avoid this, we can use packages like `server-only` that keep the server-only code separate from the client code. We can use this package by importing `server-only` in any modules like this:

```jsx
import 'server-only'

export async function getData() {
  // Do get the data
}
```

### Server Components Data Fetching in Next.js

With the new features implemented to the `fetch` WebAPI and make the use of `async/await` in Server Components, now the `fetch` can provide us a higher performance on caching/revalidating fetched data and prevent memory caching duplicate requests.

Next.js caches the data from fetch requests by default. When Next.js renders a page on the server and comes across a fetch, it will look for the data in the cache first. If the data is there, it will use it. If not, it will fetch and store the data for later requests. Or we can use native `cache` function of react to manually cache the data if unable to use `fetch` WebAPI.

For revalidating the cache data, that the `fetch` API introduced two ways are:

- [Background revalidate](https://nextjs.org/docs/app/building-your-application/data-fetching/revalidating#background-revalidation) at a specific time interval
- On-Demand revalidate by using [revalidatePath](https://nextjs.org/docs/app/api-reference/functions/revalidatePath) (for app route) or [revalidateTag](https://nextjs.org/docs/app/api-reference/functions/revalidateTag) (the tag of the `fetch` request)

We can use the [Server Actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions) in handling actions in Client Components interactive actions by adding `use server` in the handling action:

```jsx
export default function Form() {
  async function handleSubmit() {
    'use server'
    // ...
  }

  async function submitPicture() {
    'use server'
    // ...
  }

  return (
    <form action={handleSubmit}>
      <input type="text" name="name" />
      <input type="image" formAction={submitImage} />
      <button type="submit">Submit</button>
    </form>
  )
}
```

If we don’t use `fetch` to cache the API on server code, we can still fetch data on the client side. We suggest using libraries like `SWR` or `React Query` with Client Components. Later, we’ll also be able to use React’s [use()](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching#use-in-client-components) hook to fetch data in Client Components.

If we planning to use `react-query` on the project, we can use the approach with [initialData](https://tanstack.com/query/v4/docs/react/guides/ssr#using-initialdata-2) in `useQuery` or [Hydrate](https://tanstack.com/query/v4/docs/react/guides/ssr#using-hydrate) .

## Conclusion

In summary, React Server Components (RSCs) provide a powerful way to render React applications by enabling collaboration between server and client components. They improve performance, reduce bundle size, and enhance initial page loading time. By breaking down the page into smaller components, non-interactive parts can be rendered on the server as Server Components, resulting in faster page loads and better user experience. RSCs in Next.js offer benefits such as improved performance, reduced bundle size, and simplified data fetching. Overall, RSCs offer developers a more efficient and seamless rendering experience for React applications.

## References

- [SSR | TanStack Query Docs](https://tanstack.com/query/v4/docs/react/guides/ssr#using-hydrate)
- [Getting Started | Next.js (nextjs.org)](https://nextjs.org/docs/getting-started/react-essentials)
- [Introducing Zero-Bundle-Size React Server Components – React](https://react.dev/blog/2020/12/21/data-fetching-with-react-server-components)


React Server Components (RSCs) offer the flexibility to decide where to render components based on their purpose, diverging from the client-side rendering approach of Single-Page Applications.

React Server Components, NextJs Route and Data Fetching


A brief comparison between Remix and Next.js frameworks

## Introduction of Remix
Remix describes itself as:

> Remix is an edge native, full-stack JavaScript framework for building modern, fast, and resilient user experiences. It unifies the client and server with web standards so you can think less about code and more about your product.

Compared to Next.js, which is one of the most React frameworks used for server-side rendering and has been there for a significant time, Remix appears as a new strong competitor. Developers have started to wonder what the difference between these two frameworks is. 

In this post, we will mainly focus on Remix and highlight what makes it unique and where it shines the most.

## How is Remix different from Next.js?
### Page rendering strategies
Despite the same idea of creating websites that are rendered on the server before being sent to the client, Remix and Next.js go with distinct approaches.

Remix doesn't support Static Site Generation (SSG) but it suggests using HTTP stale-while-revalidate caching directive (SWR) as an alternative. The key here is that static routes are cached using a CDN. These routes are then served to users on each visit and automatically revalidated for the next visitor.

### Routing
Both Remix and Next.js follow a file-based routing system.

In Next.js, each file inside the `/pages` directory will be automatically set as a route. 

```javascript
pages/index.js ==> /
pages/users/index.js ==> /users
pages/users/create.js ==> /users/create
```

Remix also does the same but the route directory is `/app/routes`:

```javascript
app/routes/index.js ==> /
app/routes/users/index.js ==> /users
app/routes/users/create.js ==> /users/create
```

Built on top of React Router, Remix shines when it comes to nested routing. It comes with a very powerful route nesting mechanism that can put one or many routes inside another route and those act like children components that can be mounted and unmounted depending on the active URL path. We need to use an Outlet component to render the route hierarchy from the parent routes.

Next.js, on the other hand, comes with its own router and has support for routes nesting but it’s not so easy to do so compared to Remix.

### Data Loading
Next.js supports different ways for loading data on the server-side like `getServerSideProps` and `getStaticProps` based on the type of web app.

Remix has a new concept with two portions:

* `loader` function - used to load data in a component, and a supplementary
* `useLoaderData hook` - used to get access to the data returned by the `loader` function

```javascript
import { useLoaderData } from "remix";

export const loader = () => {
  // fetch data from database or make API calls
  return {data}
};

export default function App() {
 // get access to data
  let {data} = useLoaderData();

  return (
    <div>
      <p>Use Data in component {data}</h1>
    </div>
  );
}
```

### Data Mutation
Next.js doesn't do anything for mutations. Basically, we would have to handle everything from creating a form, fetching data, managing state, adding event handlers, to finally dealing with errors, interruptions, and race conditions.

Data mutations in Remix are built on top of two fundamental web APIs: `<form>` and HTTP. All we have to do is to use a `<Form>` component (works identically to `<form>` with a couple of extra goodies for optimistic UI etc.) and a route function named `action`. When the user submits a form, Remix with call the action for the form and reload all of the data on the page. This ensures that any updates to the data are reflected in the UI.

```javascript
export const action = async ({ request }) => {
  const form = await request.formData()
  const content = form.get('content')
  return redirect('/')
}

export default function App() {
  return (
    <div>
      <Form method="POST">
        <label htmlFor="content">
          Content: <textarea name="content" />
        </label>
        <input type="submit" value="Add New" />
      </Form>
    </div>
  )
}
```

### Error Handling
Next.js define some custom pages for certain status errors like 404 or 500 errors. However, some errors around data and rendering are not supported.

Remix has an error boundary for handling errors. When we create a route component, we can also define an error boundary for catching any errors that occur in the route component. It likes having two components in a route file, with one being the actual route component and one being the fallback when errors happen in the former. One noteworthy thing is when there is an error in a nested component route and this route has no error boundary, the error bubbles up the nested tree until caught by a parent’s error boundary.

![](assets/remix-versus-nextjs_a7d49c4d71418c892f72a5c2a7dbee19_md5.webp)

## Conclusion
For React developers, Next.js is obviously the prior choice when it comes to server-side rendering for its familiar concepts and larger community. Has been around for a while, it seems like a steady pedestal and is not easy to be replaced in a short period.

Even so, Remix looks like a shiny new thing. It also provides a higher level of abstraction. Routing system might be confusing but it is a remarkable feature too. Other built-in features such as data loading, data mutations, error boundary, etc. actually improve the developer experience.

Overall, Remix is a new framework, and it will definitely become more powerful and widespread in the future.


A brief comparison between Remix and Next.js frameworks

Remix Versus Nextjs


![](assets/remove-unused-css-styles-from-bootstrap-using-purgecss_50067f1125ee42d2d68068bd93443235_md5.webp)

## Introduction

Reducing assets size is one of the most practical ways to speed up your web application. I have a simple use case, lets imagine your HTML file looks like this

```javascript
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <title>Bootstrap</title>

  <link rel="stylesheet" href="./bootstrap-grid.min.css" />
</head>
<body>
  <div class="row">
    <div class="col-sm-4">.col-sm-4</div>
    <div class="col-sm-4">.col-sm-4</div>
    <div class="col-sm-4">.col-sm-4</div>
  </div>
</body>
</html>
```

Now look at

```javascript
bootstrap - grid.min.css
```

![](assets/remove-unused-css-styles-from-bootstrap-using-purgecss_50067f1125ee42d2d68068bd93443235_md5.webp)

Quite huge isn’t it? Thanks to PurgeCss here is the CSS file after being purged will only contain parts of the CSS file (only used selectors), as you can see horizontal scrollbar is not very long:

## Usage

PurgeCSS can be installed with npm package

```javascript
npm i --save-dev purgecss
```

Basically, you run it against your CSS files and your HTML/JavaScript files. It will parse and analyze which CSS content will be used and remove unused CSS content.

PurgeCSS can be used as a CLI. This is our project structure, we gonna need to transform CSS files so we have to download bootstrap distro and get file we want to transform.

![](assets/remove-unused-css-styles-from-bootstrap-using-purgecss_a903c03602f38038a2c4e4eb4344e0b9_md5.webp)

CLI command syntax

`purgecss --css <css file> --content <content file to parse css> --out <output-directory>`

Since Purgecss is installed in `/node_modules\` we must run this command through npm script. We use `--out dist` option to store output CSS files in dist folder after transformed. Now change the path of `bootstrap-grid.min.css` in `index.html` to:

`<link rel="stylesheet" href="./dist/bootstrap-grid.min.css" />`

Then create npm script to run purgecss

```javascript
{
  "name": "PurgeCSS",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "devDependencies": {
    "webpack": "^4.29.0"
  },
  "scripts": {
    "build": "purgecss --css bootstrap-grid.min.css --content index.html --out dist/"
  }
}
```

Then run npm run build, you should see new bootstrap-grid.min.css in dist folder with unused CSS content being removed

![](assets/remove-unused-css-styles-from-bootstrap-using-purgecss_04ee21f4b60188ce76c21df96695e6cf_md5.webp)

![](assets/remove-unused-css-styles-from-bootstrap-using-purgecss_dd640e027b4421ee74d88c2864f0c9ed_md5.webp)

You can view full CLI options at [https://www.purgecss.com/cli\](https://www.purgecss.com/cli%5C)

Example repository: [https://github.com/PhmNgocNghia/purge\-css\-demo\-cli\](https://github.com/PhmNgocNghia/purge%5C-css%5C-demo%5C-cli%5C)

## Setup using Webpack

Purge CSS can be used together with built tools such as webpack, gulp, grunt,… etc. You can view it’s documentation at [https://www.purgecss.com/\](https://www.purgecss.com/%5C)

I’m going to demonstrate how to integrate with Webpack. This is my simple project which integrate project and Webpack

```javascript
var UglifyJsPlugin = require('uglifyjs-webpack-plugin')
var HtmlWebpackPlugin = require('html-webpack-plugin')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')

module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    filename: '[name].js',
    path: __dirname + '/dist',
  },
  module: {
    rules: [
      // javascript = babel + uglify
      {
        test: /\.m?js$/,
        exclude: /(node_modules|bower_components)/,
        use: [{ loader: 'babel-loader' }],
      },

      // css file: extract to css file with mini extract plugin
      {
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, 'css-loader'],
      },
    ],
  },

  // uglifyjs
  optimization: {
    minimizer: [new UglifyJsPlugin()],
  },

  // plugin
  plugins: [
    new HtmlWebpackPlugin({
      template: './index.html',
    }),
    new MiniCssExtractPlugin({
      filename: '[name].css',
      chunkFilename: '[id].css',
    }),
  ],
}
```

In my index.js file, I simply import bootstrap grid CSS.

`// Import CSS Grid min CSS`

`import 'bootstrap/dist/css/bootstrap-grid.min.css'`

Here is the build output which includes CSS grid file

![](assets/remove-unused-css-styles-from-bootstrap-using-purgecss_429bb8c82f4e38465293c6f79d782394_md5.webp)

To use PurgeCss with Webpack simply install this Webpack plugin: `npm i purgecss-webpack-plugin -D`

Then add it to plugin section in Webpack config file

```javascript
var UglifyJsPlugin = require('uglifyjs-webpack-plugin')
var HtmlWebpackPlugin = require('html-webpack-plugin')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
const PurgecssPlugin = require('purgecss-webpack-plugin')
const glob = require('glob')
const path = require('path')

module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    filename: '[name].js',
    path: __dirname + '/dist',
  },
  module: {
    rules: [
      // javascript = babel + uglify
      {
        test: /\.m?js$/,
        exclude: /(node_modules|bower_components)/,
        use: [{ loader: 'babel-loader' }],
      },

      // css file: extract to css file with mini extract plugin
      {
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, 'css-loader'],
      },
    ],
  },

  // uglifyjs
  optimization: {
    minimizer: [new UglifyJsPlugin()],
  },

  // plugin
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html',
    }),
    new MiniCssExtractPlugin({
      filename: '[name].css',
      chunkFilename: '[id].css',
    }),
    new PurgecssPlugin({
      paths: glob.sync(`${path.join(__dirname, 'src')}/**/*`, { nodir: true }),
    }),
  ],
}
```

![](assets/remove-unused-css-styles-from-bootstrap-using-purgecss_97c7bfa1adf49d7c225f00976d99eb8c_md5.webp)

Full example repository: [https://github.com/PhmNgocNghia/purge\-css\-example\-webpack\](https://github.com/PhmNgocNghia/purge%5C-css%5C-example%5C-webpack%5C)

## Conclusion

With PurgeCSS, our `bootstrap-grid.main.css` file reduce from **47kb** to **601byte**. All unused selectors has been removed. You can view the documentation at [https://www.purgecss.com/\](https://www.purgecss.com/%5C) which contain details instruction and api references.

Not only bootstrap, you can use PurgeCSS with many css libraries such as TailwindCSS, Zurb foundation,... etc.


This article demonstrates how to use PurgeCSS to remove unused CSS styles from Bootstrap.

Remove Unused CSS Styles From Bootstrap Using Purgecss


Data-fetching libraries are software tools or frameworks that can help improve the performance and scalability of your application by handling network requests and data processing more efficiently. In React, one of the key challenges these libraries address is optimizing rendering to avoid unnecessary re-rendering of components when the underlying data remains unchanged. This helps to prevent situations where components re-render multiple times despite no changes in the data, resulting in improved efficiency and smoother user experiences.

Let's dive in how it works.

## Deduplication

Data-fetching libraries typically use caching strategies to reduce the number of network requests that need to be made, and improve the performance of the application. By using a unique key as the identifier and stale-while-revalidate as cache validation, the library will return responses from cached data or make a network request.

![](assets/render-optimization-in-data-fetching-libraries_render-optimization-in-data-fetching-1.webp)

## Data selection

Everytime a request is sent, the corresponding components will be updated by 3 very common stateful values:

```json
{ data, error, fetching }
```

Look at `fetching`, this flag is quite useful if you want to display a loading indicator. But it's also kinda unnecessary if you don't do that. Then your component will render twice even though nothing changed in data because this flag is always true when a request is in-flight and otherwise. Unexpected render happens when a hook request is used like:

```js
const data = useRequest(...)
```

For this use-case, most libraries is designed to notify on what properties are using in component only. So it's recommended to use destructuring instead:

```js
const { data, error } = useRequest(...)
```

## Structural sharing

Structural sharing is the most advance feature that can optimize rendering over data selection. One of the data-fetching libraries has turned on out of the box is [React Query](https://tanstack.com/query/latest/). To use this feature, makes sure your data is kept referential identity on every level. As an example, suppose we have the following data structure:

```json
[
  { "id": 1, "name": "Learn React", "status": "active" },
  { "id": 2, "name": "Learn React Query", "status": "todo" }
]
```

Now suppose first todo is changed into the *done* state:

```diff
[
- { "id": 1, "name": "Learn React", "status": "active" },
+ { "id": 1, "name": "Learn React", "status": "done" },
 { "id": 2, "name": "Learn React Query", "status": "todo" }
]
```

Structural sharing will attempt to compare the old state and the new and keep as much of the previous state as possible.

This comes in very handy when using selectors for partial subscriptions:

```js
// ✅ will only re-render if _something_ within todo with id:2 changes
// thanks to structural sharing
const { data } = useTodo(2)
```

In some instances, especially when having very large datasets, structural sharing *can* be a bottleneck. Let's use it carefully.

## References

- https://tkdodo.eu/blog/react-query-render-optimizations
- https://nextjs.org/docs/app/building-your-application/data-fetching
- https://swr.vercel.app/docs/advanced/performance
- https://tanstack.com/query/latest/docs/react/guides/caching


Data-fetching libraries are software tools or frameworks that can help improve the performance and scalability of your application by handling network requests and data processing more efficiently.

Render optimization in data-fetching libraries


A comprehensive August 2024 update on key advancements in React 19, Next.js 15, and web development tools. Highlights include new async transitions, server components, SSR performance comparisons, and emerging technologies in the web development landscape.

## React

### [React 19 RC: Async Transitions, Server Components, and Optimistic Updates](https://react.dev/blog/2024/04/25/react-19#whats-new-in-react-19)

React 19 introduces async transitions through Actions, improved error handling for hydration, and new hooks like `useOptimistic` for managing state. It enhances support for Server Components, integrates async scripts and resource preloading, and offers better tools for managing form submissions.

### [An SSR Performance Showdown](https://blog.platformatic.dev/ssr-performance-showdown)

This article compares the Server-Side Rendering (SSR) performance of major frontend libraries, including React, Vue, Svelte, Solid, and Preact, using Fastify. Vue led in performance, closely followed by Svelte and Solid, with React and Preact falling behind.

### [Essential React Libraries for 2024](https://www.robinwieruch.de/react-libraries/)

A handy guide to the best React libraries you should consider in 2024. It covers everything from state management tools like Zustand, to UI components like Tailwind CSS, and data-fetching libraries like TanStack Query. It’s all about streamlining your development and optimize performance with the latest trends in React.

### Quick Links

- [Build your own React state management library in under 40 lines of code](https://paripsky.github.io/blog/build-your-own-react-state-management/)
- [Managing Effects in React](https://ui.dev/c/react/effects): Understanding `useEffect`
- [Interface Segregation Principle in React](https://alexkondov.com/interface-segregation-principle-in-react/)
- [Everything About Google Translate Crashing React](https://martijnhols.nl/gists/everything-about-google-translate-crashing-react)
- [Implementing React from Scratch](https://www.rob.directory/blog/react-from-scratch)

## Next.js

### [Next.js 15 RC - Now Supporting React 19 RC](https://www.syncfusion.com/blogs/post/whats-new-in-next-js-15-rc/amp)

Next.js 15 brings support for React 19 RC, along with better hydration error handling, caching improvements, and experimental features like the React Compiler and Partial Prerendering, allowing for incremental static and dynamic rendering.

### [Build Anything with v0 (3D Games, Interactive Apps)](https://www.youtube.com/watch?v=zA-eCGFBXjM)

A quick introduction to the new version of V0, showcasing its ability to create interactive apps and games.

### Quick Links

- [Vercel AI SDK 3.3](https://vercel.com/blog/vercel-ai-sdk-3-3)
- [Next.js + Supabase App in Production: Lessons Learned](https://catjam.fi/articles/next-supabase-what-do-differently)

## Others

### [State of CSS 2024 Is Now Open!](https://survey.devographics.com/en-US/survey/state-of-css/2024)

Want to calculate a square root or cosine in your CSS? Use that to build scroll-triggered animations? And maybe scope all of it down so it doesn't have any unwanted effects? Now you can do all that, and much more! This is an interesting survey to share your experiences and thoughts on the current trends in CSS.

### [JS Dates Are About to Be Fixed](https://docs.timetime.in/blog/js-dates-finally-fixed)

The [Temporal proposal](https://github.com/tc39/proposal-temporal) promises to simplify time zone handling, fix issues with UTC and local times, and add features like daylight saving time management and easy date comparisons.

### [MUI v6 Is Out!](https://mui.com/blog/material-ui-v6-is-out/)

MUI v6 introduces CSS theme variables, container queries, and performance improvements. The update reduces package size, stabilizes Grid v2, and introduces experimental features like Pigment CSS and React Server Components, fully compatible with React 19.

### Quick Links

- [Common Causes of Memory Leaks in JavaScript](https://www.trevorlasn.com/blog/common-causes-of-memory-leaks-in-javascript)
- [CSS Grid Areas: A Fresh Look](https://ishadeed.com/article/css-grid-area/)
- [Front-End Security Checklist](https://www.trevorlasn.com/blog/frontend-security-checklist)
- [When Regex Goes Wrong](https://www.trevorlasn.com/blog/when-regex-goes-wrong)
- [Why CSS-in-JS Can Be Slow](https://playfulprogramming.com/posts/why-is-css-in-js-slow)
- [Announcing TypeScript 5.6 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-rc/)

## Trending

### [Top Programming Languages 2024: Typescript and Rust on the Rise](https://spectrum.ieee.org/top-programming-languages-2024)

Python reigns in AI and education, while SQL remains crucial for employers. Typescript's static typing increases reliability, and Rust's memory safety gains it a solid following. Meanwhile, C is declining, but legacy languages like Fortran and Cobol persist in niche areas.

### [e18e: Improving JS Performance One Package at a Time](https://e18e.dev/?ck_subscriber_id=2328911063)

e18e is a community project focused on cleaning up outdated dependencies, speeding up widely-used JavaScript packages, and leveling up the ecosystem with modern alternatives.

### [Introducing InformAI: Let Your LLMs See What Your Users See](https://edspencer.net/2024/8/26/introducing-inform-ai)

InformAI allows developers to expose UI and component data to large language models (LLMs) with a few lines of code, enabling smarter AI responses based on app state.

### Quick Links

- [Say No to console.log!](https://dev.to/alishgiri/say-no-to-consolelog-556n): Explore alternatives to `console.log`
- [Structured Outputs in the OpenAI API](https://openai.com/index/introducing-structured-outputs-in-the-api/)
- [GitHub Models: A New Generation of AI Engineers](https://github.blog/news-insights/product-news/introducing-github-models/)

## New Tools

### [Waku: Making React Development Fun Again](https://waku.gg/)

Waku offers a lightweight, fun alternative for React development in the server components era.

### [Formity: Build Complex, Multi-Step Forms with JSON](https://www.formity.app/)

Formity makes building dynamic, customizable forms easy by defining them with JSON. It simplifies complex form development with conditions, loops, variables, and operators.

### [Rspack 1.0: A High-Performance JavaScript Bundler](https://rspack.dev/blog/announcing-1-0)

Rspack 1.0, built in Rust, delivers significant performance improvements over webpack, offering compatibility with its ecosystem while being up to 10 times faster. It introduces key features such as better bundle size optimization, support for Module Federation 2.0, and stable APIs, with growing adoption from enterprises like ByteDance, Microsoft, and Amazon.

### Quick Links

- [Coolify: Open-Source Heroku/Netlify Alternative](https://coolify.io/)
- [Web Vitals Chrome Extension](https://chromewebstore.google.com/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma)
- [React Email 3.0](https://resend.com/blog/react-email-3)

## Commentary

- [It’s Time to Talk About “CSS5”](https://www.smashingmagazine.com/2024/08/time-to-talk-about-css5/)
- [Microfrontends Should Be Your Last Resort](https://www.breck-mckye.com/blog/2023/05/Microfrontends-should-be-your-last-resort)
- [Japanese Web Design: Weird, But It Works](https://www.youtube.com/watch?v=vi8pyS076a8)
- [Practices of Reliable Software Design](https://two-wrongs.com/practices-of-reliable-software-design)
- [Why Micro-Libraries Should Die](https://bvisness.me/microlibraries)
- [The Secret Behind One Million Checkboxes](https://eieio.games/essays/the-secret-in-one-million-checkboxes)
- [Is Tailwind CSS Too Redundant?](https://www.reddit.com/r/webdev/comments/1f2abca/anyone_else_find_tailwind_css_a_bit_too_redundant/)
- [React: Is It Time to Move On?](https://www.youtube.com/watch?v=0tvfC9r9lcw)


A comprehensive August 2024 update on key advancements in React 19, Next.js 15, and web development tools. Highlights include new async transitions, server components, SSR performance comparisons, and emerging technologies in the web development landscape

August 2024

Frontend Report August 2024


## React

### [CRA is officially dead - here's what to use now](https://syntackle.com/blog/create-react-app-deprecated)

React finally pulled the plug on Create React App. After years without updates, CRA's strict setup and old Webpack system became a pain for developers. Try Vite for super-fast builds or Next.js if you need server rendering.

### [React Context: The hidden performance problem](https://tigerabrodi.blog/was-react-context-a-mistake)

That simple Context Provider might be slowing down your app. Context causes too many re-renders across your app. Break large contexts into smaller ones or try state libraries like Jotai or Zustand for better control over what updates when.

### [Understanding React Server Components: Under the hood](https://tonyalicea.dev/blog/understanding-react-server-components/)

This guide breaks down how React Server Components actually work! Learn why they're different from regular components, how the `Flight` format streams data to your browser, and why the `double data problem` matters. Plus, see which React features work server-side and which don't.

### [React Query's downsides no one talks about](https://tkdodo.eu/blog/react-query-the-bad-parts)

Everyone loves React Query, but it has trade-offs worth knowing. The file size is big, its approach can make code harder to follow, and its cache system adds complexity.

### Quick links

- [17 tips from a senior React developer](https://www.frontendjoy.com/p/17-tips-from-a-senior-react-developer)
- [We replaced our React frontend with Go and WebAssembly](https://dagger.io/blog/replaced-react-with-go)
- [React UI component libraries in 2025](https://www.builder.io/blog/react-component-library)

## Next.js

### [Vercel's Fluid Compute: Making AI apps 85% cheaper](https://www.youtube.com/watch?v=itSu3T1zJew)

Vercel's new feature packs multiple requests into single functions - cutting AI costs by up to 85%. Fluid Compute replaces Edge functions with full Node.js support while staying fast. It's the perfect middle ground between serverless and traditional servers.

### [Build a Next.js login page with session-based authentication](https://clerk.com/blog/building-a-nextjs-login-page-template)

This guide shows you how to implement session-based authentication in a Next.js application, including essential aspects such as database schema design, backend security measures (password hashing and session ID verification), and frontend user interface considerations (sign-up/sign-in forms).

### [Next.js 15's better error handling stops your site from crashing](https://devanddeliver.com/blog/frontend/next-js-15-error-handling-best-practices-for-code-and-routes)

Next.js 15 gives you better control over errors with special files - `error.tsx` for component problems, `global-error.tsx` for big issues, and `not-found.tsx` for missing pages. ErrorBoundary components keep errors contained while the useActionState hook handles server actions smoothly.

### Quick links

- [Make your Next.JS Docker images tiny!](https://xeiaso.net/notes/2024/small-nextjs-images/)
- [Next.js composable caching makes sites faster](https://nextjs.org/blog/composable-caching)

## Others

### [Double-keyed caching: The privacy update slowing down your site](https://addyosmani.com/blog/double-keyed-caching)

Browsers now use both URL and website to split cache storage - good for privacy, bad for speed. This security change affects CDNs, third-party resources, and shared assets. See how it impacts your site and what changes you need to make.

### [Simple tricks to make your sites work for everyone](https://martijnhols.nl/blog/accessibility-essentials-every-front-end-developer-should-know)

Stop putting accessibility last. This guide gives practical tips on using proper HTML, building forms correctly (don't rely on placeholders!), and handling focus in popups. These easy changes make your site usable for everyone while helping SEO and user experience.

## [Speed up your website with these simple tricks](https://syntax.fm/show/874/fast-apps-easy-perf-wins)

Optimize images, shrink code, and use Gzip to make your files smaller. Smart caching and CDNs help global users see your site faster. Use Chrome's tools to find what's slowing you down, and don't forget CSS tricks like putting critical styles directly in the HTML and using system fonts.

### Quick links

- [A poor Lighthouse score doesn't always mean your site is slow](https://www.debugbear.com/blog/poor-performance-score-good-performance)
- [Mistakes in the design of CSS](https://wiki.csswg.org/ideas/mistakes)

## Trending

### [5 technical JavaScript trends you need to know about in 2025](https://risingstars.js.org/2024/en)

Serverless is going mainstream with edge functions leading the way. WebAssembly is finding its place for speed-critical features. Microfrontends with Webpack Module Federation help big teams work better, while state management keeps moving toward smaller, focused solutions.

### [What 7,800+ developers say about React in 2024](https://2024.stateofreact.com)

The biggest React survey ever shows the pain points React 19 needs to fix - especially forwardRef and memo. While React itself stabilizes, the tools around it keep changing fast. TanStack Start is becoming a strong Next.js alternative with growing adoption.

### [Interop 2025 makes the web better](https://web.dev/blog/interop-2025)

`Interop` is an annual meeting where browser makers (Chrome, Safari, Firefox, Edge) agree on which web features to make work the same across all browsers. After hitting 95% compatibility in 2024, they've picked 19 new areas to fix in 2025. Top priorities include CSS Zoom standards, WebRTC security, and mobile testing.

### Quick links

- [The success of Interop 2024!](https://webkit.org/blog/16413/the-success-of-interop-2024/)
- [Which rich text editor should you choose in 2025?](https://liveblocks.io/blog/which-rich-text-editor-framework-should-you-choose-in-2025)

## Tools

### [React Scan: Find slow components without changing your code](https://react-scan.com/)

React Scan spots React performance problems without adding any code. Unlike other tools that need special setup, React Scan visually shows problem components and suggests clear fixes - all through a simple, easy-to-use interface.

### [Nue: The framework that cuts JavaScript bloat](https://nuejs.org/blog/standards-first-web-framework)

Tired of complex JavaScript frameworks? Nue goes back to web basics with HTML, Markdown and modern CSS. It helps designers and developers work better together while reducing technical debt.

### [Standard Schema: The Zod alternative everyone's switching to](https://www.youtube.com/watch?v=V1vMaNVwTaI)

Zod has problems: it's slow, causes TypeScript to lag, and doesn't fully follow standards. Standard Schema fixes these issues while letting you use any validator you want. No more multiple validation libraries - just one flexible system that actually performs well.

### Quick links

- [Learn Yjs: Interactive tutorials](https://learn.yjs.dev/)
- [State management libraries in the React compiler era](https://blog.axlight.com/posts/thoughts-on-state-management-libraries-in-the-react-compiler-era/)
- [bippy: Hack into react internals](https://www.bippy.dev/)
- [CSS Variables editor](https://www.cssvariables.com/)

## Commentary

- [Server-side renaissance: A year without React](https://kellysutton.com/2025/01/18/moving-on-from-react-a-year-later.html)
- [Why developers hate linters?](https://www.coderabbit.ai/blog/why-developers-hate-linters)
- [Will AI eat the browser?](https://crazystupidtech.com/archive/will-ai-eat-the-browser/)
- [HTML is actually a programming language. Fight me](https://www.wired.com/story/html-is-actually-a-programming-language-fight-me/)


Our February 2025 report covers what's new in frontend development - from React's move away from Create React App to Next.js improvements, browser compatibility updates, and cool new tools like React Scan. Get practical tips for better auth, faster websites, and making your sites work for everyone.

February 2025

Frontend Report February 2025


This report provides a detailed look at the significant developments in frontend development during the first half of November 2024. It covers the latest updates, tools, and approaches shaping the frontend scene, including React 19's full-stack features, XState for managing state, Shopify's move to React Native, improvements in Next.js 15, and how container queries impact responsive design.

## React

### [TanStack Start: Challenging Next.js](https://bobaekang.com/blog/two-ways-to-the-two-reacts/)

TanStack Start is emerging as a formidable competitor to Next.js, focusing on its client-first approach, while providing a full-featured server-side capable system, which contrasts with Next.js's server-first model.

### [XState in React: Streamlining state management for complex UIs](https://www.frontendundefined.com/posts/monthly/xstate-in-react/)

Dive into the power of XState in React applications. Learn how this state machine library simplifies handling complex state logic, enhances UI reliability, and integrates seamlessly with React for predictable and scalable state management.

### [Shopify’s React Native migration success story](https://threadreaderapp.com/thread/1853619638141071573.html)

Shopify overhauled its decade-old mobile app using React Native, reducing 1.8M lines of code and achieving faster load times (44% faster), better performance, and higher user ratings.

### Quick links

- [Seamless React upgrades in micro-frontends](https://alexocallaghan.com/upgrading-react-with-microfrontends)
- [React Navigation 7: Enhanced developer experience and powerful new features](https://reactnavigation.org/blog/2024/11/06/react-navigation-7.0/)

## Next.js

### [Exploring Next.js 15: What's new and why it's better than ever](https://aviral-blogs.hashnode.dev/exploring-nextjs-15-whats-new-and-why-its-better-than-ever)

Next.js 15 enhances build speed, improves developer experience, and adds new features like full support for React Server Components and expanded App Router functionality. It also improves image optimization with dynamic resizing and global caching. 

### [Advanced search param filtering](https://aurorascharff.no/posts/managing-advanced-search-param-filtering-next-app-router/)

Comprehensive guide on implementing search parameter filtering using App Router with startTransition and useOptimistic.

### Quick links

- [Vercel simplifies Next.js self-hosting](https://thenewstack.io/vercel-makes-changes-to-next-js-to-simplify-self-hosting/)
- [Integrating WordPress as a headless CMS with React or Next.js](https://scientyficworld.org/how-to-deploy-headless-wordpress-with-next-js/)

## Others

### [Why frameworks outperform Web components: A deep dive into key drawbacks](https://www.youtube.com/watch?v=UrS61kn4gKI)

Explore the fundamental limitations of Web Components compared to modern frameworks like React, including issues with state management, integration challenges, server-side rendering, and real-world adoption. Understand why frameworks remain the practical choice for developers today.

### [Enhancing web design with Container queries and the Containment API](https://www.joshwcomeau.com/css/container-queries-introduction/)

Container queries enable responsive design by allowing elements to adjust based on their parent’s size. With widespread browser support, these tools promise to transform design practices, and the author will share practical examples in a future post.

### Quick links

- [Browser rendering process](https://abhisaha.com/blog/exploring-browser-rendering-process)
- [HTML login form best practices](https://evilmartians.com/chronicles/html-best-practices-for-login-and-signup-forms)

## Trending


### [TanStack Start: A Full-Stack React framework for modern web apps](https://tanstack.com/start/latest)

TanStack Start is a powerful full-stack React framework featuring type-safe APIs, robust routing, full-document SSR, streaming, and server functions—perfect for building modern, scalable web applications.

### [How Recall.ai Cut AWS Costs by $1M with Shared Memory Optimization](https://www.recall.ai/post/how-websockets-cost-us-1m-on-our-aws-bill)

Recall.ai reduced AWS costs by $1M annually and cut CPU usage by 50% by leveraging Shared Memory for direct access between processes, eliminating the need for data copying.

### Quick links

- [GitHub Copilot Supercharged: Beyond autocomplete](https://github.blog/news-insights/product-news/universe-2024-previews-releases/)

## New Tools

### [HTML to React Chrome extension](https://chromewebstore.google.com/detail/html-to-react-figma-by-ma/chgehghmhgihgmpmdjpolhkcnhkokdfp)

Browser extension for converting HTML snippets to React or Figma.

### [Streamlining Frontend testing with Storybook Test](https://storybook.js.org/blog/storybook-test-sneak-peek/)

Storybook Test revolutionizes frontend testing by integrating component, visual, and accessibility tests into one workflow, delivering fast, browser-based results. Developers are invited to shape this game-changing tool through the early access program.

### Quick links

- [Docusaurus 3.6: Docs made easy & fast!](https://docusaurus.io/blog/releases/3.6)

## Commentary

- [Why a perfect Lighthouse score isn't everything](https://www.smashingmagazine.com/2024/11/why-optimizing-lighthouse-score-not-enough-fast-website/)
- [Headless components](https://www.subframe.com/blog/how-headless-components-became-the-future-for-building-ui-libraries)
- [State of CSS survey analysis](https://www.oddbird.net/2024/11/04/css-demographics/)


A comprehensive update on key advancements in frontend development for the first half of November 2024, highlighting React 19's full-stack capabilities, XState for state management, Shopify's React Native migration, Next.js 15 enhancements, and the impact of container queries on responsive design.

Nov 2024 (First Half)

Frontend Report First Half of November 2024


## React

### [React 19 is officially here](https://react.dev/blog/2024/12/05/react-19)

The moment we've all been waiting for! React 19 has officially landed. React 19 is here with game-changing features! Actions simplify state management with built-in handling for errors and optimistic updates. New hooks like useOptimistic and useActionState make development smoother than ever. Plus, enhanced Suspense boosts performance for better user experiences.

### [React 19: Ref callbacks - More than just DOM access](https://tkdodo.eu/blog/ref-callbacks-react-19-and-the-compiler)

Ref callbacks in React 19 can now return cleanup functions, similar to useEffect, allowing for tasks like measuring DOM nodes with ResizeObserver. 

### [View Transition API: Smooth animations coming to React](https://motion.dev/blog/reacts-experimental-view-transition-api)

Explore React's experimental View Transition API and how it can create smoother, more engaging user experiences. This article dives into the details, showing practical examples and offering insights on how to utilize this feature in your own projects.

### Quick Links

- [Mastering React internationalization with i18next](https://lingual.dev/blog/getting-more-out-of-i18next-in-react/)
- [Boost React app speed with INP optimization](https://kurtextrem.de/posts/improve-inp-react)
- [React, visualized: An interactive guide to understanding React concepts](https://react.gg/visualized)

## Next.js

### [Next.js 15.1 embraces React 19!](https://nextjs.org/blog/next-15-1)

Next.js 15.1 is here, embracing React 19 with official support! Enjoy seamless integration, enhanced debugging tools, and smarter error handling for a smoother development experience.

### [Next.js on Deno deploy: A new frontier](https://deno.com/blog/nextjs-on-deno-deploy)

Next.js SSR apps can now run on Deno Deploy. It’s fast, scalable, and a glimpse into the future of serverless tech.

### [Scaling micro-frontends with Next.js multi zones](https://techhub.iodigital.com/articles/building-scalable-micro-frontends-with-next-js-multi-zones)

Managing independent deployments for large teams just got easier! Next.js Multi Zones is a powerful feature that enables the composition of multiple Next.js applications into a single unified experience, allows different teams to develop, deploy, and maintain distinct parts of a website independently.

### Quick Links

- [Introducing efficient Valkey-based caching for Next.js](https://blog.platformatic.dev/introducing-efficient-valkey-based-caching-for-nextjs)
- [SSR: Debunking myths and delivering real value](https://t3.gg/blog/post/ssr-is-not-expensive)
- [Why Dato CMS chose Astro over Next.js](https://www.datocms.com/blog/why-we-switched-to-astro)

## Others

### [Bring AI to your browser with Transformers.js](https://www.raymondcamden.com/2024/12/03/using-transformersjs-for-ai-in-the-browser)

Run AI tasks right in the browser! Transformers.js leverages a pipeline API that is easy to use and can perform tasks like sentiment analysis and object detection. All processing occurs client-side, no server needed.

### [New HTML and CSS features: Making interactive elements easier without JavaScript](https://zeroheight.com/blog/the-lowdown-on-dropdowns-in-html-css/)

The popover attribute allows developers to add popovers effortlessly, while CSS Anchoring offers more reliable positioning. The new `calc-size()` function makes it possible to animate elements to and from auto height, bringing more flexibility to animations. Plus, updates to `<details>` and `<select>` elements enhance their styling and customization capabilities. These innovations make building interactive and dynamic web elements smoother and more accessible than ever before.

### Quick Links

- [Headless, Boneless, Skinless, & Lifeless UI: 4 categories of UI abstractions](https://nerdy.dev/headless-boneless-and-skinless-ui)
- [A simple masonry-like composable layout](https://piccalil.li/blog/a-simple-masonry-like-composable-layout)
- [Architectures of modern front-end applications](https://blog.meetbrackets.com/architectures-of-modern-front-end-applications-8859dfe6c12e)
- [[Lock down your OAuth2 implementations - protect against CSRF attacks](https://auth0.com/blog/prevent-csrf-attacks-in-oauth-2-implementations)]

## Trending

### [Rising stars of JavaScript 2024](https://risingstars.js.org/2024/en)

Discover front-end tools shaping the JavaScript landscape in 2024! Key highlights include `shadcn/ui`, a modern, accessible component library for building customizable UIs, and `HTMX`, a lightweight library that brings dynamic interactions to HTML without relying heavily on JavaScript frameworks.

### [Offline-first apps: everything you need to know to get started!](http://devstarterpacks.com/blog/what-every-developer-should-know-about-offline-first-apps)

Learn the essentials of building offline-first applications in this guide. It covers the core concepts, techniques, and best practices for creating apps that function seamlessly even when the internet connection is unreliable. This article will help you understand data synchronization, caching, and handling user interactions in an offline environment.

### [Emerging Trends in Front-End Development](https://dev.to/aneeqakhan/the-future-of-front-end-development-3gea)

Explore the latest trends in front-end development, including AI-powered tools, server-driven UI, and Next.js with React Server Components. The article highlights Jamstack, headless CMS solutions, and component-driven design systems, showcasing how these innovations enhance performance, scalability, and efficiency.

### Quick Links

- [My Go-To React tech stack for 2025](https://www.robinwieruch.de/react-tech-stack/)

## Tools

### [Tailwind CSS v4.0 Beta: New features, concerns, and what you should know](https://nmn.sh/blog/2024-11-30-thoughts-on-tailwind-4)

Tailwind CSS v4 has great improvements like the switch to LightningCSS and native CSS cascade layers, but this author has concerns about the performance implications of CSS variables, the potential for abuse with new descendant variants, and the lack of clarity in some class names.

### [Node’s new built-in support for TypeScript](https://2ality.com/2025/01/nodejs-strip-type.html)

Big news for Node.js developers! Native TypeScript support is on the way through type stripping, meaning you'll soon be able to run TypeScript code directly in Node without needing to transpile it first. This article explains the implications, outlining what this change means for development workflows and how it will streamline the use of TypeScript within Node.js projects. 

### [Boost React performance with Million](https://million.dev/)

Million is a lightweight tool designed to optimize React websites by identifying slow components and improving performance and integrates directly into your IDE for real-time performance insights. Million also provides features like production observability and replay for investigating performance issues.

### Quick links

- [Onlook: The open-source Figma for React that lets you design in real-time](https://onlook.dev)

## Commentary

- [Why I ditched React for Go, HTMX, and Templ](https://blog.erodriguez.de/dependency-management-fatigue-or-why-i-forever-ditched-react-for-go-htmx-templ)
- [React and similar frontend frameworks, used incorrectly, can lead to performance and accessibility issues.](https://infrequently.org/2024/11/if-not-react-then-what)
- [The open social web is the future of the internet. Here's why I'm excited](https://werd.io/2024/the-open-social-web-is-the-future-of-the-internet)
- [Struggling with complex code? see how Types can simplify things!](https://mayhul.com/posts/type-driven-design)
- [Thinking of switching to Vite? this team did it and here's what they learned!](https://neon.tech/blog/from-webpack-to-vite)

This January 2025 report explores key frontend advancements, including React 19's Actions, Next.js 15.1's Deno Deploy support, and innovative tools like Transformers.js for AI. Discover trending technologies, best practices, and expert commentary shaping the future of frontend development.

January 2025

Frontend Report January 2025


The report for July 2024 gives you a snapshot of what’s happening in the world of web development. React is evolving with Server Components, and Next.js continues to push the boundaries of performance. Vite is solidifying its position as a top build tool, while TypeScript and other frameworks hold steady. Whether you’re looking for the latest updates or just want to stay in the loop, this report has you covered with key trends, tools, and insights to keep you informed.

## React

### [State of React: Aging like fine wine, now with Server Components](https://stateofreact.com/en-US)

This year, React Server Components have shaken up the ecosystem, rivaling the impact of Hooks in 2018. As React 18 sees wide adoption, the future of Server Components is still being figured out. At the same time, SPAs dominate with a usage of 86%.

### [React Conf 2024: React 19, Server Components & other talks you don’t want to miss](https://conf.react.dev/talks)

From React 19’s newest features to breaking the rules and real-time server components, React Conf 2024 offers a dynamic lineup including spatial computing, error-solving strategies, and more.

### [Using React Native frameworks, such as Expo, is now the recommended approach to create new apps](https://reactnative.dev/blog/2024/06/25/use-a-framework-to-build-react-native-apps)

React Native has streamlined the development process by recommending frameworks like Expo. These frameworks offer a complete toolbox for building production-ready apps, saving you from reinventing the wheel.

### Quick links

- [Using React 19 with Vite and Next.js (youtube.com)](https://www.youtube.com/watch?v=AdkNcFUsRQQ)
- [Sneaky React Memory Leaks: How the React compiler won’t save you | Kevin Schiener](https://schiener.io/2024-07-07/react-closures-compiler?utm_source=tldrwebdev)
- [How Airbnb Smoothly Upgrades React](https://tracking.tldrnewsletter.com/CL0/https:%2F%2Flinks.tldrnewsletter.com%2FH1PJOD/1/01000190eec8684b-ae23de3c-298b-4e48-baf6-6b87ab368f0e-000000/PGZOjErYrecaY5-P--SCa4c8UNLM_fLs9INsqzrQ_ms=363)

## NextJS

### [Google’s JavaScript indexing: Myths busted, modern SEO practices embraced](https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process)

This research has debunked several common myths about Google's handling of JavaScript-heavy websites. Turns out Google can effectively render and index JavaScript content, including complex SPAs, dynamically loaded content, and streamed content!

### [Someone built a library that reduced TBT by 380% for NextJS](https://github.com/woywro/next-lazy-hydration-on-scroll)

This component delays the hydration of your elements until they come into view. This can significantly improve initial load performance and reduce time-to-interactive for large pages.

Also see: [I built a library that reduced TBT by 380% : r/nextjs (reddit.com)](https://www.reddit.com/r/nextjs/comments/1ejtbp8/i_built_a_library_that_reduced_tbt_by_380/)

### [**Secret knowledge to self-host Next.js**](https://www.flightcontrol.dev/blog/secret-knowledge-to-self-host-nextjs)

Self-hosting Next.js apps can be complex, but Flightcontrol's guide demystifies the process. They cover essential steps like environment setup, deployment strategies, and optimizing performance.

### Quick links

- [Flags as Code in Next.js – Vercel](https://vercel.com/blog/flags-as-code-in-next-js)
- [Differences between the Pages and App Router with RSC Diagram : r/nextjs (reddit.com)](https://www.reddit.com/r/nextjs/comments/1eaefm9/differences_between_the_pages_and_app_router_with/)

## Others

### [State of JS 2023: TypeScript ascends, React and Vue hold steady, and Next.js dominates](https://2023.stateofjs.com/en-US/)

TypeScript continues its ascent, with smaller libraries making waves in the JavaScript world. React and Vue hold steady, while Angular sees a decline. Emerging frameworks like Qwik and Stencil are worth watching.

Next.js dominates the meta-framework space, with strong contenders in SvelteKit and Remix. Testing and build tools evolve, with Vitest and Vite on the rise. Monorepos favor Turborepo and pnpm.

In the backend, Express and Nest reign supreme.

### [Announcing TypeScript 5.6 Beta](https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-beta/)

TypeScript 5.6 Beta introduces several new features and improvements, including the `using` keyword for resource management, better type-checking for JSX, and performance enhancements. It also brings more precise control over tuple types and expanded capabilities for enums.

### [Vite - The Final Boss of Build Tools](https://bytes.dev/archives/310?ck_subscriber_id=2328911063)

Vite has achieved its goal of becoming a foundational tool in the web ecosystem, with widespread adoption from frameworks like Remix and Angular. The Vite team is creating a unified toolchain with Rust-based tools like Rolldown and OXC for faster and more comprehensive JavaScript and TypeScript handling.

### Quick links

- [Bytes #309 - War of the Bundlers](https://bytes.dev/archives/309)
- [JavaScript — What’s new with ECMAScript® 2024 (ES15) — In Depth Guide | by Igor Komolov | Medium](https://medium.com/@yourfuse/javascript-whats-new-with-ecmascript-2024-es15-ef056d2f4bf1)
- [Introducing Vercel AI SDK 3.2 – Vercel](https://vercel.com/blog/introducing-vercel-ai-sdk-3-2)

## Trending

### [ViteConf 2024: Mark your calendars for October 3rd](https://viteconf.org/)

ViteConf 2024 promises a 24-hour marathon of talks from top innovators in the Vite ecosystem. From Astro to Svelte, and beyond, get ready to dive deep into the next-gen web.

### [Astro 4.12 introduces Server Islands, blending static HTML with server-generated components](https://astro.build/blog/astro-4120/)

Extending from [islands architecture](https://astro.build/blog/introducing-astro/), Server islands make it easy to combine high performance static HTML and dynamic server-generated components for enhanced performance.

### [Eureka Labs is revolutionizing education with AI-native schools](https://eurekalabs.ai/)

Their first offering, LLM101n, is an undergrad course that teaches students to train their own AI, blending teacher expertise with AI assistance.

### Quick links

- [Accelerating Idea to Production: Using Visual Development + AI to Ship 10x Faster (youtube.com)](https://www.youtube.com/watch?v=SMlTRGbYadI)
- [Popover API 101 — Amit Merchant — A blog on PHP, JavaScript, and more](https://www.amitmerchant.com/popover-api-101/)

## New tools

### [TurboPack: The Next-Gen Bundler](https://turbo.build/pack/docs)

TurboPack is redefining bundling for JavaScript and TypeScript with its high-performance, incremental approach. Built by the creators of webpack, it promises lightning-fast development speeds by caching tasks at a granular level.

- [Turbopack updates: Moving homes – Vercel](https://vercel.com/blog/turbopack-moving-homes)

### [Meet es-toolkit - aka. “lodash on steroid”](https://github.com/toss/es-toolkit)

A modern JavaScript utility library that's 2-3 times faster and up to 97% smaller—a major upgrade to lodash, with built-in Typescript support.

### [React Flow - Node-Based UIs in React](https://reactflow.dev/)

Highly customizable React library for workflow builders, no-code apps, image processing, visualizers, and more.

### Quick links

- [TinyBase](https://tinybase.org/): The *reactive* data store for local-first apps.
- [Mako](https://makojs.dev/blog/mako-open-sourced): An extremely fast, production-grade web bundler based on Rust.
- [render.com](https://render.com/?utm_source=coopeprpress&utm_medium=cooperpress): Unified cloud to build and run all your apps and websites with free TLS certificates, global CDN, private networks and auto deploys from Git.
- [React CodeMirror](https://uiwjs.github.io/react-codemirror/): CodeMirror is a code editor component for the web. This React-specific component supports React hooks, TypeScript, and more.
- [WorkOS — Your app, Enterprise Ready](https://workos.com/?utm_source=cpjava&utm_medium=newsletter&utm_campaign=q22024): The Modern Identity Platform for B2B SaaS (SSO, SCIM, and more).

## Commentary

- [Your pain in 2024 as a web developer. : r/webdev (reddit.com)](https://www.reddit.com/r/webdev/comments/1dzw7l7/your_pain_in_2024_as_a_web_developer/?utm_source=tldrwebdev)
- [sbensu: We need visual programming. No, not like that.](https://blog.sbensu.com/posts/demand-for-visual-programming/?utm_source=tldrwebdev)
- [AI didn’t take my job](https://dava.ai/n/hank/ai-didnt-take-my-job)
- [Ask HN: Junior dev and I don't want to compete in this job market. Any advice? | Hacker News (ycombinator.com)](https://news.ycombinator.com/item?id=41125070&utm_source=tldrwebdev)
- [Please Stop Using Barrel Files | TkDodo's blog](https://tkdodo.eu/blog/please-stop-using-barrel-files)


The Front-end Market Report for July 2024 gives you a snapshot of what’s happening in the world of web development. React is evolving with Server Components making waves, and Next.js continues to push the boundaries of performance. Vite is solidifying its position as a top build tool, while TypeScript and other frameworks hold steady. Whether you’re looking for the latest updates or just want to stay in the loop, this report has you covered with key trends, tools, and insights to keep you informed.

July 2024

Frontend Report July 2024


## React

### [Common React libraries architecture](https://www.felgus.dev/blog/common-react-lib-architecture)

Most React libraries share a similar architecture: a core with the main logic and a binding (hooks/components) for React integration. The core object is often created externally and connected via Context API. Libraries use the Observer pattern to notify React of changes, triggering re-renders with useSyncExternalStore or custom hooks

### [Time to ditch Redux: Why most React apps don't need it](https://www.bennett.ink/its-probably-time-to-stop-recommending-redux)

Redux might be holding your app back! Most **state** is actually API data better handled with caching tools. Modern React can handle complex UI state with useState and custom hooks - no global store needed. Skip the boilerplate and complexity; your team will thank you when they don't have to trace actions through multiple files anymore.

### [Use React 19's cache() to kill waterfall fetching](https://aurorascharff.no/posts/avoiding-server-component-waterfall-fetching-with-react-19-cache/)

React 19's cache() API for Server Components caches data fetches/computations per render, preventing redundant requests. This reduces data coupling between components and enables data preloading to avoid waterfall fetching, improving performance. Use cache() for custom data fetching functions (like database calls), as the built-in fetch() API in Next.js already handles caching

### Quick links

- [Beyond React.memo: Smart performance optimization that actually works](https://cekrem.github.io/posts/beyond-react-memo-smarter-performance-optimization/)
- [The URL: React's underrated state manager](https://iamsahaj.xyz/blog/react-state-in-the-url/)
- [React: The unexpected perfect engine for LLM workflows](https://www.gensx.com/blog/why-react-is-the-best-backend-workflow-engine)
- [Server Actions with Toast: React's useActionState explained](https://www.robinwieruch.de/react-server-actions-useactionstate-toast/)

## Next.js

### [Next.js middleware exploit: CVE-2025-29927 authorization bypass](https://zeropath.com/blog/nextjs-middleware-cve-2025-29927-auth-bypass)

Critical CVE-2025-29927 in Next.js middleware lets attackers bypass security via the x-middleware-subrequest header. This impacts auth, CSP, geo-restrictions, and more. Affects v11.1.4 to unpatched v14/15. Update ASAP to patched versions (≥ 12.3.5, ≥ 13.5.9, ≥ 14.2.25, ≥ 15.2.3) or block the header

### [Next.js 15.2: Error handling that actually makes sense](https://nextjs.org/blog/next-15-2)

Next.js 15.2 transforms your debugging experience with beautiful new error UIs and readable stack traces! The game-changing streaming metadata feature decouples UI rendering from metadata generation for faster page loads. Plus, Turbopack gets massive speed boosts with reduced memory usage and there's experimental support for React View Transitions!

### [Can Next.js handle serious traffic? The surprising answer](https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rendered-nextjs-site-handle)

A pre-rendered Next.js site should handle tons of traffic, right? Wrong! This developer's shocking discovery shows VPS performance limits with barely any improvement after scaling up. After rejecting Cloudflare (privacy concerns) and Vercel (too expensive), a dedicated server finally delivered thousands of requests per second.

### [We ditched Next.js and lived to tell the tale](https://northflank.com/blog/why-we-ditched-next-js-and-never-looked-back)

Sometimes the popular choice isn't right! This team abandoned Next.js and found greater simplicity, better performance, and increased flexibility with their custom solution. Their honest assessment of Next.js limitations might challenge your assumptions about which framework best fits your project's actual needs.

### Quick links

- [Vercel's Fluid Compute: How it slashes AI costs](https://vercel.com/blog/how-fluid-compute-works-on-vercel)
- [How Preply boosted INP without App Router](https://medium.com/preply-engineering/how-preply-improved-inp-on-a-next-js-application-without-react-server-components-and-app-router-491713149875)

## Others

### [Tailwind's hidden cost: The maintainability trade-off](https://measured.co/blog/tailwind-trade-offs)

Tailwind lets you ship blazing fast with predefined styles and no custom CSS files, but at what cost? As projects grow, maintaining those utility-packed class strings becomes increasingly challenging. This honest look at Tailwind's trade-offs will help you decide if the initial velocity boost is worth potential long-term maintenance headaches.

### [CSS just got functions! Here's why it's a game-changer](https://css-tricks.com/functions-in-css/)

CSS is finally getting real functions! Define them with `@function`, pass arguments with type-checking, and return values with the `result` descriptor. Currently in Chrome Canary behind a flag, they'll revolutionize complex CSS logic - especially for fluid typography and dynamic layouts. The CSS preprocessor era might finally be ending!

### [Why prefetching can actually slow your site down](https://www.debugbear.com/blog/prefetch-slower-website)

While prefetching is supposed to improve website performance by loading resources in advance, it can sometimes worsen loading speed by competing with critical content for bandwidth. Despite being assigned the lowest priority, prefetch requests may initiate too early, delaying the loading of important elements like the Largest Contentful Paint (LCP). To prevent this, you can inject prefetch hints via JavaScript after the initial page load to make sure essential content loads first.

### Quick links

- [CSS individual transforms are additive (and awesome)](https://polypane.app/blog/the-css-transform-property-and-individual-transforms-are-additive)
- [CSS relative colors: Dynamic color generation is here](https://ishadeed.com/article/css-relative-colors/)
- [TypeScript: The JavaScript sidekick you didn't know you needed!](https://2ality.com/2025/03/typescript-sales-pitch.html)

## Trending

### [React 2025: Server power unleashed & dev tools evolved!](https://www.robinwieruch.de/react-trends/)

This year, expect **React Server Components (RSC)** to become standard. **React Server Functions (RSF)** will simplify data fetching & mutations. **React 19** brings form improvements. Frameworks beyond Next.js (TanStack Start, React Router) will rise. **Full-Stack React** gains traction. Plus, watch for new styling approaches & tools like **Biome** and the **React Compiler**.

### [TypeScript is getting 10x faster.](https://devblogs.microsoft.com/typescript/typescript-native-port/)

Get ready for `Corsa` - TypeScript's new Go-based compiler that promises 10x faster builds, half the memory usage, and near-instant editor responsiveness! The upcoming native port will transform the TypeScript experience, especially on large codebases. Preview coming mid-2025, with full release by year-end.

### [Corepack unplugged: Node.js rethinks bundled package managers!](https://socket.dev/blog/node-js-tsc-votes-to-stop-distributing-corepack)

The **Node.js TSC has voted to stop distributing Corepack** in future releases (25+), though it remains experimental in v24 and earlier . This move reflects **low adoption**, **distribution concerns**, and the desire for **independent evolution of package managers**. Developers may need to **install Corepack separately** if needed.

### [TanStack Start on Netlify: Official deployment partner](https://www.netlify.com/blog/tanstack-start-netlify-official-deployment-partner/)

**Netlify** is now the **official deployment partner** for **TanStack Start**, the hot new full-stack React framework! Expect seamless, **zero-config deployments** and a killer developer experience.

### Quick links

- [How we migrated 160,000 lines to TypeScript with zero downtime](https://benhowdle.im/migrating-js-to-ts-zero-downtime.html)
- [Prisma replaces Rust with WASM and TypeScript, gets 3.4x faster](https://www.prisma.io/blog/rust-to-typescript-update-boosting-prisma-orm-performance)

## Tools

### [TanStack Form v1: Forms done right, finally](https://tanstack.com/blog/announcing-tanstack-form-v1)

TanStack Form v1 is here and production-ready across React, Vue, Angular, Solid, and Lit! With extreme type safety, schema validation (Zod, Valibot, ArkType), and smart async validation with built-in debouncing, it solves the form headaches that have plagued frontend devs for years.

### [React Router v7: Middleware changes everything](https://react.statuscode.com/link/166745/web)

React Router v7 introduces middleware - a game-changing approach to handling routes that lets you intercept and transform navigation requests before they complete. Perfect for auth checks, analytics, permission verification, and more.

### [TypeScript 5.8: Better return type checks & ESM require() support](https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/)

TypeScript 5.8 enhances code checks with granular return expression analysis, improving bug detection. It boosts Node.js ESM/CJS interop under `--module nodenext`. The `--erasableSyntaxOnly` flag aids Node.js direct TS execution

### [Chrome 133: Enhanced attr() for styling any CSS property](https://css-tricks.com/chrome-133-goodies/)

Chrome 133 enhances CSS with two main features: `attr()` for all properties and scroll state container queries. The `attr()` function can now use HTML attribute values to style any CSS property, not just content. This includes specifying data types and fallback values. Additionally, container queries can now style elements based on their scroll state (e.g., "stuck", "snapped") within a defined container. This allows dynamic styling of elements like sticky headers

### Quick links

- [Why does target="\_blank" have that underscore?](https://kyrylo.org/html/2024/10/25/why-does-target-blank-have-an-underscore-in-front.html)
- [Lynx: Build native mobile & web UIs from one codebase](https://lynxjs.org/)

## Commentary

- [The end of JavaScript fatigue? Don't count on it](https://allenpike.com/2025/javascript-fatigue-ssr)
- [Decoding the debate around signals in the world of React](https://www.felgus.dev/blog/signals-in-react)
- [Local-first is the future (but not without challenges)](https://rxdb.info/articles/local-first-future.html)


March 2025 brings critical frontend updates! Learn about the Next.js security exploit you must patch nows. Explore TypeScript's upcoming 10x speed boost with Corsa, React Router's game-changing middleware, and why prefetching can surprisingly slow down your site. Plus: CSS functions are finally here, new in Chrome 133, Node.js is dropping Corepack, and TanStack Start finds an official deployment home!

March 2025

Frontend Report March 2025


This month’s newsletter highlights key advancements in web development, including React’s new compiler beta and top updates from Next.js Conf 2024, featuring optimizations like Edge Functions and React Server Components. Industry trends show a shift toward full-stack roles, modern CSS standards, and rising demand for engineering talent. AI-driven tools like GitHub Copilot and Project IDX continue advancing development workflows.

## React

### [React Compiler Beta Release](https://react.dev/blog/2024/10/21/react-compiler-beta-release)

React’s new compiler, in beta, introduces optimizations that minimize re-renders and improve code-splitting, enhancing performance, especially for larger applications.

### [The Interactive Guide to Rendering in React](https://ui.dev/why-react-renders)

Discover why React components render, what triggers re-renders, and how to optimize them for better app performance. Perfect for new developers looking to understand React’s rendering process.

### Quick Links

- [React Folder Structure in 5 Steps](https://www.robinwieruch.de/react-folder-structure/)
- [React Native Storybook 8](https://storybook.js.org/blog/react-native-storybook-8/)
- [Conditional React hooks pattern](https://robinmalfait.com/blog/conditional-react-hooks-pattern)
- [Tailwind CSS Group Modifier to Prevent React Rerenders](https://www.nico.fyi/blog/tailwind-css-group-modifier-to-prevent-react-rerender)

## Next.js

### [Key Highlights from Next.js Conf 2024: What You Missed](https://vercel.com/blog/recap-next-js-conf-2024)

Get the highlights from Next.js Conf 2024, featuring exciting updates on React Server Components, Edge Functions, and the new Next.js features that are shaping modern web development.

### Quick Links

- [Server Side State management in NextJS: a deep dive into React Cache](https://www.yoseph.tech/posts/nextjs/server-side-state-management-in-nextjs-a-deep-dive-into-react-cache)
- [How to Build and Deploy a Headless WordPress with Next.js](https://scientyficworld.org/how-to-deploy-headless-wordpress-with-next-js/)
- [Managing Advanced Search Param Filtering in the Next.js App Router](https://aurorascharff.no/posts/managing-advanced-search-param-filtering-next-app-router/)

## Others

### [State of Frontend 2024  - The Rise of Full-stack development](https://tsh.io/state-of-frontend/)

Full-stack developers now outnumber senior frontend roles, with performance as a top challenge prompting simpler applications. Nearly 69% of companies plan to integrate AI for developer support, and remote work remains popular.

### [State of CSS 2024 - Embracing 'New CSS' with Advanced Features and Enhanced Browser Support](https://2024.stateofcss.com/en-US/)

The report highlights a pivotal shift from traditional CSS practices to "New CSS," characterized by the adoption of advanced features like sub-grid, variables, and container queries.

### [State of Engineering Market 2024 - The growth resumes](https://newsletter.pragmaticengineer.com/p/state-of-eng-market-2024?utm_source=substack&utm_medium=email)

The report highlights resilient demand for software engineers, with growth in remote work and a broadening search for talent beyond traditional tech hubs. Key areas include AI, machine learning, and cybersecurity.

### Quick Links

- [The New Architecture in React Native](https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here)
- [Content-Aware Components Using CSS :has(), Grid, and Quantity Queries](https://piccalil.li/blog/making-content-aware-components-using-css-has-grid-and-quantity-queries/)
- [Unleash the Power of Scroll-Driven Animations](https://css-tricks.com/unleash-the-power-of-scroll-driven-animations/)
- [The most effective ways to improve Core Web Vitals](https://web.dev/articles/top-cwv)
- [How We Shrunk Our Git Repo Size by 94%](https://www.jonathancreamer.com/how-we-shrunk-our-git-repo-size-by-94-percent/)
- [Fixing your website's JavaScript performance](https://developer.mozilla.org/en-US/blog/fix-javascript-performance/)

## Trending

### [Enhance Your Code Reviews with GitHub Copilot Workspace (Public Preview)](https://github.blog/changelog/2024-10-29-refine-and-validate-code-review-suggestions-with-copilot-workspace-public-preview/)

GitHub Copilot Workspace now offers tools to refine and validate code review suggestions, enabling a smoother and more efficient review process with AI-driven insights.

### [How Vercel adopted microfrontends](https://vercel.com/blog/how-vercel-adopted-microfrontends)

Learn how Vercel cut build times and improved developer velocity while maintaining a smooth user experience with microfrontends.

## New Tools

### [TanStack Start - Full-stack React framework](https://tanstack.com/start/latest)

Full-document SSR, Streaming, Server Functions, bundling and more, powered by TanStack Router, Vinxi, and Vite.

### [Project IDX - Building apps in the cloud](https://idx.google.com/)

Project IDX simplifies the process of setting up and managing a monolithic tech stack, integrating services from database to authentication. It aims to streamline the deployment and maintenance of cohesive, scalable applications.

### [OneStack - When creating websites and apps is too complex](https://onestack.dev/)

One is a new React framework for web and native, built on Vite. It simplifies things with universal, [typed routing](https://onestack.dev/docs/routing) seamlessly across static, server, and client pages

### Quick Links

- [Motion Canvas - A TypeScript library for creating animated videos using the Canvas API](https://motioncanvas.io/)
- [Deno 2: New Features and Enhancements](https://deno.com/blog/v2.0)
- [Nuqs: Lightweight Data Fetching for React](https://nuqs.47ng.com/)

## Commentary

- [Why I Switched from Svelte to React: A Developer’s Perspective](https://www.reddit.com/r/sveltejs/comments/1gbwi0b/i_moved_from_svelte_to_react/)
- [A Reddit discussion on React Query alternatives](https://reddit.com/r/reactjs/comments/1ghxz99/if_youre_not_using_react_query_in_large/)
- [The WordPress, WP Engine and ACF Drama](https://dev.to/matfrana/the-wordpress-wp-engine-and-acf-drama-5h88)
- [Using AI Generated Code Will Make You a Bad Programmer](https://slopwatch.com/posts/bad-programmer/)
- [Measuring Developer Productivity: Real-World Examples](https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity-bae)

This month’s newsletter highlights React’s new compiler beta, key updates from Next.js Conf 2024, and industry shifts toward full-stack roles and modern CSS. AI-driven tools like GitHub Copilot and Project IDX are further advancing development workflows.

October 2024

Frontend Report October 2024


A second half of November 2024 frontend roundup featuring React Router v7, Tailwind CSS v4 Beta, and Vite 6.0. Explore tools like Next Cloudinary, Extism, and SmarkForm, plus insights on SSR cost-effectiveness, JavaScript Symbols, and new CSS strategies.

## React

### [React Router v7: New features and flexible development options](https://remix.run/blog/react-router-v7)

React Router v7 introduces `framework mode` with features from Remix, including server rendering and improved type safety. It also includes enhanced templates for starting new projects, and comprehensive upgrade guides for React Router v6 and Remix v2 users.

### [React Anti-Pattern: Stop Passing Setters Down the Components Tree](https://matanbobi.dev/posts/stop-passing-setter-functions-to-components)

Passing `useState` setters as props can lead to abstraction leaks, reducing clarity and reusability, making it harder to reason about the state. A better approach is to use callback functions to handle state changes, making your code more maintainable and flexible.

### Quick links

- [React Server Components vs. SSR: 5 key differences](https://www.tymzap.com/blog/5-differences-between-react-server-components-and-server-side-rendering)
- [React Portals: Escaping the DOM hierarchy](https://techhub.iodigital.com/articles/what-are-react-portals)
- [Tremor: React components for dashboards & charts](https://tremor.so/)

## Next.js

### [Next Cloudinary: A game-changer for client-side file handling](https://robiul.dev/next-cloudinary-a-game-changer-for-client-side-file-handling)

Next Cloudinary is a flexible tool that simplifies file handling and image optimization in Next.js applications. It supports various file sources like Google Drive and offers advanced image effects, real-time adjustments, video transformations, watermarking and responsive rendering.

### [Solito 4.3: Bridge the gap between React Native and Next.js](https://solito.dev)

Solito enables seamless development of universal React Native and web applications by sharing components and navigation across platforms. Built to integrate with Expo and Next.js, it ensures high performance and a consistent user experience across mobile and web.

### Quick links

- [Payload 3.0: A Next.js-Native CMS](https://payloadcms.com/blog/payload-30-the-first-cms-that-installs-directly-into-any-nextjs-app)

## Others

### [Mastering JavaScript Symbols: Unique keys, custom behaviors, and advanced usages](https://www.trevorlasn.com/blog/symbols-in-javascript)

Delve into JavaScript Symbols, the powerful tool for creating unique property keys and enabling custom behaviors in your objects. Explore practical applications, from controlling primitive conversions with `Symbol.toPrimitive` to building specialized arrays with `Symbol.species`. Learn about their uniqueness, serialization quirks, and how `Symbol.for()` enables global sharing.

### [A simple guide to importing JavaScript libraries without a build system](https://jvns.ca/blog/2024/11/18/how-to-import-a-javascript-library/)

This guide walks you through importing JavaScript libraries like Chart.js and @atcute/oauth-browser-client, covering global variables, ES modules, and CommonJS. It explores using UMD files, ES modules with importmaps, and converting CommonJS modules, highlighting challenges and the importance of a build step for dependency updates.

### Quick links

- [Essential TypeScript for React: Quick productivity tips](https://www.jacobparis.com/content/react-ts)
- [Easy Light/Dark Modes: No fuss!](https://frontendmasters.com/blog/no-fuss-light-dark-modes/)
- [Building Reddit's frontend with Vite](https://www.reddit.com/r/RedditEng/comments/1dhztk8/building_reddits_frontend_with_vite/)
- [Vitest vs. Jest: The ultimate showdown](https://www.speakeasy.com/post/vitest-vs-jest)

## Trending

### [Evaluating Browser Support: A Framework for Deciding When to Use New CSS Features](https://www.joshwcomeau.com/css/browser-support)

Learn a framework to decide on using new CSS features based on browser support. It considers fallback experience, audience-specific browser stats, and risks of broken experiences. Simulate unsupported browsers by removing CSS declarations and use @supports for custom fallbacks when needed.

### [Crafting a new web performance score: Designing for scalability and clarity](https://csswizardry.com/2024/11/designing-and-evolving-a-new-performance-score/?utm_source=tldrwebdev)

This blog discusses the limitations of using Core Web Vitals (CWV) scores for comparing websites due to their differing units and scales. It introduces CrRRUX, a new metric that normalizes CWV metrics to a 0-1 scale and averages them for a single, comparable performance score within a cohort.

### Quick links

- [Framer Motion goes solo: New adventures in animation!](https://motion.dev/)

## New Tools

### [Tailwind CSS v4 Beta: Built for speed and modern web development](https://tailwindcss.com/blog/tailwindcss-v4-beta)

Tailwind CSS v4 Beta introduces a revolutionary engine with 5x faster full builds and 100x faster incremental builds. Enjoy a unified toolchain, CSS-first configuration, and modern web features like cascade layers, container queries, and popovers.

### [Vite 6.0: Faster, simpler, more extensible!](https://vitejs.dev/blog/announcing-vite6/)

Vite 6 brings groundbreaking updates, including a 10M+ weekly npm downloads milestone, faster builds, and a new experimental Environment API for better development experiences. With modern features, broader framework support, and seamless upgrades, it's the most significant release since Vite 2.

### [Extism: Unlocking WebAssembly for everyone](https://extism.org/)

Extism is a lightweight, universal framework for building with WebAssembly (Wasm), supporting its use across various platforms. It offers a flexible, plug-in system designed to make all software programmable.

### Quick links

- [SmarkForm: Effortless markup-driven and extendable forms](https://smarkform.bitifet.net/)
- [SVG to Font: Generator of fonts from SVG icons](https://wangchujiang.com/svgtofont/)
- [Effortlessly Transform JSON into Stunning Interactive Tree Diagrams with jsontr.ee](https://github.com/xzitlou/jsontr.ee)

## Commentary

- [Which IDEs do devs actually love? (And why!)](https://substack.com/redirect/cd81c4f0-4acd-4366-b3d4-896fe33c2d65)
- [Technical Debt and Interop Challenges in the Web Platform](https://bkardell.com/blog/debt.html)
- [Impressions of React and TypeScript from an Elixir/Elm Developer: A Tale of Two Ecosystems](https://korban.net/posts/elm/2024-11-16-typescript-react-impressions/)
- [PostHog's Engineering: Solving challenges with trust and future-focused tech decisions](https://dub.link/bytes-nov25)


A second half of November 2024 frontend roundup featuring React Router v7, Tailwind CSS v4 Beta, and Vite 6.0. Explore tools like Next Cloudinary, Extism, and SmarkForm, plus JavaScript Symbols, and new CSS strategies.

Nov 2024 (Second Half)

Frontend Report Second Half of November 2024


This roundup covers the latest in React, Next.js, and web development. React Server Actions are now Server Functions, and there's a deep dive into the React 19 compiler. In Next.js news, OpenNext is enabling self-hosting, and there's fresh guidance on Progressive Web Apps. Plus, explore tips on lazy loading, CSS Grid, and JavaScript's evolution.

## React

### [Server Functions are Here! (They Used to be Server Actions)](https://19.react.dev/reference/rsc/server-functions 'https://19.react.dev/reference/rsc/server-functions')

React's Server Actions got a name change! Now they're Server Functions, and they're not just for mutations anymore.

### [How to Use React Compiler – A Complete Guide](https://www.freecodecamp.org/news/react-compiler-complete-guide-react-19/)

The buzz around React 19's compiler is real. This comprehensive guide walks you through everything you need to know to harness its power.

### [SPA Lazy Loading: Watch Out for These Pitfalls](https://reacttraining.com/blog/spa-lazy-loading-pitfalls)

Lazy loading with React Router can be tricky. Avoid common pitfalls by understanding how to structure your loader functions for optimal performance.

### Quick Links

- [The unspoken rules of React hooks](https://macwright.com/2024/09/19/the-extra-rules-of-hooks)
- [React Testing Technique: Inverse Assertions](https://www.epicweb.dev/inverse-assertions)
- [Modern Data-Fetching in React - Comparing architectures at a high level](https://reacttraining.com/blog/modern-data-fetching-in-react)
- [Vim for React Developers - A free course focusing on real-world scenarios](https://vimforreactdevs.com/)

## Next.js

### [ChatGPT Ditches Next.js, Embraces Remix: What's the Deal?](https://www.youtube.com/watch?v=hHWgGfZpk00)

OpenAI's ChatGPT has made a switch from Next.js to Remix. We're breaking down the possible reasons behind this intriguing move.

### [OpenNext: Sharing is Caring for Next.js Apps](https://opennext.js.org/)

Next.js, unlike Remix, Astro, or the other modern frontends, doesn't have a way to self-host across different platforms. OpenNext is on a mission to make self-hosting Next.js apps a reality across different platforms. No more vendor lock-in!

### [Next.js Goes PWA](https://nextjs.org/docs/app/building-your-application/configuring/progressive-web-apps)

Progressive Web Applications (PWAs) offer the reach and accessibility of web applications combined with the features and user experience of native mobile apps. The new Next.js docs now make it easier than ever.

### Quick Links

- [Deploying a Next.js App to Production in any server](https://www.saybackend.com/blog/04-deploy-nextjs-to-production-without-vercel)
- [Reliable date formatting in Next.js – Internationalization (i18n) for Next.js](https://next-intl-docs.vercel.app/blog/date-formatting-nextjs)

## Others

### [Easy RAG for TypeScript and React Apps](https://edspencer.net/2024/9/2/easy-rag-for-typescript-and-react-apps)

This article walks through setting up the necessary architecture and TypeScript types to efficiently integrate **Retrieval-Augmented Generation (RAG)** in **TypeScript** and **React** apps.

### [Replacing React code with CSS :has selector](https://www.developerway.com/posts/replacing-react-with-css)

See real-world React examples where CSS :has steals the show! From handling focus to jazzing up tables, it's all here.

### [Is ES5 Still Relevant? A Look at JavaScript's Evolution](https://philipwalton.com/articles/the-state-of-es5-on-the-web/)

This Google engineer challenges the norm: Do we really need to transpile to ES5 anymore?

### Quick Links

- [Data Synchronization with React Query](https://ui.dev/c/query/data-synchronization)
- [The web's clipboard, and how it stores data of different types](https://alexharri.com/blog/clipboard)
- [CSS display contents - How it works](https://ishadeed.com/article/display-contents/)
- [Cleaner JavaScript promises with safe-await](https://alexpate.com/posts/cleaner-promises-with-safe-await)
- [CSS Masonry & CSS Grid](https://css-tricks.com/css-masonry-css-grid/)

## Trending

### [Open Letter to Oracle: It's Time to Free JavaScript!](https://javascript.tm/)

Prominent figures in the JavaScript world are calling on Oracle to release the "JavaScript" trademark: _You have long ago abandoned the JavaScript trademark, and it is causing widespread, unwarranted confusion and disruption._

### [Bytes #323 - Hono: The Next Big Thing in Web Frameworks?](https://bytes.dev/archives/323)

Discover why it's causing a stir in the JavaScript world. Think blazing-fast speeds and effortless full-stack development. And some other cool bits.

### Quick Links

- [Prompt design - A case for building better tools for it](https://www.cursor.com/blog/prompt-design)
- [Using ChatGPT to reverse engineer minified JavaScript](https://glama.ai/blog/2024-08-29-reverse-engineering-minified-code-using-openai)

## New Tools

### [Meet Conform: The Type-Safe Form Validation Library](https://conform.guide/)

Conform is a type-safe form validation library utilizing web fundamentals to progressively enhance HTML Forms with full support for server frameworks like [Remix](https://remix.run/) and [Next.js](https://nextjs.org/).

### [NewDevTools: Your Daily Dose of Developer Goodies](https://newdevtools.com/)

Discover new developer tools & services daily with NewDevTools. Updated daily!

### [Bulletproof React - A simple, scalable, and powerful architecture for building production ready React applications](https://github.com/alan2207/bulletproof-react)

This is not supposed to be a template, boilerplate or a framework, but more of an opinionated guide, showcasing solving most of the real-world problems of an application in a practical way and help developers write better applications.

### Quick Links

- [Tailwind CSS for Emails? Now You Can Inline Those Styles!](tailwind-to-inline-npm-npmjs.com)](https://www.npmjs.com/package/tailwind-to-inline))
- [Vaul 1.0: New React Drawer Component](vaul-emilkowal.ski)](https://vaul.emilkowal.ski/))
- [DMNO - Environment Variables Evolved](https://dmno.dev/)
- [prabhuignoto/react-chrono: 🕑 Modern Timeline Component for React](https://github.com/prabhuignoto/react-chrono)
- [Write and Code with ChatGPT: Introducing Canvas](https://openai.com/index/introducing-canvas/)

## Commentary

- [Why Gumroad Didn't Choose htmx](https://htmx.org/essays/why-gumroad-didnt-choose-htmx/)
- [Something went wrong – Ways out of the JavaScript crisis](https://molily.de/something-went-wrong/)
- [The hardest bug investigation of my career and the insane code that caused it](https://www.reddit.com/r/ExperiencedDevs/comments/1fu0e5q/the_hardest_bug_investigation_of_my_career_and/)


This roundup highlights the latest in React and Next.js, including Server Functions, the React 19 compiler, and self-hosting with OpenNext. Find tips on lazy loading, CSS Grid, JavaScript's evolution, plus new tools and expert insights.

September 2024

Frontend Report September 2024


## Infinite scroll - Benefits and Challenges

Infinite scroll has become a popular web design technique in recent years, as it offers several benefits over traditional pagination models such as reducing page load times or minimizing the need for users to browse through multiple pages. However, it can also present some painful challenges for accessibility and usability. One of the most common issues happens when you are scrolling the list, then click on an item to view its detail (and of course, is navigated to another page). When going back to the list, you lose your previous scroll position and have to scroll all the way to find the item you clicked on before.

![](assets/retain-scroll-position-in-infinite-scroll_infinite_scrolling.webp)

_Image Source: [https://www.explainxkcd.com](https://www.explainxkcd.com/wiki/index.php/1309:_Infinite_Scrolling)_

## Solution

In this article, we will show you an approach using the session storage to store the scroll position, with the infinite scroll implemented using [`useSWRInfinite`](https://swr.vercel.app/docs/pagination.en-US#useswrinfinite).

```javascript
export const LIST_STATES_KEY = 'infinite-scroll-list-states'

export default function createRetainPositionStore<
	T extends SWRInfiniteResponse<any, any>,
>(storeKey = LIST_STATES_KEY) {
	function useRetainPosition({ swr }: { swr: T }) {
		// ...
	}

	function handleSaveStates({ swr }: { swr: T }) {
		// ...
	}

	return { useRetainPosition, handleSaveStates }
}
```

Let's begin by creating a `createRetainPositionStore` that takes in a key that we will use to store and retrieve data from the session storage.

We will also implement two functions inside, one to handle the behaviors before routing happens, and another one for those when we go back to the page and want to retain the scroll position. Both of them accept the parameter of `swr` which is the [response](https://swr.vercel.app/docs/pagination.en-US#return-values) of the `useSWRInfinite()`.

```javascript
function handleSaveStates({ swr }: { swr: T }) {
  sessionStorage.setItem(storeKey, JSON.stringify({ swrSize: swr.size, scrollPosition: window.scrollY }))
}
```

The function above simply stores an object with `swrSize` and `scrollPosition` to the session storage. When a user clicks on an item and is navigated to the detail page, we call this function along with the routing function to store the vertical scroll position (`scrollPosition`) and also the number of pages (or a group of several consecutive items) that infinite scroll already loaded (`swrSize`).

```javascript
function useRetainPosition({ swr }: { swr: T }) {
  const documentHeight = document?.documentElement.scrollHeight || 0
  const listStates = JSON.parse(sessionStorage.getItem(storeKey) || '{}')

  useEffect(() => {
    if (typeof listStates.scrollPosition !== 'number') {
      return undefined
    }

    if (documentHeight > listStates.scrollPosition) {
      window.scrollTo(0, listStates.scrollPosition)
      sessionStorage.removeItem(storeKey)
    }
  }, [documentHeight, listStates.scrollPosition])

  useEffect(() => {
    if (typeof listStates.swrSize !== 'number') {
      return undefined
    }

    if (listStates.swrSize > 1) {
      swr.setSize(listStates.swrSize)
    }
  }, [listStates.swrSize, swr])
}
```

The hook `useRetainPosition` is called in the listing page that uses the infinite scroll technique, so that everytime we visit the page, the two `useEffect`s help us to retrieve the data from the session storage. The `scrollPosition` is used for scrolling the page to the previous position. The `swrSize`, on the other hand, is passed to the `setSize` function to tell `swr` how many pages already loaded before we were navigated to the item detail page.

This makes sense since as mentioned above, when user clicks on an item and is navigated to the detail page, we will store those data to the session storage, and when user wants to go back to the listing page, `useRetainPosition` can retrieve those data and the page will be scrolled to the previous position. After calling `window.scrollTo(0, listStates.scrollPosition)`, don't forget to remove the relating data from the session storage to prevent unwanted scrolling behaviors of the page in the future.

## Reference

- https://www.explainxkcd.com/wiki/index.php/1309:_Infinite_Scrolling


Infinite scroll has become a popular web design technique in recent years, as it offers several benefits over traditional pagination models. However, it can also present some painful challenges for accessibility and usability.

Retain scroll position in infinite scroll


Scroll-driven animations are popular effects used in web design. They are animations that are connected to the scroll position of a scroll container. So, as you scroll up or down, the animation moves accordingly. For example, think of background images that move with your scroll or indicators that show your progress as you read through a page. Another type of scroll-driven animation is linked to an element's position within its scroll container. With this, elements can smoothly fade in as they become visible.

In the past, achieving these effects involved responding to scroll events on the main thread. However, this made it difficult to create smooth and synchronized animations. But now, thanks to the Scroll-driven Animations specification, you have access to new APIs and concepts that enable you to easily create declarative scroll-driven animations. These APIs work seamlessly with the Web Animations API and CSS Animations API.

## Animation timelines

By default, an animation attached to an element runs on the document timeline. Its origin time starts at 0 when the page loads, and starts ticking forwards as clock time progresses. This is the default animation timeline and, until now, was the only animation timeline you had access to.

The Scroll-driven Animations Specification defines two new types of timelines that you can use:

### Scroll Progress Timeline

A **Scroll Progress Timeline** is an animation timeline that is linked to progress in the scroll position of a scroll container–also called scrollport or scroller–along a particular axis. It converts a position in a scroll range into a percentage of progress.

The starting scroll position represents 0% progress and the ending scroll position represents 100% progress. In the following visualization, you can see that the progress counts up from 0% to 100% as you scroll the scroller from top to bottom.

<video src="https://storage.googleapis.com/web-dev-uploads/video/AeNB0cHNDkYPUYzDuv8gInYA9rY2/xdU4YJ6cxjNYpec1XcE6.mp4" controls></video>

Visualization of a Scroll Progress Timeline. As you scroll down to the bottom of the scroller, the progress value counts up from 0% to 100%. Source: https://developer.chrome.com/articles/scroll-driven-animations/

### View Progress Timeline

A **View Progress Timeline** is an animation timeline that is linked to the relative progress of a particular element within a scroll container.

Just like **IntersectionObserver**, this feature tracks how much of an element is visible in the scroller. If the element is completely hidden, it's not considered intersecting. But even if a small part of the element is visible, it's considered intersecting.

A View Progress Timeline starts when the subject enters the scroll container and ends when it leaves. In the visualization, the progress begins at 0% when the subject enters and reaches 100% when it exits the container.

<video src="https://storage.googleapis.com/web-dev-uploads/video/AeNB0cHNDkYPUYzDuv8gInYA9rY2/rvPTFW2277KBTuWiZFj1.mp4" controls></video>

Visualization of a View Progress Timeline. The progress counts up from 0% to 100% as the subject (green box) crosses the scroller. Source: https://developer.chrome.com/articles/scroll-driven-animations/

## Basic usage

To demonstrate the Scroll-driven Animations, we will re-create the animation from [this demo](https://codepen.io/chriscoyier/pen/mdVWgdN) without using any JavaScript. Let's grab some code from the original example:

```
<body>
  <svg width="100" height="100" viewBox="0 0 24 24">
  <path d="M21,9H15V22H13V16H11V22H9V9H3V7H21M12,2A2,2 0 0,1 14,4A2,2 0 0,1 12,6C10.89,6 10,5.1 10,4C10,2.89 10.89,2 12,2Z" />
</svg>
</body>
```

```
svg {
  position: fixed;
  top: 50%;
  left: 50%;
  margin-top: -50px;
  margin-left: -50px;
}

@keyframes rotate {
  to {
    transform: rotate(360deg);
  }
}

body {
  min-height: 500vh;
}
```

Our goal is to make the icon rotate based on the user's scrolling. To achieve this, we need to create a Scroll Progress Timeline using CSS. The simplest way to do this is by using the `scroll()` function. It allows us to create an anonymous Scroll Timeline, which we can then set as the value for the new `animation-timeline` property.

```
svg {
  ...
  animation: rotate auto linear;
  animation-timeline: scroll(root, block);
}
```

The `scroll()` function requires two arguments: `<scroller>` and `<axis>`. Here are the accepted values for each argument:

For the `<scroller>` argument:

**nearest**: Uses the nearest ancestor scroll container (default). **root**: Uses the document viewport as the scroll container. **self**: Uses the element itself as the scroll container.

For the `<axis>` argument:

**block**: Measures the progress along the block axis of the scroll container (default). **inline**: Measures the progress along the inline axis of the scroll container. **y**: Measures the progress along the y-axis of the scroll container. **x**: Measures the progress along the x-axis of the scroll container.

In our case, to bind an animation to the root scroller on the block axis, you can use the simplified syntax `scroll(root block)`. Also, note that when using a Scroll Progress Timeline, it does not make sense to set the `animation-duration` in seconds. Instead, you should set it to `auto`.

You can find the full code of this example at this [link](https://codepen.io/Levi-ackerman/pen/BaqeENy)

Note: Make sure you run this example in Chrome 115 or above with the 'Experimental Web Platform Features' enabled.

That's it! With just a few lines of CSS code, we've created an awesome scroll animation. You can create many amazing animations with Scroll-driven Animation. To discover more examples, please check the reference link.

## References

- https://scroll-driven-animations.style
- https://developer.chrome.com/articles/scroll-driven-animations
- https://www.youtube.com/watch?v=oDcb3fvtETs&t=335s


Scroll-driven animations are popular effects used in web design. They are animations that are connected to the scroll position of a scroll container.

Scroll-driven animations


I'm currently working on a new application called Javis, which operates as a Chrome extension. Functioning as an AI assistant, Javis is designed to facilitate a smooth and enriching web browsing experience for users. During its testing phase in Chrome, I faced a unique challenge - **Javis's CSS clashed with the webpage's CSS**. The result was a distortion of both the application's and the webpage's interfaces. Following a research, I unearthed a potent solution - the Shadow DOM. In this piece, I aim to explain the concept of Shadow DOM and shed light on the its advantage of encapsulating style.

## What is Shadow DOM?

Shadow DOM is a web standard that allows encapsulation of HTML, CSS, and JavaScript within a specific context. Shadow DOM allows hidden DOM trees to be attached to elements in the regular DOM tree — this shadow DOM tree starts with a shadow root, underneath which you can attach any element, in the same way as the normal DOM.

![](assets/shadow-dom.svg) Source: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM

There are some bits of shadow DOM terminology to be aware of:

- **Shadow host**: The regular DOM node that the shadow DOM is attached to.
- **Shadow tree**: The DOM tree inside the shadow DOM.
- **Shadow boundary**: the place where the shadow DOM ends, and the regular DOM begins.
- **Shadow root**: The root node of the shadow tree.

When working with the shadow DOM, you have the power to manipulate its nodes just like you would with non-shadow nodes. This includes appending children, setting attributes, and applying styles using `element.style.color` or a `<style>` element within the shadow DOM. The key distinction is that any code within the shadow DOM remains encapsulated, unable to affect elements outside of it, providing a valuable encapsulation feature.

## Basic usage

Now that we understand the importance of Shadow DOM, let's explore how to create and manipulate Shadow DOM. You can create Shadow Dom by attaching a shadow root to any element using the `Element.attachShadow()` method. This takes as its parameter an options object that contains one option — `mode` — with a value of `open` or `closed`:

```js
const shadowOpen = host.attachShadow({ mode: 'open' })
const shadowClosed = host.attachShadow({ mode: 'closed' })
```

- `open`: The shadow DOM/ internal DOM of the component is accessible from outside JavaScript.
- `closed`: The shadow DOM/ internal DOM of the component is not accessible outside JavaScript. The `<video>` tag is an example of closed-mode shadow root.

## Conclusion

Shadow DOM provides a powerful tool for developers creating website extensions, widgets, and similar interactive components. It offers the benefit of encapsulation, ensuring styles and scripts do not clash with the host page, that can significantly enhance the reliability and user experience of your applications.

## References

- https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM


Shadow DOM is a web standard that allows encapsulation of HTML, CSS, and JavaScript within a specific context.

Shadow DOM


## Overview

For global state management in some frameworks like ReactJs; we already have Redux, React Context, Recoil, and Mobx... for handling that. But if we only need the vanilla javascript for handling specific state and avoid using the library to manage the state (like minimizing the bundle-size, avoid on creating too many instances...), we can use the help of design patterns.

## What is the Singleton Design Pattern?

![](assets/singleton-design-pattern-in-javascript_singleton-pattern.webp)

Singleton design pattern is the pattern in that we only create one static instance of the class.

Which can be accessed in all components, and functions without recreating or conflicting the instances.

### Example

```javascript
// Filename: singleton.js

class MyNameClass {
  constructor() {
    this._name
  }

  set name(value) {
    this._name = value
  }

  get name() {
    return this._name
  }
}

const Singleton = function () {
  let instance

  function createInstance() {
    return new MyNameClass()
  }

  return {
    getInstance: function () {
      if (!instance) {
        instance = createInstance()
      }
      return instance
    },
  }
}

export const singleton = Singleton()
```

The `createInstance` function for creating the instance of `MyNameClass`.

When requested the instance from `MyNameClass`, the method `getInstance` will be invoked. In the `getInstance` method only creating new `MyNameClass` when the instance of the class is not created and return the created instance.

```javascript
// Filename: index.js

import { singleton } from './Singleton'

function main() {
  const instanceOne = singleton.getInstance()
  instanceOne.name = 'John Doe'

  const instanceTwo = singleton.getInstance()
  console.log('The second instance with name: ', instanceTwo.name)
  // Output - The second instance with name: John Doe

  console.log('Is same instance? ', instanceOne === instanceTwo)
  // Output - Is same instance?  true
}

main()
```

- At first we assign `instanceOne` variable with the instance returned from the `singleton.getInstance()`
- Then we set the `name` from `instanceOne` with value is `John Doe`
- After that, we create another constant `instantTwo` with the `singleton` object again.
- This time we will make a compare from the value to the instance, from the output that we can see the `name` from `instanceTwo` is same as the value we already set from `instanceOne` (is `John Doe` and is not `undefined` value), and both instance is the same with the returned is `true`.

## Pros and Cons

### Pros

- You can be sure that a class has only a single instance.
- A global access point to that instance.
- The singleton only initialized once.

### Cons

- The Singleton is violate to the Single Responsibility Principle, via the SRP definition that a class only should only have one responsibility. But with the singleton pattern, it can carry too many responsibilities at the same time, this can make a deadlock when used in concurrency / multi-threads.
- The singleton design is getting us difficult to write the unit test.

## Conclusion

With the only initialized once and can use in the global context, the singleton design pattern is very useful for some specific cases where we only need to store the data that using in the global and fewer changes like database connection, user profile account config...


The Singleton design pattern is a design pattern that restricts the instantiation of a class to one object.

Singleton Design Pattern in Javascript


Frontend development has become increasingly complex over the years, and with it, the need for efficient state management. Global State is one such programming pattern that has emerged as a solution to the problem of prop drilling. Prop drilling is the process of passing data through multiple levels of nested components, which can make code difficult to maintain. By managing and sharing state across multiple components, Global State reduces the need to pass data through each component, resulting in cleaner and more maintainable code.

While Global State is convenient, it has its limitations, particularly when it comes to server-state data. Most applications consume and manipulate data from synchronous and asynchronous sources, commonly referred to as Client State and Server State. Historically, developers have treated both types of state as Global State.

```js
const globalState = {
  // Client state
  isMenuOpen: false,
  alerts: [...],
  // Server state
  user: {...},
  cart: {...},
  orders: [...],
  customers: [...],
  ...
}
```

However, Server State and Client State differ in nature. While Client State is entirely controlled by the client, Server State is remotely persisted. The source of truth is outside of the application's control, and when dealing with data that changes frequently, it's crucial to keep Global State in sync with the remote world. This synchronization requires dealing with caching, outdated requests, updating data in the background, and memory management—factors that ensure efficient data handling and prevent performance issues.

Redux users may already be familiar with the challenges of storing API responses in Global State, which requires boilerplate code to handle loading state, error state, and revalidation when data becomes stale.

Fortunately, libraries are available to deal with Server State more effectively than Global State. Two popular libraries among developers are [SWR](https://swr.vercel.app/) and [React-Query](https://react-query-v3.tanstack.com/). While these libraries have differences, their purpose is the same: to provide a simple interface for storing asynchronous data and abstract away the complexity of dealing with server-state data.

Consider the following code comparison between Redux and React-Query:

```js
// Redux
export const fetchUser = createAsyncThunk('user/fetchUser', async () => {
  const response = await fetch('/api/user');
  const data = await response.json();
  return data;
});

const userSlice = createSlice({
  name: 'user',
  initialState: { data: {}, loading: false, error: null },
  reducers: { ... },
  extraReducers: (builder) => {
    builder.addCase(fetchUser.pending, (state) => {
      state.loading = true;
      state.error = null;
    });
    builder.addCase(fetchUser.fulfilled, (state, action) => {
      state.loading = false;
      state.data = action.payload;
    });
    builder.addCase(fetchUser.rejected, (state, action) => {
      state.loading = false;
      state.error = action.error.message;
    });
  },
});

// React-Query
const { data, isLoading, error } = useQuery('user', fetch('/api/user'))
```

In this comparison, Redux requires more lines of code and additional boilerplate to handle loading and error states. On the other hand, React-Query simplifies the process significantly, making it easier for developers to maintain the code.

In conclusion, Global State management is useful in many ways, but its limitations should be considered when deciding whether to use it. If state comes from Server sources, it's important to assess whether it should be treated as Global State or not. In cases where dealing with server-state data is necessary, libraries like SWR and React Query can simplify the process by abstracting the complexities.


Frontend development has become increasingly complex over the years, and with it, the need for efficient state management.

Tackling Server State complexity in Frontend Development


The key to improving your website speed is to understand where the bottlenecks are, and how much time each step takes. When we talk about web performance basically we talk about either the two aspects: network latency and browser rendering.

## Network latency

Network latency is related to how long it takes for a request to be sent from your computer to the server and back again, and then rendered by the browser. It is affected by many factors, including your ISP speed, DNS lookup, TCP handshakes, the number of hops between you and the server, request processing time on the server and so on. If your website uses a lot of static assets (images, videos, etc), it will take longer for all of these requests to be sent over the network, which can negatively impact page load times.

There are numerous ways to improve network latency but following are the key points:

- Locate the server close to the client
- Reduce server response time (logic optimization, setup cache layer,...)
- Make file size smaller by using techniques such as code splitting or compressor
- Preload resources using resource hint
- Use a CDN

## Browser rendering

Browser rendering is how long it takes for your browser to display your page after receiving all of its data. The process contains a series of steps that the browser performs on a web page to display on the screen. Each of these individual steps is complex and has been optimized over time by browser vendors.

There are many different browsers out there, but they all perform the same basic set of steps when rendering a webpage. These steps can be broken down into 2 parts:

- Parsing static assets (HTML, CSS, JS)
- Running pixels-to-screen pipeline

Parsing is a static process that doesn't depend on the state of the application. The browser needs to read your HTML and CSS and map them into an internal tree structure. This tree is then used to render the page on screen. This phase is usually very fast, but it does take time - especially if you have a lot of HTML, CSS and JavaScript in your page. The steps in this phase includes:

- Construct Document Object Model (DOM) based on the HTML
- Construct Cascading Style Sheet Object Model (CSSOM) based on the CSS
- Combine DOM and CSSOM to generate the render tree. It has all the style properties for every node of the DOM that is needed to be rendered.

![](assets/the-fundamental-of-web-performance-render-tree.webp)

In addition to parsing, browsers also run pixel pipelines on each frame. Pixel pipelines are basically a bunch of algorithms that take information from the DOM and apply it onto the screen. For example: painting backgrounds (CSS), applying effects (SVG filters) or animating things (CSS transitions). These algorithms are executed every single time there's a change in state (e.g. scroll position changes), causing them to be executed many times per second - even if nothing has changed. There are five major areas that you need to know about and be mindful of when you work

- **JavaScript**: JavaScript execution normally is used to modify the DOM. For example, you can add event listeners or create new elements.
- **Style calculations**: The browser determines which CSS rules apply to which elements.
- **Layout**: The browser figures out where each element should be positioned on the screen (which includes things like width, height and position).
- **Paint**: Once the layout has been calculated, the browser paints every visible element on the screen.
- **Compositing**: Once all elements have been painted, they are combined together into one image that contains everything that will be displayed onscreen at once — known as a frame.

![](assets/the-fundamental-of-web-performance-pixel-pipeline.webp)

The goal of delivering a fast, smooth transition web application is **to do less work** during the rendering process. You need to understand how HTML, JavaScript and CSS are handled by browsers as each phase occurs. Then ensure that the code you write (and the other 3rd party code you include) runs as efficiently as possible. For example, to reduce the amount of time it takes for style calculations to be completed, understand [CSS specificity](https://web.dev/learn/css/specificity/) so you can write simple class names and reduce the number of styles that affect a given element.

## Reference

- [Katie Sylor Miller :: Happy Browser, Happy User!](https://www.youtube.com/watch?v=VAKD_Ob0XTQ&t=568s&ab_channel=estellevw)
- https://web.dev/rendering-performance/
- https://codeburst.io/painting-and-rendering-optimization-techniques-in-browser-2e53a70e7ee
- https://web.dev/critical-rendering-path-render-tree-construction/


The key to improving your website speed is to understand where the bottlenecks are, and how much time each step takes.

The fundamental of web performance


**ThreeJS** is a JavaScript 3D library that allows developers to develop and describe data in 3 dimensions, and then convert them into 2 dimensions and display them on [HTML Canvas](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement). [**Camera**](https://threejs.org/docs/index.html?q=camera#api/en/cameras/Camera) is one of the core elements of a ThreeJS project, beside [Scene](https://threejs.org/docs/index.html?q=scene#api/en/scenes/Scene), [Renderer](https://threejs.org/docs/index.html?q=renderer#api/en/renderers/WebGLRenderer) and 3D objects (can be formed with [Geometries](https://threejs.org/docs/index.html?q=geometry#api/en/geometries/BoxGeometry) and [Materials](https://threejs.org/docs/index.html?q=material#api/en/materials/MeshBasicMaterial)).

This article gives basic information about characteristics of the frequently used types of camera in ThreeJS.

## Most commonly used types of camera in ThreeJS

You cannot use the `Camera` class directly to initialize a new camera in ThreeJS. Instead, use the `PerspectiveCamera` or `OrthographicCamera` specifically. The **perspective camera** gives information about depth, distances, etc. since it represents perspective in **real life**. On the other hand, with an **orthographic camera**, all sizes are projected the same way and we can easily compare them accurately.

The image below shows the object viewed in **perspective camera** (upper) and in **orthographic camera** (lower).

![](assets/cameras-in-threejs_va74b4e.webp)

Place them into the **Oxyz** coordinate...

![](assets/cameras-in-threejs_uioctax.webp)

### Perspective camera

![](assets/cameras-in-threejs_oipfgw7.webp)

Some crucial attributes:

- **fov** (field of view): Camera frustum **vertical** field of view, i.e. the angle of the view in the yOz plane, in degree. The lower the number, the narrower the view. ![](assets/cameras-in-threejs_zkoiiim.webp)
- **near** and **far**: Clipping planes at 2 points on the z axis. Note that objects with z position outside the `(near, far)` interval will **not** be displayed.

```javascript
const camera = new THREE.PerspectiveCamera(45, 16 / 9, 1, 1000)
scene.add(camera)
```

In the example above, a perspective camera is initialized with `fov` of 45 degree, `aspect-ratio` of 16 / 9, `near` and `far` of 1 and 1000 respectively.

Perspective camera visualization from [r105.threejsfundamentals.org](https://r105.threejsfundamentals.org/threejs/threejs-cameras-perspective-2-scenes.html) with [`CameraHelper`](https://threejs.org/docs/index.html?q=camera#api/en/helpers/CameraHelper):

<iframe height="400" style="width: 100%;" scrolling="no" title="ThreeJS - Cameras - Perspective 2 views" src="https://codepen.io/nguyend-nam/embed/abGmYBp?default-tab=result" frameborder="no" allowfullscreen="true"></iframe>

### Orthographic camera

![](assets/cameras-in-threejs_cx1u9zi.webp)

Some crucial attributes:

- **left**, **right**, **top** and **bottom**: Horizontal and vertical position of 4 segments of the view.
- **near** and **far**: Same as for perspective camera.

```javascript
const camera = new THREE.OrthographicCamera(-2, 2, 1, -1, 1, 1000)
scene.add(camera)
```

In the example above, an orthographic camera is initialized with `left`, `right`, `top` and `bottom` equal -2, 2, 1 and -1 respectively. The last 2 numbers represent `near` and `far`.

Orthographic camera visualization from [r105.threejsfundamentals.org](https://r105.threejsfundamentals.org/threejs/threejs-cameras-orthographic-2-scenes.html) with [`CameraHelper`](https://threejs.org/docs/index.html?q=camera#api/en/helpers/CameraHelper):

<iframe height="400" style="width: 100%;" scrolling="no" title="ThreeJS - Cameras - Orthographic 2 views" src="https://codepen.io/nguyend-nam/embed/BaxLrWv?default-tab=result" frameborder="no" allowfullscreen="true"></iframe>

## Other types of camera

Beside those 2 most frequently used cameras, ThreeJS also provides various options:

- [ArrayCamera](https://threejs.org/docs/index.html?q=camera#api/en/cameras/ArrayCamera)
- [CubeCamera](https://threejs.org/docs/index.html?q=camera#api/en/cameras/CubeCamera)
- [StereoCamera](https://threejs.org/docs/index.html?q=camera#api/en/cameras/StereoCamera)

## Reference

- https://threejs.org/docs/index.html?q=camera#api/en/cameras/Camera
- https://r105.threejsfundamentals.org/threejs/lessons/threejs-cameras.html
- https://www.vectorstock.com/royalty-free-vector/isometric-and-perspective-drawings-vector-7297379
- https://wiki.freecadweb.org/index.php?title=File:Orthographic_Perspective.gif
- https://www.celestron.com/blogs/knowledgebase/what-is-the-field-of-view-of-a-pair-of-binoculars


**ThreeJS** is a JavaScript 3D library that allows developers to develop and describe data in 3 dimensions, and then convert them into 2 dimensions and display them on [HTML Canvas](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement). [**Camera**](https://threejs.org/docs/index.html?q=camera#api/en/cameras/Camera) is one of the core elements of a ThreeJS project, beside [Scene](https://threejs.org/docs/index.html?q=scene#api/en/scenes/Scene), [Renderer](https://threejs.org/docs/index.html?q=renderer#api/en/renderers/WebGLRenderer) and 3D objects (can be formed with [Geometries](https://threejs.org/docs/index.html?q=geometry#api/en/geometries/BoxGeometry) and [Materials](https://threejs.org/docs/index.html?q=material#api/en/materials/MeshBasicMaterial)).

Cameras in ThreeJS


## Why?

With the rise of social platforms like Facebook, Twitter and LinkedIn, it's easier than ever to share URLs with a large audience quickly and efficiently. However, each social network has its own unique way of handling URLs, and understanding the correct formatting can make a significant difference in the visibility and engagement of your shared content.

## Facebook

```javascript
;`https://www.facebook.com/sharer.php?u=${url}`
```

This format allows you to share a specific URL with your [Facebook](https://about.meta.com/technologies/facebook-app/) friends and followers. By replacing `url` with the actual URL, you can create a link that shows a dialog with the content you want to share.

![](assets/url-formats-for-sharing-via-social-networks_hmijfth.webp)

## Messenger

Sharing via [Messenger](https://about.meta.com/technologies/messenger/) is another way to share a URL with your Facebook friends and contacts.

```javascript
;`https://www.facebook.com/dialog/send?app_id=${appId}&display=popup&link=${url}&redirect_uri=${url}`
```

To use this format, you'll need to replace `${appId}` with your Facebook app ID and `${url}` with the URL you want to share.

> Follow this [documentation](https://developers.facebook.com/docs/development/create-an-app) to create a Facebook app and get the app ID.

![](assets/url-formats-for-sharing-via-social-networks_yrq15em.webp)

## Zalo

To share a URL via [Zalo](https://zalo.me/pc), a widely used messaging app in Vietnam, you need to create a JSON object containing a key of `"url"` and the value of the URL you want to share. Then stringify and encode the string in the base64 format.

```javascript
function encodeB64(str: string) {
  return window.btoa(str)
}

const sharingUrl = `https://button-share.zalo.me/share_external?d=${encodeB64(JSON.stringify({ url }))}`
```

![](assets/url-formats-for-sharing-via-social-networks_5gtifrk.webp)

## Other platforms

Check out some other formats that allow you to share a URL via some social networks.

| Platform | URL format                                                              |
| -------- | ----------------------------------------------------------------------- |
| LinkedIn | <pre>`https://www.linkedin.com/sharing/share-offsite/?url=${url}`</pre> |
| Twitter  | <pre>`http://twitter.com/share?url=${url}`</pre>                        |
| Telegram | <pre>`https://telegram.me/share/?url=${url}`</pre>                      |
| Reddit   | <pre>`https://www.reddit.com/submit?url=${url}&title=${title}`</pre>    |


Each social network has its own unique way of handling URLs, and understanding the correct formatting can make a significant difference in the visibility and engagement of your shared content.

URL formats for sharing via social networks


In the React 18 version, the `useEffect` hook has been updated to called twice compare to only one in the older version in StrictMode.

### What are the changes and why?

- Beginning with React 18, when in development mode, the components will be mounted, unmounted, and then mounted once again in StrictMode.
- In the future, React would support a functionality that allows React to add and remove sections of the UI while maintaining state in the future. For example, when a user back history from a screen and then revisit it, React should be able to show the previous screen right away. React would do this by un-mounting and re-mounting trees with the same component state as before.
- This functionality will improve the performance of React projects out of the box, but necessitate components to be resilient to effects being mounted and un-mounted several times. The majority of effects will operate as-is, however some will presume they are only mounted or destroyed once (which means the new behavior might cause trouble for the existing use of useEffect that intends to trigger mount and unmount once).
- React 18 adds a new development-only check in StrictMode to identify these issues. After a component mounts for the first time, this new check will immediately unmount and remount it, restoring the previous state on the second mount.

### What are the differences?

- In React 17 the useEffect hook gets call every time the component is mounted.
- In React 18 each component is mounted, then unmounted, and then remounted and an useEffect call with no dependencies will be run double-time in strict mode.

### Example of useEffect in React 18

We can confirm the behavior by using the cleanup function of the useEffect hook.

```js
useEffect(() => {
  console.log('Hello Dwarves!')
  return () => console.log('Cleanup..')
}, [])
```

The output to the console should look like this:

```sh
Hello Dwarves!
Cleanup..
Hello Dwarves!
```

**Solution**

Embrace the double-firing and make sure your clean up function works (so double-firing in development doesn't hurt).

**Get around (not recomended)**

You can create a custom hook so that the useEffect get called only once, although this approach can cause leaks and overall not the best practice in engineering.

```ts
export const useEffectOnce = (effect: () => void | (() => void)) => {
  const destroyFunc = useRef<void | (() => void)>()
  const effectCalled = useRef(false)
  const renderAfterCalled = useRef(false)
  const [val, setVal] = useState<number>(0)

  if (effectCalled.current) {
    renderAfterCalled.current = true
  }

  useEffect(() => {
    // only execute the effect first time around
    if (!effectCalled.current) {
      destroyFunc.current = effect()
      effectCalled.current = true
    }

    // this forces one render after the effect is run
    setVal((val) => val + 1)

    return () => {
      // if the comp didn't render since the useEffect was called,
      // we know it's the dummy React cycle
      if (!renderAfterCalled.current) {
        return
      }
      if (destroyFunc.current) {
        destroyFunc.current()
      }
    }
  }, [])
}
```

#### Reference

- https://reactjs.org/blog/2022/03/29/react-v18.html#new-strict-mode-behaviors
- https://www.techiediaries.com/react-18-useeffect/
- https://dev.to/ag-grid/react-18-avoiding-use-effect-getting-called-twice-4i9e


In the React 18 version, the `useEffect` hook has been updated to called twice compare to only one in the older version in StrictMode.

useEffect double calls in React 18


## Website Accessibility

Website Accessibility is a term for approaching a website of which the potential user are people with disabilities (eye disorders or illiterate). This audience type can’t be able to approach a visualize website. They must depend on keyboard or Screen Reader supporting tool instead.

Website Accessibility is also a factor to evaluate the website quality of Google Lighthouse. Developers can enhance the accessibility of a website by categorizing the current elements, as long as the reader system can identify and have those elements delivered to readers.

## Why we need to use the correct HTML

For example, a control button to play a video on your site could be marked up like this:

```javascript
<div>Play video</div>
```

But as you'll see in greater detail later on, it makes sense to use the correct element for the job:

```javascript
<button>Play video</button>
```

Not only do HTML `<button>`s have some suitable styling applied by default (which you will probably want to override), they also have built-in keyboard accessibility — users can navigate between buttons using the Tab key and activate their selection using `Return` or `Enter`.

Semantic HTML doesn't take any longer to write than non-semantic (bad) markup if you do it consistently from the start of your project. Even better, semantic markup has other benefits beyond accessibility:

1. **Easier to develop with** — as mentioned above, you get some functionality for free, plus it is arguably easier to understand.
2. **Better on mobile** — semantic HTML is arguably lighter in file size than non-semantic spaghetti code, and easier to make responsive.
3. **Good for SEO** — search engines give more importance to keywords inside headings, links, etc. than keywords included in non-semantic `<div>`s, etc., so your documents will be more findable by customers.


Using the correct HTML element can significantly improve the accessibility of your website.

Using Correct Html Element To Increase Website Accessibility


**Zod** is the TypeScript-first schema validation library with static type inference. It's functional approach to data validation is [parse-dont-validate-in-typescript]() which parses the data in order to validate and catch errors.

## Why use Zod?

- **TypeScript Support:** Zod has TypeScript support, which lets developers to detect type issues early on, making it easier to discover and repair bugs.
- **Improved data quality:** Developers may guarantee that the data they are working with is in the right format and fulfills particular restrictions by utilizing Zod to validate and coerce input data. This can assist to reduce mistakes and enhance data quality overall.
- **Simplified code:** Developers may easily design and maintain validation code because to Zod's clear and simple syntax for constructing schemas. This can assist to decrease the amount of boilerplate code required and make it easier to reason about the data flowing through an application.
- **Flexibility:** Zod may be used in a number of situations, including online forms, REST APIs, and others. It also allows developers to construct custom validation methods, allowing them to validate data using their own business logic.
- **Lightweight:** Zod is a lightweight library with no external dependencies.
- **Cross-platform:** Zod works in both browser and Node.js, allowing it to be utilized in a wide range of applications and environments.

## How to use Zod

### Example using validate method

```ts
const z = require('zod')

// Define a schema for the input data
const schema = z.object({
  name: z.string(),
  phone_number: z.number().min(0).max(12),
  email: z.string().email(),
})

// Input data to be validated and coerced
const input = {
  name: 'Dwarves Foundation',
  phone_number: 123456,
  email: 'team@dwarves.foundation',
}

// Validate and coerce the input data
const data = schema.validate(input)
console.log(data)
/*
{
  name: 'Dwarves Foundation',
  phone_number: 123456,
  email: 'team@dwarves.foundation',
}
*/
```

In this example, we define a schema using the Zod library that specifies the types and constraints for the input data. The `schema.validate(input)` function is used to validate and coerce the input data to match the schema. If the input data is valid and meets all the constraints defined in the schema, it will be returned in a proper format, otherwise it will throw an error with the validation issues.

In this case, the input data is an object that has a name, phone number, and email address. According to the standard, the name and email should be strings, and the phone number should be a number between 0 and 12.

It also ensure that the email is valid email.

This way the application can be sure that the data it is receiving is in the correct format, and that any issues with the data will be caught early on.

### Example using parse method

The `parse()` method in the Zod validation library is used to parse and validate input data, and return the parsed data in the correct format. It is similar to the `validate()` method, but it also removes any extra properties from the input data that are not defined in the schema.

```ts
const z = require('zod');

// Define a schema for the input data
const schema = z.object({
  name: z.string(),
  phone_number: z.number().min(0).max(12),
  email: z.string().email(),
});

// Input data to be parsed and validated
const input = {
  name: 'Dwarves Foundation',
  phone_number: 123456
  email: 'team@dwarves.foundation',
  extra_property: 'This should not be included in the output'
};

// Parse and validate the input data
const data = schema.parse(input);
console.log(data);
/*
{
  name: 'Dwarves Foundation',
  phone_number: 123456,
  email: 'team@dwarves.foundation',
}
*/
```

In this example, the input data contains an extra property `extra_property` which is not defined in the schema, it will be removed from the parsed data, resulting in a cleaner object without any unnecessary properties.

`parse()` method is useful when the input data may contain extra properties that are not needed by the application. It also ensures that the input data matches the schema and that any issues with the data will be caught early on.

It's also worth mentioning that, like `validate()`, if the incoming data does not match the schema, `parse()` will throw an exception indicating the validity issues.

## Zod vs Yup

**Zod** and **Yup** are both JavaScript libraries for data validation, but they have some key differences:

- Syntax: Zod and Yup have different syntax for defining schemas. Zod uses a fluent interface with a chainable API, while Yup uses a plain object to define the schema.
- TypeScript Support: Zod is built with TypeScript, which means it has excellent typings, making it easy to use in a TypeScript environment. Yup does not have built-in TypeScript support, but it can be used in a TypeScript environment with the use of an additional package.
- Error message: Yup allows to specify custom error messages for each field, which can be useful for displaying error messages to the end-user. Zod, on the other hand, does not provide a way to specify custom error messages.
- Utility functions: Zod provides a number of utility functions such as the ability to extract values from an object based on a schema, and to create an object with default values based on a schema. Yup does not have similar utility functions.
- Performance: Zod is smaller in size and it's faster than Yup, which means it could be a better choice for applications that need to handle a large amount of data validation.
- Popularity: Yup is more popular than Zod because it's been around longer and has a larger community of developers.

Both Zod and Yup are robust validation libraries, and the choice between them is based on your project's specific demands, syntax preference, and the capabilities that you require.

## References

- <https://zod.dev/>
- <https://github.com/jquense/yup>
- <https://blog.logrocket.com/comparing-schema-validation-libraries-zod-vs-yup/>
- <https://blog.logrocket.com/schema-validation-typescript-zod/>


Zod is the TypeScript-first schema validation library with static type inference.

Validation with Zod


## What's variable font?

Variable fonts - officially known as OpenType Font Variations - are a font format that allows for a single font file to contain multiple variations of a typeface, such as different weights, widths, and styles, that can be dynamically adjusted in real-time using font variations.

![](assets/variable-fonts_variable_fonts_01.webp)

Weights, widths and other properties are also called **"axes" of variations**.

### Axes of Variations

In typography and font design, "axes of variation" refer to the different characteristics or parameters of a font that can be modified or adjusted to create different font styles or variations. These variations can include parameters such as font weight, width, slant, optical size, and more.

Each axis of variation defines a range of possible values, and any combination of values within that range can be used to create a unique font style or variation.

> For example, the weight axis of a variable font might range from "Thin" to "Bold," and any value within that range can be selected to create a font style with a corresponding weight.

![](assets/variable-fonts_variable_fonts_02.webp)

By adjusting these parameters within a defined range, designers can create custom font styles that fit their specific design needs.

<video src="https://storage.googleapis.com/web-dev-assets/variable-fonts/roboto-dance.mp4" controls autoplay></video>

These variations are also dependent on how the fonts were designed and built. Designers and developers should refer to the font's documentation or its creator to understand which variations are available and how they can be used.

## Why should we use variable fonts?

- **Size and efficiency**: Font variations are contained within a single font file, leading to smaller file sizes and faster load times.
- **Flexibility, customization, precision and control**: By allowing manipulating of various variation axes to match our needs
- **Creativity**: Variable fonts provide designers with new opportunities to experiment and create unique font designs, resulting in visually distinct and more memorable typography

## Examples on variable fonts

The best way to understand variable fonts is to start playing with them. Below are some examples from [an article](introducing-variable-fonts-fonts-knowledge-google-fontshttps/fontsgoogle.com/knowledge/introducing_type/introducing_variable_fonts) from Google Fonts to get you started.

Go to [etceteratype.co/epilogue](https://etceteratype.co/epilogue) and play with the **weight** axis of Epilogue to see how it affects the overall spacing of the ![](assets/variable-fonts_variable_fonts_03.webp)

Now go to [etceteratype.co/grandstander](https://etceteratype.co/grandstander) and compare that with Grandstander, which was designed to take up the same amount of horizontal space regardless of changes made to the weight axis. This shows how what happens within an axis of variation is determined by the typeface designer.

![](assets/variable-fonts_variable_fonts_04.webp)

Go to [etceteratype.co/anybody](https://etceteratype.co/anybody) and play with the weight **and** width axes on Anybody, to see how they can be combined, and how they affect each other in a subtle way:

![](assets/variable-fonts_variable_fonts_05.webp)

You can also visit these websites:

- [VariableFonts.io](https://variablefonts.io/)
- [VariableFonts.TypeNetwork.com](https://variablefonts.typenetwork.com/)
- [Axis-Praxis](https://www.axis-praxis.org/)
- [Variable Fonts](https://v-fonts.com/)
- [Font Playground](https://play.typedetail.com/)
- [Very Able Fonts](https://www.very-able-fonts.com/)

## How do we use variable fonts (as a developer)?

### Load the fonts

Variable fonts are loaded though the same `@font-face` mechanism as traditional static web fonts, with a new enhancement:

```css
@font-face {
  font-family: 'Roboto Flex';
  src: url('RobotoFlex-VF.woff2') format('woff2') tech('variations'), url('RobotoFlex-VF.woff2') format('woff2-variations');
}
```

We don't want the browser to download the font if it doesn't support variable fonts, so we add format and tech descriptions: once in the future syntax `(format('woff2') tech('variations'))`, once in the deprecated but supported among browsers syntax `(format('woff2-variations'))`. They both point to the same font file.

### Using variation axes

To set value for the variations, we use `font-variation-settings`, specifying an array of `{{axis tag}} {{value}}` pairs:

```css

@font-face {
  ...
  font-variation-settings: 'wght' 500, 'GRADE' 0.5;
}
```

You will notice that in the example above, 1 tag is lowercase, and the other is uppercase. It is to differentiate between **registered axes** & **custom axes**. Registered axes will always be lowercase, whereas custom axes will always be uppercase.

By default, there are 5 [registered axes](https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg#registered-axis-tags), which control known, predictable features of the font:

- Weight - `wght`
- Width - `wdth`
- Optical size - `opsz`
- Slant - `slnt`
- Italics - `ital`

Beyond that, we depends on how the fonts were built & what custom axes they are using. Check out [this site](https://v-fonts.com/fonts/roboto-flex) for another good example on all the axes a font can have.

![](assets/variable-fonts_variable_fonts_06.webp)

## References

- https://www.youtube.com/watch?v=0fVymQ7SZw0&list=WL&index=1&t=247s&ab_channel=KevinPowell
- https://fonts.google.com/knowledge/introducing_type/introducing_variable_fonts
- https://web.dev/variable-fonts/


Variable fonts are a font format that allows for a single font file to contain multiple variations of a typeface.

Variable Fonts


Before ES modules was supported in the browser, we have no native mechanism for authoring [javascript-modules]() in a modularized fashion. That is why the concept of **"bundling"** and tools like Webpack, Rollup, and Parcel exist to improve the development experience for frontend developers.

However, when our project started to expand more, the amount of modules might increase from a hundred to thousands of modules which lead to performance bottleneck for **JavaScript-based** toolings.

### Why Vite faster

Vite takes full advantage of the availability of native ES modules in the browser and the rise of JavaScript tools written in compile-to-native languages by introducing `pre-bundles dependancies` using `esbuild` which was written in Go which is 10-100x faster than JavaScript-based bundlers.

### Server built architecture

#### Bundle based dev server

Bundle-based dev server like Webpack built your application by combining all the source-code and modules into a JavaScript-based bundle, everything is done on the server-side and when you change something, the entire application has to build from the start.

![](assets/bundler.37740380.png)

#### Native ESM based dev server

Vite's approach was instead of bundling all everything on the server, it only bundles modules when the browser requires them through HTTP request.

This architecture provides a faster dev server by avoiding bundling all the application on the server and utilizing the power of modules handling of the browsers.

![](assets/esm.3070012d.png)

### Update when built

Rebuilding the whole bundle after making changes to your source code in a bundler-based build system is inefficient for the obvious reason that the update speed would degrade linearly with the app's size.

**HMR (Hot module replacement)** is applied to native ESM in Vite. Vite consistently performs HMR updates quickly regardless of the size of your application by only needing to precisely invalidate the chain between the updated module and its nearest HMR boundary when a file is changed.

### Why Bundle for Production

Despite the fact that native ESM is now generally supported, deploying unbundled ESM in production is still wasteful (even with HTTP/2) since nested imports require extra network round trips. It is still preferable to bundle your code with tree-shaking, lazy-loading, and common chunk splitting to get the best loading performance in production (for better caching).

### Why not bundle with ESBuild?

While `esbuild` is lightning-quick and a very capable bundler for libraries, some crucial features required for bundling apps, specifically code-splitting and CSS handling, are still **under development**. `Rollup` is currently more capable and adaptable in several areas and being used in production.

### References

- https://vitejs.dev/guide/why.html
- https://www.telerik.com/blogs/whats-vite-guide-modern-super-fast-project-tooling


ViteJS takes full advantage of the availability of native ES modules in the browser and the rise of JavaScript tools written in compile-to-native languages by introducing pre-bundles dependancies using esbuild.

ViteJS native modules


Since modern websites and applications contain huge amounts of dynamic content and complex components with no semantics to describe what they mean, users with disabilities, those dependent on **assistive technologies** such as **[Screen Reader](https://chrome.google.com/webstore/detail/screen-reader/kgejglhpjiefppelpmljglcjbhoiplfn/related?hl=en)**, text-to-speech or screen magnification tools might suffer to interact with those components.

Web Accessibility Initiative’s Accessible Rich Internet Applications or simply **WAI-ARIA** is a technology that can help with such problems.

## What is WAI-ARIA?

Before semantic elements like `<nav>` or `<footer>` were introduced that define specific features of a web page, some developers would rely on JavaScript libraries that generate a bunch of **nested `<div>`s**, then styled them with CSS and controlled with JavaScript.

The website still works fine and behaves normally. The problem comes when the site is used by a user dependent on assistive technologies, tools that help users with disabilities interact with websites (by speaking the content or information out loud, zoom into the content at the cursor position etc.). If those tools cannot make any sense of what the components are since no semantics were provided, they cannot assist their users. WAI-ARIA provides 3 main features: **Roles**, **States** and **Properties** to solve this problem, giving an opportunity to add attributes to content and components that make them **meaningful** and enhance **accessibility**.

### Roles:

WAI-ARIA roles define **what that HTML is or does**, add the required additional information in cases the markup does not provide the required role. If we write `<a role="button">`, the screen reader will recognize it as a button. You can also use roles to describe sections on a web page such as `navigation`, `main` or `banners` etc.

> Detailed documentation about **WAI-ARIA Roles** from MDN [[here](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles)]

```javascript
<ul role="menu">
  <li role="menuitem" aria-selected="true" tabindex="0">
    Home
  </li>
  <li role="menuitem" aria-selected="false" tabindex="0">
    About
  </li>
  ...
</ul>
```

We can have `button`s, `tab`s,... representing widget roles working as part of larger components, or `heading`, `row`, `rowgroup`,... describing content structure in a page.

### Properties:

Represent the **data value associated** with the object. When combined with roles, the user agent can supply the assistive technologies with user interface information to convey to the user at any time. Properties are **less** likely to change. `aria-label`, `aria-required` and `aria-describedby` are some instances for WAI-ARIA properties.

> Detailed documentation about **WAI-ARIA States & Properties** from MDN [[here](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes)]

```javascript
<form>
	<label for="name">Enter your name:</label>
	<input type="text" name="name" aria-label="Name input" aria-required="true" placeholder="Your name">

	<label for="age">Enter your age:</label>
	<input type="number" name="age" aria-label="Age input" aria-required="true" placeholder="Your age">

	<input type="submit">
</form>
```

### States:

Have the same characteristics as properties, except for one thing that states are frequently changed during the life cycle of the component. Some commonly used WAI-ARIA states are `aria-pressed`, `aria-expanded`, `aria-selected`,...

```javascript
<ul role="tablist">
  <li class="active" role="tab" aria-selected="true" tabindex="0">
    Tab 1
  </li>
  <li role="tab" aria-selected="false" tabindex="0">
    Tab 2
  </li>
  <li role="tab" aria-selected="false" tabindex="0">
    Tab 3
  </li>
</ul>
```

Below is a small demonstration, you can add this [Screen Reader extension](https://chrome.google.com/webstore/detail/screen-reader/kgejglhpjiefppelpmljglcjbhoiplfn/related?hl=en) and interact with it to know how WAI-ARIA helps enhance accessibility before reading further about benefits of using it:

<iframe height="400" style="width: 100%;" scrolling="no" title="WAI-ARIA" src="https://codepen.io/nguyend-nam/embed/XWqZPPE?default-tab=result" frameborder="no" allowfullscreen="true"></iframe>

## Why use WAI-ARIA?

Note that WAI-ARIA attributes **do not** change the behavior of the supplied component, they do not affect anything about the web page. The difference is that the [browser's accessibility APIs](https://wiki.mozilla.org/Accessibility/WebAccessibilityAPI) will expose that information and the assistive technologies can rely on that information to enhance users' accessibility.

WAI-ARIA will become handy in some cases as listed below:

- WAI-ARIA roles are useful when defining specific **regions on a web page** (e.g. banner, navigation, main,...). ![](assets/wai-aria_r1s3rbm.webp)

- `aria-live` can inform screen reader users when a component is **dynamically updated**.
<iframe height="400" style="width: 100%;" scrolling="no" title="WAI-ARIA" src="https://codepen.io/nguyend-nam/embed/WNJKEvy?default-tab=result" frameborder="no" allowfullscreen="true"></iframe>

- Strong support **keyboard users**: some HTML elements already have built-in keyboard accessibility (e.g. `<buttons>`, `<inputs>`,... where users can navigate to using tab key), but some need JavaScript along with to do that. WAI-ARIA provides `tabindex` attribute to allow focusing on those elements.
- **Improve accessibility** of non-semantic components: as modern web pages are getting more and more complex, UI components might have a bunch of nested `<div>`s inside. WAI-ARIA helps cover that with roles (e.g. button, tablist), it also improves functionality (e.g. `aria-required`).

## Reference

- https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics
- https://www.maxability.co.in/trainings/advanced-web-accessibility-testing/what-is-wai-aria
- https://www.w3.org/WAI/ARIA/apg/example-index/button/button
- https://pressbooks.library.torontomu.ca/wafd/chapter/wai-aria-landmarks/#:~:text=WAI%2DARIA%20landmarks%20are%20used,bypass%20links%20and%20page%20headings


WAI-ARIA is a technology that can help with the problems of modern websites and applications containing huge amounts of dynamic content and complex components with no semantics to describe what they mean.

WAI-ARIA


### What

WebAssembly (abbreviated *Wasm*) was launched in 2017 as a low-level assembly-like language with a compact binary format, so it’s fast to load, execute, and run with near-native performance. It is designed as a portable target for the compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications. That means you do not write WebAssembly, you compile other high-level languages to it.

![](assets/webassembly_wasm-architecture.webp)

### How

With JavaScript, the code is included in the website and is interpreted as it runs because JavaScript variables are dynamic. The only way to know what the types are for sure is to monitor the code as it executes, which is what the JavaScript engine does. Once the engine is satisfied that it knows the variable’s types, it can convert that section of code into machine code.

![](assets/webassembly_wasm-js-how-it-work.webp)

WebAssembly isn’t interpreted but, rather, is compiled into the WebAssembly binary format by a developer ahead of time. Because the variable types are all known ahead of time, when the browser loads the WebAssembly file, the JavaScript engine doesn’t need to monitor the code. It can simply compile the code’s binary format into machine code.

![](assets/webassembly_wasm-how-it-works.webp)

### High-Level Goals

- Be fast, efficient, and portable -- WebAssembly code can run at near-native speed regardless of platform.
- Be readable and easily debuggable -- although WebAssembly is a low-level assembler-like language, it has a human-readable text format. This makes it possible to write, read and debug code yourself.
- Be secure -- Actually, WebAssembly is specified to be run during a safe and sandboxed execution environment. Like other web code, it'll enforce the browser's same-origin and permissions policies.
- Don’t break the web -- WebAssembly is designed so that it plays nicely with other web technologies and maintains backwards compatibility.

### Use Cases

- Image / video editing.
- Peer-to-peer applications (games, collaborative editing, decentralized and centralized).
- Music applications (streaming, caching).
- Live video augmentation.
- VR and augmented reality (very low latency).
- Scientific visualization and simulation.
- Developer tooling (editors, compilers, debuggers, …).
- Fat client for enterprise applications (e.g. databases).

### Reference

https://developer.mozilla.org/en-US/docs/WebAssembly https://webassembly.org/ https://livebook.manning.com/book/webassembly-in-action/chapter-1/ https://www.xenonstack.com/insights/a-beginners-guide-to-webassembly


WebAssembly (abbreviated *Wasm*) was launched in 2017 as a low-level assembly-like language with a compact binary format, so it’s fast to load, execute, and run with near-native performance.

Webassembly


## What are WebSockets

Previously, creating web applications that need bidirectional require a HTTP polling for updating the data from the server. This result in lots of problems such as high overhead, latency, not-truthly realtime.

WebSocket is a simple solution that is invented to solve those problems as it helps to maintain one single TCP connection for traffic in both directions. It currently can work over HTTP port 80, 443 and as proxies as it is designed for addressing the other existing bidirectional HTTP technologies so that take advantage of existing HTTP infrastructure.

## The Protocol Overview

### Handshake

A HTTP Handshake is preformed before update to WebSocket connection. The client makes a GET request to the server with an upgrade header. The server then response with status 101 to upgrade the current connection to be WebSocket connection. Otherwise, the client has to end the connection.

Example handshake

#### From client

```javascript
GET /chat HTTP/1.1
    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
    Origin: http://example.com
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13
```

- `Sec-WebSocket-Key` is to ensure the server support WebSocket protocol, the key is generated random to preven proxy server to cache and follow the communication

#### From server

```javascript
HTTP/1.1 101 Switching Protocols
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
    Sec-WebSocket-Protocol: chat
```

- `Sec-WebSocket-Accept`: is a response key to show server acceptance, the server first take the value of `Sec-Websocket-Key`, append `"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"` _(Globally Unique Identifier)_ and then hashed with SHA-1

### Data Transfer

After the handshake was successful, each side can start sending or receiving data. The data property in WebSocket is `message`. For each message, the browser is only able to send and receive messages as binary or plain text.

WebSocket uses sequential `frames` for transferring message instead of `streaming`. This result in each side can exchange data independently without any blocking.

#### \*Framing

A `Frame` is a small `header` + `payload`, the payload is similiar to other application data such as body of a HTTP message. In most basic form of WebSocket protocols include 2 type of frames:

- Non-control frame:
  - `text` - denotes sending `utf-8` encoded bytes
  - `binary` - sending raw bytes
  - `continue` - sending a continuation fragment of previous message
- Control frame:
  - `close` - denote that wanting to close, or responding to a close
  * `ping`
  * `pong`

_[Read detail here](https://datatracker.ietf.org/doc/html/rfc6455#section-5.2)_

#### \*Authentication

The protocol itself does not specify an authentication method. User can use any other mechanism used in HTTP such as TLS authentication, cookies or authentication Header _(Except for browser client, WebSocket api does not provide a way to modify the client handshake Header)_.

#### \*WebSocket URI

```
ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
```

Note that the differences between `ws` and `wss`is:

- **`ws` use `HTTP` for handshake while `wss` use `HTTPS`**
- Default port for `ws` is 80 and `wss` is port 443

## WebSocket Browser API

The browser provide an API for creating and managing WebSocket connection as well as exchange messages with a WebSocket server.

### Open WebSocket connection

We can instantiate a new WebSocket connection, linking to the WebSocket server, and it will start connecting immediately.

```typescript
const socket = new WebSocket('ws://localhost:8080')
```

### WebSocket Events

In total, there are 4 events we can listen to are `open`, `message`, `error`, and `close`.

```typescript
// Connection opened
socket.addEventListener('open', (event) => {})
// Receive messages from server
socket.addEventListener('message', (event) => {})
// Connection Error
socket.addEventListener('error', (event) => {})
// After connection closed
socket.addEventListener('close', (event) => {})
```

**Sending message** The `socket.send(body)` method allow sending a message to the server. The `body` argument can be a `string` or `binary format type` such as `ArrayBuffer`, `Blob`.

#### Receiving message

Access `event.data` for incomming message

```typescript
socket.onmessage = (event) => {
  console.log(event.data)
}
```

- For Text message, `event.data` will always be `string`
- For `binary type` message, user can choose between `Blob` and `ArrayBuffer` by assign `WebSocket.binaryType='arraybuffer` _(default is `blob`)_ then `event.data` will be the appropriate type

```typescript
socket.binaryType = 'arraybuffer'
socket.onmessage = (event) => {
  if (event.data instanceof ArrayBuffer) {
    // Handling binary message
    return
  }
  // Handling String message
}
```

### Rate Limiting

When user has a slow network connection. After calling `WebSocket.send(...)` the data will be buffered in memory and will be sent out as soon as connection get better

`WebSocket.bufferedArmount` return the amount of data queued using `call()` but not yet send out to the network. _This value will not reset to zero if connection close._

```typescript
if (socket.bufferedAmount === 0) {
  socket.send(moreData())
}
```

### Close Connection

For sending `close frame` from browser WebSocket, simply call `WebSocket.close(code, reason)`.

```typescript
socket.close(1000, 'Complete') // both argument is optional
socket.onclose = (event) => {
  const { code, reason, wasClean } = event
  console.log({ code, reason, wasClean })
  // { code: 1000, reason: "Complete", wasClean: true }
}
```

#### \*Common code

- 1000 - normal closure (default)
- 1006 - connection was lost (this code cannot set manually, connection close abnormally by the browser and event go to `WebSocket.onerror`)
- 1001 - the party is going away (server shutting down, browser leave the page)
- ...

## Connection State

User can access `WebSocket.readyState` for getting the current state of a WebSocket instance

- `0`: CONNECTING - socket created but connection is not open yet
- `1`: OPEN - Connection is open and ready to communicate
- `2`: CLOSING - Connection is in closing process
- `3`: CLOSED - Connection is closed or could not be opened


WebSockets are a simple solution that is invented to solve the problems of HTTP polling for updating the data from the server, which has caused in high overhead, latency, and not-truthly realtime. WebSocket helps to maintain one single TCP connection for traffic in both directions for bidirectional soft-realtime communication.

WebSockets


## What is PNPM?

![](assets/what-is-pnpm-compare-to-npmyarn_0f651d536ab6e1811cdf37eb2b15550d_md5.webp)

_At Dwarves Foundation, we are always on the lookout for new tech. Researching PNPM was originally from research on what package manager **[Next.js](https://github.com/vercel/next.js/)** uses. We then tried to experiment with it for **[dwarves/react-toolkit](https://github.com/dwarvesf/react-toolkit/pull/46)**, which has given us some insights into some of the cost-benefits of using the package manager._

## Introduction

PNPM is a package manager for Node.js which stands for “Performant NPM”. It was introduced in 2016, the same year Yarn was released. PNPM is a fast, disk space efficient package manager that supports monorepos. It creates a non-flat `node_modules` by default, so code has no access to arbitrary packages. PNPM performs installation in three stages:

1. **Dependency resolution **- The package manager identifies and fetches all required dependencies to the store.
2. **Directory structure calculation** - Based on these dependencies, it calculates the layout of the `node_modules` directory.
3. **Linking dependencies** - it retrieves and establishes hard links from the store to `node_modules` for all remaining dependencies.

## Advantages of PNPM

PNPM is a very performant alternative to most package managers. Here are a few advantages of using PNPM:

- Saves disk space by using a content-addressable store for packages
- Boosts installation speed with a three-stage process
- Creates a non-flat node_modules directory for larger projects

### Saving Disk Space

Supposing you have 10 Node.js projects on your personal computer if you use NPM/Yarn, you will have 10 `node_modules` folders with a heavy size.

If you use PNPM, things will be different. It introduces a new concept to us, called a _content-addressable store_. See the image below:

![](assets/what-is-pnpm-compare-to-npmyarn_949760adee1b7a897e0b53044b7b0a89_md5.webp)

As you can see, PNPM does not store packages in the `node_modules` folder, but rather in the content-addressable store. Therefore, in the `node_modules` folders of projects using PNPM, the packages are _linked_ from the global store.

Thanks to this, package versions are only stored once on the disk

### **Boosting installation speed\*\***[](https://pnpm.io/motivation#boosting-installation-speed)\*\*

PNPM performs installation in three stages:

1. Dependency resolution: identifying and obtaining all necessary dependencies for the store.
2. Directory structure calculation: determining the layout of the `node_modules` directory based on these dependencies.
3. Linking dependencies: retrieving and establishing hard links from the store to `node_modules` for all remaining dependencies.

![](assets/what-is-pnpm-compare-to-npmyarn_4cde4958507a5ac4d8e7d614175b57de_md5.webp)

This approach is significantly faster than the conventional method of identifying, obtaining, and saving all dependencies directly to the `node_modules` directory.

![](assets/what-is-pnpm-compare-to-npmyarn_acaaed15e34c391a1ff6b81bbbf6163f_md5.webp)

### Creating a non-flat node_modules [directory](https://pnpm.io/motivation#creating-a-non-flat-node_modules-directory)

First of all, we must ask why NPM chooses the flat `node_modules` structure approach.

Going back in time, before the release of NPM version 3, at this point, `node_modules` in NPM were still in a non-flat structure. As shown in the example below:

```javascript
node_modules
└─ foo
   ├─ index.js
   ├─ package.json
   └─ node_modules
      └─ bar
         ├─ index.js
         └─ package.json
```

This approach has some issues such as:

- The issue of long directory paths on the Windows operating system occurred because the package created a dependency tree that was too deep
- Packages were copy-pasted in many places because they were required in different dependencies

Therefore, to solve this problem, NPM decided to flatten `node_modules`. After NPM version 3, the structure of the `node_modules` directory will become like this:

```javascript
node_modules
├─ foo
|  ├─ index.js
|  └─ package.json
└─ bar
   ├─ index.js
   └─ package.json
```

Consequently, the source code can access dependencies that are not explicitly declared in the project. Following the example above, even though the project only uses the **foo** package, we can completely use the **bar** package without declaring it in package.json.

Unlike NPM version 3, PNPM tries to solve the issues without flattening the dependency tree. Follow the example below:

```javascript
node_modules
├─ foo -> .registry.npmjs.org/foo/1.0.0/node_modules/foo
└─ .registry.npmjs.org
   ├─ foo/1.0.0/node_modules
   |  ├─ bar -> ../../bar/2.0.0/node_modules/bar
   |  └─ foo
   |     ├─ index.js
   |     └─ package.json
   └─ bar/2.0.0/node_modules
      └─ bar
         ├─ index.js
         └─ package.json
---------------------------------------
->: a symlink (or junction on Windows)
```

The **foo** package still contains its dependency **bar** in the form of a symlink. And what’s special is that **foo** doesn’t have `node_modules` inside, this way the dependency tree of **foo** won’t be as deep as in NPM before the release of v3.

At first glance, the structure may seem complicated, but when working on larger projects you will see that this structure is clearer than NPM/Yarn

## Disadvantages of PNPM

However, there are a few disadvantages of using PNPM. One of them is that it can be slower than other package managers like Yarn or NPM when installing packages for the [first time](https://medium.com/@buffet_time/why-you-should-move-to-pnpm-82962f332418). It can also be difficult to use with some build tools like [Webpack](https://dev.to/stackblitz/what-is-pnpm-and-is-it-really-so-fast-and-space-efficient-29la).

PNPM's node_modules layout uses [symbolic links to create a nested structure of dependencies](https://pnpm.io/symlinked-node-modules-structure). This has some implications for certain setups, where Windows machines or certain permissioned Linux environments may have trouble accessing these links.

Another potential issue with PNPM is that its nested dependency structure may not be compatible with certain older packages. [This can cause issues when trying to install packages that have dependencies that are not compatible with PNPM’s nested structure](https://pnpm.io/limitations).

## **Showcase**

Thankfully, PNPM is employed by numerous large companies, demonstrating its effectiveness. For an updated list, you can visit [https://pnpm.io/users](https://pnpm.io/users).

![](assets/what-is-pnpm-compare-to-npmyarn_55e4a8514dc89f283ed5e6b77d839d42_md5.webp)

## Conclusion

PNPM is a package manager for Node.js that offers several advantages over other popular package managers, including saving disk space and boosting installation speed. It also creates a non-flat `node_modules` directory, which can be helpful for larger projects. However, there are some potential disadvantages to using PNPM, such as compatibility issues with certain older packages and slower initial package installation times. Despite these drawbacks, PNPM is used by numerous large companies and may be worth considering for your own projects.

Overall, PNPM offers some unique benefits and is a viable alternative to other package managers for Node.js. It's worth exploring whether it's the right choice for your specific use case.

## References:

- [https://pnpm.io/motivation](https://pnpm.io/motivation)
- [https://blog.bitsrc.io/pnpm-javascript-package-manager-4b5abd59dc9](https://blog.bitsrc.io/pnpm-javascript-package-manager-4b5abd59dc9)
- [https://pnpm.io/faq#what-does-pnpm-stand-for](https://pnpm.io/faq#what-does-pnpm-stand-for)
- [https://medium.com/pnpm/why-should-we-use-pnpm-75ca4bfe7d93](https://medium.com/pnpm/why-should-we-use-pnpm-75ca4bfe7d93)
- [https://medium.com/@buffet_time/why-you-should-move-to-pnpm-82962f332418](https://medium.com/@buffet_time/why-you-should-move-to-pnpm-82962f332418)
- [https://dev.to/stackblitz/what-is-pnpm-and-is-it-really-so-fast-and-space-efficient-29la](https://dev.to/stackblitz/what-is-pnpm-and-is-it-really-so-fast-and-space-efficient-29la)
- [https://refine.dev/blog/pnpm-vs-npm-and-yarn/](https://refine.dev/blog/pnpm-vs-npm-and-yarn/)


PNPM is a package manager for Node.js which stands for “Performant NPM”. It was introduced in 2016, the same year Yarn was released. PNPM is a fast, disk space efficient package manager that supports monorepos. It creates a non-flat `node_modules` by default, so code has no access to arbitrary packages.

Playground > Frontend