
import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

Accessibility (a11y for short) is a major concern when creating modern websites. And for a very good reason. The internet is for everyone and we, as developers, need to make sure we build it that way!

When it comes to React, most developers are well aware of the [benefits of reusable components](https://whereisthemouse.com/a-guide-to-building-non-trivial-react-components) - they provide consistency and flexibility while keeping our code clean.

But here's a little secret - React components, when built with a11y in mind, can also dramatically improve the level of accessibility of our UIs. What is more, by adding Typescript to the mix, we can practically enforce certain accessibility features directly in our codebase.

Let's explore some examples.

## Images

Imagine we are building a reusable image component for our React project. In its simplest form, it might look something like this:

```js
type ImageProps = {
  src: string,
};

const Image = ({ src }: ImageProps) => {
  return <img src={src} />;
};
```

But to make our component truly accessible, we need to create the possibility to add some `alt` text to it. [The `alt` attribute](https://www.w3.org/WAI/tutorials/images/) could be an empty string for decorative images but it should always be there.

How should we go about it? The simplest way is to just add an optional `alt` prop like so:

```js
type ImageProps = {
  src: string,
  alt?: string,
};

const Image = ({ src, alt }: ImageProps) => {
  return <img src={src} alt={alt} />;
};
```

This works just fine! But it still doesn't ensure our component is accessible out of the box. Developers could still simply omit the `alt` prop when they are using the component. So let's make sure we always have it, even if it's an empty string by adding a default value.

```js
type ImageProps = {
  src: string,
  alt?: string,
};

const Image = ({ src, alt = '' }: ImageProps) => {
  return <img src={src} alt={alt} />;
};
```

This is better! We've made sure our component is accessible by default. But we can take it a step further still by making the `alt` prop mandatory:

```js
type ImageProps = {
  src: string,
  alt: string,
};

const Image = ({ src, alt }: ImageProps) => {
  return <img src={src} alt={alt} />;
};
```

Why do this when we already had an excellent solution? Simple. With this setup, we are forcing the developers on our team to actively consider whether the image they are adding to the code is decorative or not. Accessibility is now something about which we make conscious choices. It is no longer merely an afterthought.

## Inputs and labels

Inputs are another fundamental React component we can easily make accessible by default. Let's create a basic `Input` component to illustrate:

```js
type InputProps = {
  label?: string, // other relevant input props
  ...
};

const Input = ({ label }: InputProps) => {
  return (
    <>
      {label && <label>{label}</label>}
      <input type="text" />
    </>
  );
};
```

The component above is clearly not accessible. Not only is the label is not associated with the corresponding input but it will also not even render, if we fail to pass the `label` prop to our component. Let's fix it.

```js
type InputProps = {
  id: string,
  label: string, // other relevant input props
  ...
};

const Input = ({ label, id }: InputProps) => {
  return (
    <>
      <label htmlFor={id}>{label}</label>
      <input id={id} type="text" />
    </>
  );
};
```

Much better! We now have a mandatory `id` and `label` props that ensure our component is accessible out of the box. But there is a problem. We always need to have a visible label for our inputs. This is not ideal because in some cases, we might want to hide it.

To implement the necessary hidden label functionality [without breaking accessibility](https://www.w3.org/WAI/tutorials/forms/labels/), we should have a mechanism to visually hide the label while still having it available in the DOM and appropriately styled.

Here's an example implementation:

```js
// CSS for our visually-hidden class

.visually-hidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
}

// React component

type InputProps = {
  id: string;
  label: string;
  labelIsVisuallyHidden?: boolean;
  ... // other relevant input props
};

const Input = ({ label, id, labelIsVisuallyHidden }: InputProps) => {
  return (
    <>
      <label
        htmlFor={id}
        className={labelIsVisuallyHidden ? "visually-hidden" : ""}
      >
        {label}
      </label>
      <input id={id} type="text" />
    </>
  );
};

```

We have now enforced a11y in our inputs even when labels are not visible to users without sacrificing any of our desired functionality.

## Icon buttons

Let's look at a final example - icon buttons. If designed and used correctly, icon buttons are great - they provide a lot of relevant information while allowing us to save valuable screen real estate. But we always need to make sure they are accessible and just as useful to our visually-impaired users.

Let's create a simple `IconButton` component.

```js
// Icon
const MenuIcon = () => {
  return (
    <svg viewBox="0 0 24 24" width="24px" height="24px" focusable="false">
      <path d="M3,6H21V8H3V6M3,11H21V13H3V11M3,16H21V18H3V16Z" />
    </svg>
  );
};

// Icon Button
type IconButtonProps = {
  icon: React.ReactNode,
};

const IconButton = ({ icon }: IconButtonProps) => {
  return <button>{icon}</button>;
};

// Usage

const App = () => {
  return (
    <div>
      <IconButton icon={<MenuIcon />} />
    </div>
  );
};
```

This component works as expected for most users. But it is not accessible. There's currently no way for screen readers to be able to communicate to users what this button is about. We are simply not providing them the necessary information.

Let's rectify the situation.

```js
// Icon
const MenuIcon = () => {
  return (
    <svg
      viewBox="0 0 24 24"
      width="24px"
      height="24px"
      focusable="false"
      aria-hidden={true} // This signals to screen-readers to ignore this element
    >
      <path d="M3,6H21V8H3V6M3,11H21V13H3V11M3,16H21V18H3V16Z" />
    </svg>
  );
};

// Icon Button
type IconButtonProps = {
  icon: React.ReactNode,
  a11yButtonText: string,
};

const IconButton = ({ icon, a11yButtonText }: IconButtonProps) => {
  return (
    <button>
      {icon}
      <span className="visually-hidden">{a11yButtonText}</span>
    </button>
  );
};

// Usage

const App = () => {
  return (
    <div>
      <IconButton icon={<MenuIcon />} a11yButtonText="menu" />
    </div>
  );
};
```

We've added a `a11yButtonText` prop to our `IconButton` and a visually hidden `span` element where the text is displayed for screen readers but not our regular users. By making the prop mandatory, we are also ensuring our component will always be used with accessibility in mind throughout our codebase.

## Conclusion

Building websites with accessibility in mind makes them better for everyone. With the power of Typescript, we can make sure we enforce certain accessibility features in our components by default.

But we shouldn't stop there. There's a plethora of `a11y` tooling we can use to further enhance accessibility on our React app.

Here are just a few examples:

- `eslint-plugin-jsx-a11y` - excellent [ESLint plugin](https://www.npmjs.com/package/eslint-plugin-jsx-a11y) to statically evaluate JSX to spot accessibility issues
- `@axe-core/react` - allows us to [test our React components](https://github.com/dequelabs/axe-core-npm/tree/develop/packages/react) with axe-core accessibility testing library
- WAVE Web Accessibility Evaluation Tools - a [whole suite](https://wave.webaim.org/) of accessibility testing tools, including browser extensions that facilitate manual testing

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


A detailed guide on how to make React components accessible out of the box with Typescript.

Accessibility (a11y) by default with React and Typescript


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

Here's a simple question - when do the children of a React component re-render? At first glance, the answer is obvious - React children will re-render when either their props/state change or their parent component re-renders. But, as usual, there's more to the story.

Let's explore parent component re-renders in more detail.

## The usual scenario

Will the `ChildComponent` re-render when we click the button in the parent component?

```js
import { useState } from 'react';

const ChildComponent = () => {
  console.log('I re-rendered');
  return <p>Child</p>;
};

const ParentComponent = () => {
  const [count, setCount] = useState(0);
  return (
    <div>
      <button onClick={() => setCount(number + 1)}>{count}</button>
      <Child />
    </div>
  );
};

export default ParentComponent;
```

It definitely will! The parent re-renders on every button click and so does the child. This how React works, after all.

Hmm! But `ChildComponent` doesn't really need to re-render. What should we do about it?

## The instinctive reaction - `React.memo`

The short answer is - in this case, absolutely nothing! We don't have any evidence that this is causing performance problems. Micro-optimising React components in similar scenarios is, in fact, likely to [hurt performance and complicate our codebase unnecessarily](https://whereisthemouse.com/advanced-reactjs-interview-questions).

Still, the temptation to solve for empty re-renders is always there. Or, maybe we have a different use case, where there's a legitimate need for memoization (more on that in a moment). So what do we usually do? Instinctively, we add `memo` to our `ChildComponent`. That way, we are sure it's not going to re-render unnecessarily:

```js
import { memo } from 'React';

const ChildComponent = memo(() => {
  console.log('I re-rendered');
  return <p>Child</p>;
});
```

But here is a question - is there, perhaps, a better way?

## A better way - `children` as a prop

Let's re-structure our components a bit and see what happens.

```js
const ChildComponent = () => {
  console.log('I re-rendered');
  return <p>Child</p>;
};

const ParentComponent = ({ children }) => {
  const [count, setCount] = useState(0);
  return (
    <div>
      <button onClick={() => setCount(number + 1)}>{number}</button>
      {children}
    </div>
  );
};

const App = () => {
  return (
    <ParentComponent>
      <ChildComponent />
    </ParentComponent>
  );
};

export default App;
```

The functionality of our app remains exactly the same as before. Yet, the `ChildComponent` doesn't re-render anymore even though the state of the parent is updated when the button is clicked. And we didn't use any explicit memoization techniques to achieve this.

So what's the secret? Instead of nesting our `ChildComponent` directly in the parent, we used `children` as a prop and placed it in the `App` instead. This technique is known as "lifting content up". That way, even when `ParentComponent` re-renders, React can skip re-rendering the part of the component tree that relates to `ChildComponent`. For a more in-dept explanation on how this works, check out this [excellent article](https://overreacted.io/before-you-memo/#solution-2-lift-content-up) by Dan Abramov.

Amazing, right! But wait a minute...

We already established that, in most cases, memoizing the children is not even needed. So when is this technique even relevant?

## React context

The above can be useful any time we have an expensive React sub-tree we don't want to re-render frequently.

Here's an example. Let's re-structure our `App` yet again so that this time, our `count` is kept in React context. It is not unusual for a React context provider to wrap our entire app. So, in this case, it's important to make sure we are not re-rendering every single component down the line when a context value changes.

```js
import { useState, useContext, createContext } from 'react';

const Context = createContext();

const ChildWithCount = () => {
  const { count, setCount } = useContext(Context);
  console.log('ChildWithCount re-renders');
  return (
    <div>
      <button onClick={() => setCount(count + 1)}>{count}</button>
      <p>Child</p>
    </div>
  );
};

const ExpensiveChild = () => {
  console.log('ExpensiveChild re-renders');
  return <p>Expensive child</p>;
};

const CountContext = () => {
  const [count, setCount] = useState(0);
  const contextValue = { count, setCount };
  return (
    <Context.Provider value={contextValue}>
      <ChildWithCount />
      <ExpensiveChild /> // Imagine re-rendering this component is expensive
    </Context.Provider>
  );
};

const App = () => {
  return <CountContext />;
};

export default App;
```

This time, we created two child components - one that consumes the `CountContext` we introduced and one that does not. So what happens when I click the button?

With the structure above, both child components will re-render on every button click. And while this is expected behaviour for the component that is consuming `CountContext`, it's not something we want to happen for our `ExpensiveChild` component. Depending on the app structure and how often these re-renders occur, this can be the cause for legitimate performance issues. So let's fix it!

Instead of adding complexity to our app by manually memoizing components, we can just use `children` as a prop to solve the problem.

```js
import { useState, useContext, createContext } from 'react';

const Context = createContext();

const ChildWithCount = () => {
  const { count, setCount } = useContext(Context);
  console.log('ChildWithCount re-renders');
  return (
    <div>
      <button onClick={() => setCount(count + 1)}>{count}</button>
      <p>Child</p>
    </div>
  );
};

const ExpensiveChild = () => {
  console.log('ExpensiveChild re-renders');
  return <p>Expensive child</p>;
};

const CountContext = ({ children }) => {
  const [count, setCount] = useState(0);
  const contextValue = { count, setCount };
  return <Context.Provider value={contextValue}>{children}</Context.Provider>;
};

const App = () => {
  return (
    <CountContext>
      <ChildWithCount />
      <ExpensiveChild />
    </CountContext>
  );
};

export default App;
```

Everything works as expected in our app now - both in terms of functionality and performance. And with no cost to code readability or maintainability.

All we needed was to understand when React children re-render.

Happy coding! 💫

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


Learn when child components in React re-render and how to structure a React apps with both performance and simplicity in mind.

React components - when do children re-render?


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

To build robust UIs often means to take all possible UI states into consideration and to make sure components behave consistently and correctly throughout. One way to do this is to prevent UIs from getting into impossible states. In this scenario, an impossible UI state means inconsistent, nonsensical or mutually exclusive.

Here's a simple example:

```js
const SchrodingersCat = () => {
  return (
    <Box>
      <Cat dead={true} alive={true} />
    </Box>
  );
};
```

The famous [Schrödinger's cat](https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat) thought experiment might make a lot of sense when illustrating quantum physics concepts. But, if we turn it into a React component, it can also serve as a good example of an inconsistent UI state. 🐈‍⬛

So how can we avoid impossible UI states and create React components that make sense?

## Replace boolean state and props with descriptive ones

How we structure our React components props and state can have a massive impact. Let's replace our `Cat` example from above with something a little more realistic. Imagine we want to create a `Status` component with 4 possible states - `idle`, `pending`, `success` and `error`. How should we go about it?

One way would be to create a boolean prop for these states and make sure to pass the correct one when the status changes. So it would look something like this:

```js
interface StatusProps {
  isIdle?: boolean;
  isPending?: boolean;
  isError?: boolean;
  isSuccess?: boolean;
}

const Status = ({ isIdle, isPending, isError, isSuccess }: StatusProps) => {
  return (
    <div>
      {isIdle && <p>Idle</p>}
      {isPending && <p>Pending</p>}
      {isSuccess && <p>Success</p>}
      {isError && <p>Error</p>}
    </div>
  );
};

// Usage
const App = () => {
  return <Status isIdle />;
};
```

This is somewhat of a contrived example but, in reality, it can often be tempting to structure props in this way. It's relatively easy to understand and pretty straightforward to implement.

But we can immediately spot a serious problem with this approach. Nothing is preventing us from putting this component in an impossible state.

```js
const App = () => {
  return <Status isIdle isError />;
};
```

To avoid this, let's ditch the boolean props and create a single descriptive prop in their place.

```js
interface StatusProps {
  status: 'idle' | 'pending' | 'error' | 'success';
}

const Status = ({ status }: StatusProps) => {
  return (
    <div>
      {status === 'idle' && <p>Idle</p>}
      {status === 'pending' && <p>Pending</p>}
      {status === 'success' && <p>Success</p>}
      {status === 'error' && <p>Error</p>}
    </div>
  );
};

// Usage
const App = () => {
  return <Status status="idle" />;
};
```

Much better!

But wait! This approach works well when we can fit all the information that we need in a single prop. What if we need to handle multiple props, instead?

## Use Typescript discriminated union

Imagine we want to display an error message in our `Status` component but only when it is in its `error` state? We also want to pass the text of the error message to `Status` via a prop. In these more complicated scenarios, we can use Typescript to make sure impossible states are not allowed.

Here's how:

```js
interface StatusPropsDefault {
  status: 'idle' | 'pending' | 'success';
  errorMessage?: never;
}

interface StatusPropsError {
  status: 'error';
  errorMessage: string;
}

type StatusProps = StatusPropsDefault | StatusPropsError;

const Status = ({ status, errorMessage }: StatusProps) => {
  return (
    <div>
      {status === 'idle' && <p>Idle</p>}
      {status === 'pending' && <p>Pending</p>}
      {status === 'success' && <p>Success</p>}
      {status === 'error' && <p>Error</p>}
      {errorMessage}
    </div>
  );
};

// Usage
const App = () => {
  return (
    <>
      <Status status="idle" />
      <Status status="error" errorMessage="Error message" />
    </>
  );
};
```

We are using a Typescript [discriminated union](https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html#discriminating-unions) when we define the types of our props to make sure an error message can only be passed to the component when its status is `error`. This is awesome and it works great for our use case.

But imagine we have a different challenge. Perhaps we are not only concerned with impossible states but also with impossible state transitions.

## Implement a state machine with XState

More concretely, how can we make sure our `Status` component cannot go from `idle` directly to `success` or `error` without being in a `pending` state first?

Enter XState.

With [XState](https://xstate.js.org/) we can build and visualize type-safe, declarative finite state machines that can ensure states and state transitions always make sense.

Let's see what our `Status` state machine might look like:

```js
import { createMachine } from "xstate";

// Possible statuses
enum Statuses {
  idle = "idle",
  pending = "pending",
  success = "success",
  error = "error"
}

// Possible state machine events
type MachineEvent =
  | { type: "PENDING" }
  | { type: "SUCCESS" }
  | { type: "ERROR" };

// Possible state machine states
type MachineState =
  | { value: Statuses.idle; context: never }
  | { value: Statuses.pending; context: never }
  | { value: Statuses.success; context: never }
  | { value: Statuses.error; context: never };

export const statusMachine = createMachine<
  undefined, // We are not using the state machine context, so it is set to undefined
  MachineEvent,
  MachineState
>({
  initial: Statuses.idle,
  predictableActionArguments: true,
  states: {
    [Statuses.idle]: {
      on: {
        PENDING: Statuses.pending
      }
    },
    [Statuses.pending]: {
      on: {
        SUCCESS: Statuses.success,
        ERROR: Statuses.error
      }
    },
    [Statuses.success]: { type: "final" },
    [Statuses.error]: { type: "final" }
  }
});
```

While there is some xState-specific code in the example above, the general idea of the state machine should be straightforward. We always start in an `idle` state. With a `PENDING` event, we can transition to `pending` state . Once we are in this state, we can transition to either `success` or `error`, both of which are final states for our state machine.

Let's change our status component to use the same Typescript enum as the state machine state.

```js
interface StatusProps {
  status: Statuses;
}

const Status = ({ status }: StatusProps) => {
  return (
    <div>
      {status === Statuses.idle && <p>Idle</p>}
      {status === Statuses.pending && <p>Pending</p>}
      {status === Statuses.success && <p>Success</p>}
      {status === Statuses.error && <p>Error</p>}
    </div>
  );
};
```

Finally, let's put it all together in our `App` component:

```js
const App = () => {
  const [state, send] = useMachine(statusMachine);

  const handleStateChange = () => {
    if (state.matches(Statuses.idle)) {
      send("PENDING");
    } else if (state.matches(Statuses.pending)) {
      // Randomly send either a success or an error event
      if (Math.round(Math.random())) {
        send("SUCCESS");
      } else {
        send("ERROR");
      }
    }
  };

  return (
    <>
      <Status status={state.value as Statuses} />
      <button disabled={state.done} onClick={handleStateChange}>
        Change state
      </button>
    </>
  );
};
```

The logic inside `handleStateChange` is clearly just an illustration. Still, our state machine now ensures our component states and state transitions are always consistent and logical.

Not every component needs to be managed with a state machine. And even when we want to have one, it's not always necessary to use xState to build it. Still, especially in more complex scenarios, it can be extremely helpful to have this tool in our tool belt!

Want to learn more about complex React state management? Check out my article on [compound React components](https://whereisthemouse.com/a-guide-to-building-non-trivial-react-components).

## Conclusion

There are different approaches to building robust UI components and avoid putting our components in impossible states. Which one we choose for a particular component will always heavily depend on the use case. Hopefully this overview can help make that choice easier and more informed.

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


Use React, Typescrit and xState to ensure UIs are always in a consistent and sensible state throughout your React application.

Avoid impossible UI states with React, Typescript and xState


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

Over the past several years, I've been on both sides of dozens of front-end job interviews. In my experience, when it comes to advanced ReactJS interview questions, there are 3 core concepts that can truly make a candidate stand out.

## When does a React component re-render?

At first glance, it's a simple question. But the level of detail in the answer can reveal a lot about the candidate's understanding when it comes to advanced React concepts. At the most basic level, the answer is very straightforward - a component re-renders when there is a change in its state or props or if its parent re-renders. This is, in essence, true. But there is more to the story.

### Props or state change

Let's start with the props / state change. What does it mean exactly? How is it evaluated?
Will the below code trigger a re-render when you click the button?

```js
import { useState } from 'react';

const Component = () => {
  const [number, setNumber] = useState(1);
  console.log('re-renders');
  return <button onClick={() => setNumber(1)}>{number}</button>;
};
```

Nope. The value for `number` is always the same. How about now?

```js
import { useState } from 'react';

const Component = () => {
  const [numberArray, setNumberArray] = useState([1]);
  console.log('re-renders');
  return <button onClick={() => setNumberArray([1])}>{numberArray[0]}</button>;
};
```

In this case the component re-renders on every button click. Interesting! Why is that?

Short answer - there's a difference between evaluating equality for primitive values (like numbers or strings) and objects (like arrays). Read more about referential equality in the context of React in [my article about `useEffect`](https://www.freecodecamp.org/news/most-common-react-useeffect-problems-and-how-to-fix-them/). Senior React developers should be acutely aware of this nuance before they can move on to other advanced topics, like memoization. But more on that in a minute.

### The parent component

Above we mention that a component re-renders when its parent re-renders. Is that true? Let's find out.

Will the component re-render when we click the button?

```js
import { useState } from 'react';

const Child = () => {
  console.log('re-renders');
  return <p>I'm a child</p>;
};

const Parent = () => {
  const [number, setNumber] = useState(1);
  return (
    <div>
      <button onClick={() => setNumber(number + 1)}>{number}</button>
      <Child />
    </div>
  );
};

export default Parent;
```

Yep! It behaves as expected. How about now?

```js
const Child = () => {
  console.log('re-renders');
  return <p>I'm a child</p>;
};

const Parent = ({ children }) => {
  const [number, setNumber] = useState(1);
  return (
    <div>
      <button onClick={() => setNumber(number + 1)}>{number}</button>
      {children}
    </div>
  );
};

const App = () => {
  return (
    <Parent>
      <Child />
    </Parent>
  );
};

export default App;
```

Hm, what is going on here? The child doesn't re-render anymore even though the state of the parent is updated when the button is clicked. Why? Well, the `children` technically didn't change in this case - so React can skip re-rendering this part of the component tree. It's, in essence, an optimisation technique. For a more in-dept explanation, check out Kent Dodds' [excellent article](https://kentcdodds.com/blog/optimize-react-re-renders).

### React context and hooks

Another mechanism to cause a component to re-render is through React context. A change is the context value will trigger a re-render for all components that are consuming it. Let's take a look.

```js
import { useState, useContext, createContext } from 'react';

const Context = createContext();

const Child1 = () => {
  const { number, setNumber } = useContext(Context);
  console.log('Child1 re-renders');
  return (
    <div>
      <button onClick={() => setNumber(number + 1)}>{number}</button>
      <p>I'm a child</p>
    </div>
  );
};

const Child2 = () => {
  console.log('Child2 re-renders');
  return <p>I'm a second child</p>;
};

const NumberContext = ({ children }) => {
  const [number, setNumber] = useState(0);
  const contextValue = { number, setNumber };
  return <Context.Provider value={contextValue}>{children}</Context.Provider>;
};

const App = () => {
  return (
    <NumberContext>
      <Child1 />
      <Child2 />
    </NumberContext>
  );
};

export default App;
```

In the example above `Child1` is consuming the context which means clicking the button is causing a re-render. This is not the case for `Child2`, so it doesn't re-render.

Much the same principle applies to React hooks.

```js
import { useState } from 'react';

const useCount = () => {
  const [number, setNumber] = useState(0);
  return { number, setNumber };
};

const Child1 = () => {
  const { number, setNumber } = useCount();
  console.log('Child1 re-renders');
  return (
    <div>
      <button onClick={() => setNumber(number + 1)}>{number}</button>
      <p>I'm a child</p>
    </div>
  );
};

const Child2 = () => {
  console.log('Child2 re-renders');
  return <p>I'm a second child</p>;
};

const App = () => {
  return (
    <div>
      <Child1 />
      <Child2 />
    </div>
  );
};

export default App;
```

Once again, `Child1` re-renders while not `Child2` does not.

### Component re-renders vs. DOM updates

While this is all very interesting and useful, one important question still remains - why should we care about component re-renders in the first place?

By now, we certainly have noticed that sometimes React re-renders our components even when no DOM updates are taking place. As experienced React developers, we probably already know (at least in broad strokes) about [React reconciliation](https://reactjs.org/docs/reconciliation.html) and the diffing algorithm that allows the library to do the minimum number of DOM updates needed to update the UI.

Still, these "empty" re-renders feel unnecessary. Should we get rid of them?

## When to use `useMemo` and `useCallback`?

The question is relatively concrete but it links to the broader concept of memoization. This is a topic a lot of experienced React developers struggle with. Both hooks - `useCallback` and `useMemo` - serve as a mechanism to memoize functions and values respectively in a React component. This allows us to cache expensive calculations (see example below) and keep references stable across re-renders, provided none of the items in the dependency array changed.

What makes this question advanced is that it is predicated on the assumption that the candidate is already familiar with these hooks. The focus is rather on whether they can think critically about performance optimisations and understand not only the benefits but also the trade-offs. As React developers, once we learn we can optimise re-renders, there's often an irresistible urge to do it all the time. But every optimisation comes at a cost.

In this case there are, broadly speaking, at least two ways the cost might out-way the benefit:

- Using memoization when it's not really necessary might actually hurt performance. Here are some [interesting measurements](https://canimerge.com/should-you-really-use-usememo-in-react-lets-find-out/) to illustrate this.
- Overusing `useMemo` and `useCallback` makes the code base notably more complex and less maintainable for the entire team.

So, to get back to the original question, when should we use `useMemo` and `useCallback`?

Short answer - when we have strong evidence that there is a real performance issue in our application and that applying these techniques will help solve this problem in a tangible, measurable way. Alternatively, the two hooks can be used when we need a stable reference for a value or a method, respectively. Unless one of these conditions is met, we do not have a good justification to use `useMemo` and / or `useCallback`.

To illustrate an obvious performance issue, let's look at a classic `useMemo` example:

```js
import { useState, useMemo } from 'react';

const Component = () => {
  const [number, setNumber] = useState(0);
  const expensiveCalculationResult = artificiallyExpensiveCalculation(1);
  return (
    <div>
      <button onClick={() => setNumber(number + 1)}>{number}</button>
      <p>Expensive calculation result: {expensiveCalculationResult}</p>
    </div>
  );
};

const ComponentWithUseMemo = () => {
  const [number, setNumber] = useState(0);
  const expensiveCalculationResult = useMemo(() => {
    return artificiallyExpensiveCalculation(1);
  }, []);
  return (
    <div>
      <button onClick={() => setNumber(number + 1)}>{number}</button>
      <p>Expensive calculation result: {expensiveCalculationResult}</p>
    </div>
  );
};

const App = () => {
  return (
    <div>
      <Component />
      <ComponentWithUseMemo />
    </div>
  );
};
export default App;

const artificiallyExpensiveCalculation = (number) => {
  for (let i = 0; i < 1000000000; i++) {}
  return number;
};
```

Because of the artificially expensive calculation we have created, it's easy to prove that `useMemo` improves performance in this case.

<iframe
  src="https://codesandbox.io/embed/usememo-example-51vg6v?fontsize=14&hidenavigation=1&theme=dark"
  style={{
    width: '100%',
    height: '400px',
    border: '0',
    borderRadius: '4px',
    overflow: 'hidden',
  }}
  title="useMemo example"
  allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
  sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
></iframe>

<br />A lot of the time, performance issues might manifest in more subtle ways
and require careful measurement and analysis before they can be resolved in the
right way. Whether the answer is `useMemo`, `useCallback` or another
optimisation technique altogether, taking advantage of the React dev tools
profiler is always a good first step to diagnose the problem.

## When should we use custom React hooks?

Once again, this question appears deceptively simple on the surface. But there is a lot of advanced React-specific knowledge a candidate must have at their fingertips to answer it.

To come up with a specific use case and be able to justify it, they should be aware of the benefits of React hooks in general and custom hooks in particular. So what are they?

Here's a non-exhaustive list in no particular order:

- React hooks are notably easier to reason about compared to previous life-cycle methods. They let us collocate related logic and are, on average, less verbose
- React hooks allow us to re-use stateful logic across React component
- It's relatively straightforward to unit test React hooks independently from a React component
- React hooks are easy to use with Typescript

You can find out more about [the motivation behind hooks](https://reactjs.org/docs/hooks-intro.html#motivation) in the official React docs.

Then, with all of the above in mind, the candidate must come up with a specific scenario in which these benefits truly shine. So what are some classic examples?

### Event listeners

A lot of the time, we want to re-use some logic related to event listeners in our components. One example could be to create a `useKeyPress` hook in order to detect that a certain key is pressed.

```js
const useKeyPress = (targetKey) => {
  const [keyPressed, setKeyPressed] = useState(false);

  useEffect(() => {
    const downHandler = ({ key }) => {
      if (key === targetKey) {
        setKeyPressed(true);
      }
    };

    const upHandler = ({ key }) => {
      if (key === targetKey) {
        setKeyPressed(false);
      }
    };

    window.addEventListener('keydown', downHandler);
    window.addEventListener('keyup', upHandler);

    return () => {
      window.removeEventListener('keydown', downHandler);
      window.removeEventListener('keyup', upHandler);
    };
  }, [targetKey]);

  return keyPressed;
};
```

For a good use case for this hook, check out my article on [how to build keyboard accessible list in React](https://whereisthemouse.com/create-a-list-component-with-keyboard-navigation-in-react).

### Client-side data-fetching

Another great use case for custom hooks is data-fetching on the client. Libraries like React Query provide hooks like `useQuery` and `useMutation` to access and manage server state. In addition, it's often useful to build our own custom hooks for specific resources in order to simplify data-fetching even further. For example, to fetch a list of posts, we might create a `usePosts` hook.

```js
import { useQuery } from '@tanstack/react-query';

function usePosts() {
  return useQuery(['posts'], async () => {
    const { data } = await axios.get('https://myapi/posts');
    return data;
  });
}
```

### Simplified usage of React Context

Let's have a closer look at our `NumberContext` from the example above. Could we improve it? What if we created a `useNumberContext` custom hook that would allow us to use it with ease.

```js
import { useState, useContext, createContext } from 'react';

const Context = createContext();

const NumberContext = ({ children }) => {
  const [number, setNumber] = useState(0);
  const contextValue = { number, setNumber };
  return <Context.Provider value={contextValue}>{children}</Context.Provider>;
};

const useNumberContext = () => {
  const { number, setNumber } = useContext(Context);
  return { number, setNumber };
};

const Component = () => {
  const { number, setNumber } = useNumberContext();

  return (
    <div>
      <button onClick={() => setNumber(number + 1)}>{number}</button>
      <p>I'm a child</p>
    </div>
  );
};
```

There are many, many other valid use cases for React hooks. What is offered here is just an illustration. The goal of this questions is not to receive a specific "correct" answer. Rather, it's meant to give candidates an opportunity to demonstrate that they can truly think in React .

## Conclusion

As a candidate, having a good grasp of these core ReactJS concepts can come a long way in helping you stand out and ace an interview. Still, it's important to point out that this list is neither exhaustive nor comprehensive. The technical interview is also probably going to be only one step in a long interview process that usually involves building a React app. To tackle this next step, check out my article on how to submit a [good React take-home assignment](https://www.freecodecamp.org/news/how-to-stand-out-during-your-react-coding-interview/).

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


Learn about 3 advanced ReactJS concepts that often come up during job interviews - component re-renders, memoization and React hooks.

Controlled vs uncontrolled React components - why not both?


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

To correctly use a Button component as a link in React, we need to override the underlying `button` HTML tag of the component and turn it into an `anchor` tag, while still keeping the component styles and behaviour intact.

Let's explore in more detail.

## Button component

First, let's build a typical `Button` component in React:

```js
const Button = ({ onClick, children }) => {
  return (
    <button onClick={onClick} className="button">
      {children}
    </button>
  );
};

export default Button;
```

And add some styles to it:

```css
.button {
  background-color: #4caf50;
  border: none;
  color: white;
  padding: 15px 32px;
  text-align: center;
  text-decoration: none;
  display: inline-block;
  font-size: 16px;
}
```

Now, to use it, all we need to do is the following:

```js
import Button from './Button'

const ComponentWithButton = () => {
  const handleClick = () => {
    // Some button logic
  }

  return (
     ... other JSX
    <Button onClick={handleClick}>Button</Button>
  )
}
```

This looks great so far! But what happens if we need to use this component not as a button, but as a link to another page or website?

Our first instinct might be to handle the navigation logic using the `onClick` handler. This is the wrong approach! Here's why:

- The HTML of our page should be semantic - HTML elements have a specific purpose and should be used accordingly - a `button` should change something on the page while `anchor` tags are used for navigation;
- Using the correct HTML tags is also good for accessibility - assistive technology benefits greatly from semantic HTML and so do users who navigate our website via keyboard;
- Search engines take advantage of the links on our website to crawl it, so opting for an `anchor` tag is also SEO friendly.

So, if it's not recommended to use the `onClick` handler for navigation, what is the alternative?

## Introducing React's `as` prop pattern

There is a mechanism to override the underlying HTML tag of our button component and to turn it into a link. Let's introduce an `as` prop to our `Button` component:

```js
const Button = ({ onClick, children, as: Component = 'button', ...rest }) => {
  return (
    <Component onClick={onClick} className="button" {...rest}>
      {children}
    </Component>
  );
};
```

### Handle external links

With the help of the `as` prop, we can easily turn our button into a link:

```js
import Button from './Button'

const ComponentWithLink= () => {

  return (
     ... other JSX
    <Button as="a" href="https://whereisthemouse.com">Where is the mouse?</Button>
  )
}
```

The component above looks identical to our normal button, but is semantically a link. This is exactly what we wanted! 🚀

💡 Note: Our button is actually a link now. Because of this, there are some subtle differences it its behaviour. For example, if we use the keyboard to focus on a button, we can activate it with both `Enter` and `Space` key, while for a link only `Enter` will work.

### Handle internal links

Here's another scenario! What if we are using a router like React Router and want to link to a page that is internal to our website? Luckily, our component easily allows for this implementation:

```js
import { Link } from 'react-router-dom'
import Button from './Button'

const ComponentWithInternalLink= () => {

  return (
     ... other JSX
    <Button as={Link} to="/">Home</Button>
  )
}
```

Once again, our component is styled exactly like a button but it is a React Router link underneath!

## Conclusion

Let's conclude this article on a note of caution!

The approach above works nicely to convert our buttons into real semantic links. But before we use it, it is important to take a step back and consider whether this is something that we really want or need in the context of our React app.

While there are legitimate reasons for creating links that look and feel like buttons, in the majority of cases, we are better off using our React components and HTML elements as originally intended.

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


To correctly use a Button component as a link in React, override the underlying button HTML tag of the component and turn it into an anchor tag.

How to use a Button component as a link in React


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

React Router v6 has been around for a while now. React developers who are still using older versions of the library are probably aching to upgrade. And for a good reason. Among other improvements, React Router v6 has been built from the ground up using React hooks, making it more compatible with future versions of React and reducing its bundle size significantly. But, as with every major upgrade, inevitably there are breaking changes.

One of the major blockers when it comes to switching to React Router v6 is that the new version fully embraces React hooks - meaning that the `withRouter` HOC (higher-order component) is no longer part of the library.

As a consequence, if `withRouter` is used extensively in our application, especially with class components that cannot be immediately switched to React hooks, we are in for a major refactor.

Thankfully, there's an easy way around it. Let's create our own `withRouter` HOC!

## Creating our own `withRouter` HOC

As pointed out in [React Router's FAQ page](https://reactrouter.com/docs/en/v6/getting-started/faq#what-happened-to-withrouter-i-need-it) - creating our own wrapper to replicate `withRouter` is trivial:

```js
import { useLocation, useNavigate, useParams } from 'react-router-dom';

function withRouter(Component) {
  function ComponentWithRouterProp(props) {
    let location = useLocation();
    let navigate = useNavigate();
    let params = useParams();
    return (
      <Component
        {...props}
        location={location}
        params={params}
        navigate={navigate}
      />
    );
  }

  return ComponentWithRouterProp;
}
```

After, all we need to do is change the `withRouter` imports from `react-router` to the location of our new component, and we are done! Everything is working as before.

Now we can gradually transition away from `withRouter` without having to refactor everything at once.

But wait, what if we are using Typescript? Surely, we want to preserve type safety with our new HOC.

## Adding Typescript types to `withRouter`

Creating types for a React HOC can be tricky. Let's see how we can go about it in this case:

```js
import React from 'react';
import {
  useLocation,
  useNavigate,
  useParams,
  useSearchParams,
} from 'react-router-dom';

/** @deprecated Use `React Router hooks` instead */
export interface WithRouterProps {
  location: ReturnType<typeof useLocation>;
  params: Record<string, string>;
  navigate: ReturnType<typeof useNavigate>;
}

/** @deprecated Use `React Router hooks` instead */
export const withRouter = <Props extends WithRouterProps>(
  Component: React.ComponentType<Props>
) => {
  return (props: Omit<Props, keyof WithRouterProps>) => {
    const location = useLocation();
    const params = useParams();
    const navigate = useNavigate();

    return (
      <Component
        {...(props as Props)}
        location={location}
        params={params}
        navigate={navigate}
      />
    );
  };
};
```

As you can see above, to type the props coming from the `react-router-dom` hooks, we can use the types from the library itself. We are also using a Typescript generic for the prop types of the component that is being wrapped in `withRouter`. That's it!

We've also added a deprecation warnings for both `withRouter` and `withRouterProps` to document our preference for `react-router-dom` hooks.

## Testing `withRouter` with Jest

Finally, in order to unit test components that are using `withRouter` with Jest, we might need to mock the implementation:

```js
jest.mock('../withRouter', () => {
  return {
    withRouter: (Component: React.ComponentType<WithRouterProps>) => {
      return (props: WithRouterProps) => {
        return <Component {...props} params={{ id: '1' }} />;
      };
    },
  };
});
```

Alternatively, we can also create a global mock for it the appropriate `__mocks__` folder:

```js
import React from 'react';

export const withRouter = (Component: React.ComponentType<WithRouterProps>) => {
  return (props: : WithRouterProps) => {
    return <Component {...props} location={{ pathname: 'pathname' }} />;
  };
};
```

And reuse the mock in our tests by including it in the test file:

```js
jest.mock('../withRouter');
```

For more information on how to migrate to React Router v6, check out [the documentation.](https://reactrouter.com/docs/en/v6/upgrading/v5).

Also, learn how to properly turn a [React Button component into a React Router Link.](https://whereisthemouse.com/how-to-use-button-as-link-in-react)

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


Complete guide on how to re-create and use withRouter HOC in React Router v6 with Typescipt

How to use withRouter HOC in React Router v6 with Typescript


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

Building thought-out and creative UIs is difficult. Even excellent UX/UI designs can never tell the full story of a web app.

Because they are only a static representation of something inherently dynamic, it’s up to developers to make designs come to life, which, of course, means taking into account all possible states.

In this article, we’ll cover good practices to use in client-side rendered React apps when handling loading, error, and empty state.

## React components

Imagine we want to recreate the table from [Wikipedia’s list of cat breeds](https://en.wikipedia.org/wiki/List_of_cat_breeds) with React and [Chakra UI](https://chakra-ui.com/) in the context of the single page application (SPA) we are building.

The image below is the design we aim to achieve. Simple enough, right?

![Table with cat breeds](https://cdn.hashnode.com/res/hashnode/image/upload/v1646838466579/VRjV5TVQ8F.png)

To begin with, let’s extract our cat breeds data into a separate file, data.json:

```json
[
  {
    "name": "Abyssinian",
    "origin": "Unspecified, but somewhere in Afro-Asia likely Ethiopia",
    "type": "Natural",
    "bodyType": "Semi-foreign",
    "coat": "Short",
    "pattern": "Agouti",
    "imgUrl": "https://upload.wikimedia.org/wikipedia/commons/thumb/9/9b/Gustav_chocolate.jpg/200px-Gustav_chocolate.jpg"
  },
  {
    "name": "Aegean",
    "origin": "Greece",
    "type": "Natural",
    "bodyType": "Moderate",
    "coat": "Semi-long",
    "pattern": "Multi-color",
    "imgUrl": "https://upload.wikimedia.org/wikipedia/commons/thumb/5/51/Aegean_cat.jpg/200px-Aegean_cat.jpg"
  }
]
```

We can now create a TableComponent that relies on this data:

```js
import { Table, Thead, Tbody, Tr, Th, Td } from '@chakra-ui/react';
import data from '../public/data.json';

const TableComponent = () => {
  return (
    <Table colorScheme="blue" overflow="none">
      <Thead>
        <Tr>
          <Th></Th>
          <Th>Name</Th>
          <Th>Origin</Th>
          <Th>Type</Th>
          <Th>Body type</Th>
          <Th>Coat</Th>
          <Th>Pattern</Th>
        </Tr>
      </Thead>
      <Tbody>
        {data.map((cat) => (
          <Tr key={cat.name}>
            <Td p="2">
              <Box
                bgImage={cat.imgUrl}
                w="150px"
                h="150px"
                backgroundSize="cover"
              />
            </Td>
            <Td>{cat.name}</Td>
            <Td>{cat.origin}</Td>
            <Td>{cat.type}</Td>
            <Td>{cat.bodyType}</Td>
            <Td>{cat.coat}</Td>
            <Td>{cat.pattern}</Td>
          </Tr>
        ))}
      </Tbody>
    </Table>
  );
};
```

Done! It looks exactly as expected.

But this implementation is also very naive! The data for our cats table is simply hard-coded. In a real-world React app, it will most likely come from a server. This, in turn, means that it will not be immediately available when the user opens the page. We have to wait for it.

## Loading state

Now we come to the first state that is not explicitly included in the image above, the loading state. When we request the data, we need to indicate to our users that something is loading while we wait for the server response. Otherwise, they will just see a blank screen.

So, let’s add a Spinner to our TableComponent:

```js
import React, { useState } from "react";
import {
  ...
  Spinner
} from "@chakra-ui/react";
import useCats from "./useCats";

const TableComponent = () => {
  // Custom data-fetching hook to handle the server request
  const { data, isLoading } = useCats();

  if (isLoading) {
    return <Spinner />;
  }

  return (
    <Table>
      ...
    </Table>
  );
};
```

This is starting to look much more realistic already. But here is a thought: do we need to show a spinner every time we are fetching the table data?

What if we want to navigate between pages, for example? It would be disruptive for the table to disappear and a spinner to appear every time the user goes to a new page. The same applies if we implement a search.

Or, what if we have already cached the table data in our app, but we still want to re-fetch it in the background to ensure it’s not stale? Once again, while we re-fetch, it will be much better for the user to be able to see the already available data instead of a spinner.

For our UI to truly feel polished, we need to indicate to users when something is happening in the background. It looks like we need a second loading state, one that allows us to also display our TableComponent.

Let’s add it!

```js
import React, { useState } from "react";
import {
  ...
  Spinner,
  Progress,
} from "@chakra-ui/react";
import useCats from "./useCats";

const TableComponent = () => {
  const { data, isLoading } = useCats();

  if (isLoading && !data) {
    return <Spinner />;
  }

  return (
    <>
      {isLoading && (
        <Progress />
      )}
      <Table>
        ...
      </Table>
    </>
  );
};
```

This is neat! We now show our Spinner only when there is no data to show the user. Otherwise, we display the much more subtle Progress on top of the table.

But what if there is no data at all?

## Empty state in React

Because our data is coming from a server, we can’t know for sure if there will be data at all. We might receive an empty list. If this happens with our current implementation, the user will only see the Table headers, which will be pretty confusing.

We should add an empty state with an appropriate message to our component to account for this scenario:

```js
import React, { useState } from "react";
import {
  ...
  Spinner,
  Progress,
  Text
} from "@chakra-ui/react";
import { SearchIcon } from "@chakra-ui/icons";
import useCats from "./useCats";

const EmptyState = () => {
  return (
    <Box>
      <SearchIcon />
      <Text>
        No cats found!
      </Text>
    </Box>
  );
};

const TableComponent = () => {
  const { data, isLoading } = useCats();

  if (isLoading && !data) {
    return <Spinner />;
  }

  if (data?.length === 0) {
    return <EmptyState />;
  }

  return (
    <>
      {isLoading && (
        <Progress />
      )}
        <Table>
          ...
        </Table>
    </>
  );
};
```

Perfect! We are almost done. There is just one last thing to consider.

## Error state in React

Because we are relying on a server response for our data, it is important to consider a situation where our request fails. If this is the case, we need to show our user an appropriate error message.

Let’s do it:

```js
import React, { useState } from "react";
import {
  ...
  Alert,
  AlertIcon,
  AlertTitle,
  AlertDescription
} from "@chakra-ui/react";
import useCats from "./useCats";
...
const ErrorState = () => {
  return (
    <Alert status="error">
      <AlertIcon />
      <AlertTitle mr={2}>An error occured!</AlertTitle>
      <AlertDescription>Please contact us for assistance.</AlertDescription>
    </Alert>
  );
};

const TableComponent = () => {
  const { data, isLoading, isError } = useCats();

  if (isError) {
    return <ErrorState />;
  }

  if (isLoading && !data) {
    return <Spinner />;
  }

  if (data?.length === 0) {
    return <EmptyState />;
  }

  return (
    <>
      {isLoading && (
        <Progress size="xs" isIndeterminate w="100%" position="fixed" top="0" />
      )}
      <Table colorScheme="blue" overflow="none">
        ...
      </Table>
    </>
  );
};
```

Our component now works perfectly. We have truly thought of every possible scenario. Curious about the code? Play with it yourself [here](https://codesandbox.io/s/chakra-ui-table-jpg9f?file=/src/useCats.tsx).

Keep in mind that the above is a simplified example based on a single table component. In a real-world app, there might be dozens of pages with many tables and components that all need their own loading, error, and empty states.

So, you may be wondering: is there a way to implement our approach at scale?

## Datafetching UIs at scale

In order to implement a scalable data-fetching solution for our client-side rendered React app, we first need to have the right tools for the job at our disposal. Here are some helpful tips.

First, use an established, battle-tested data-fetching library to handle data synchronization and caching. Creating something like this from scratch is both difficult and unnecessary.

There are a number of good options for this. My personal preference is [React Query](https://react-query.tanstack.com/). Once we start using a data-fetching library, it becomes trivial to implement a custom React hook, similar to our useCats example, for every request we might need to make.

As shown in the example above, these hooks contain all of the information we need to implement each of our component data-fetching states.

Then, take advantage of a component library or, at the very least, build the loading, error, and empty states components with reusability in mind. In our example, we are using Chakra UI for the basic building blocks. But we also separated our ErrorState and EmptyState components from the main table, ensuring we can use them again in other places in our app.

Finally, UX/UI consistency across the application is really important for users. To enhance it even further, make sure to standardize the way data-fetching states are handled. This can be done by abstracting even further the conditional rendering logic we used above.

If, for some reason, abstraction is not a good option, make sure to at least strongly encourage standardization throughout the codebase through convention and/or linter rules.

## React Suspense for data-fetching

Before we wrap up this overview, it is important to mention that a major React update is in the making — [React Suspense for data fetching](https://reactjs.org/docs/concurrent-mode-suspense.html). This new feature will allow us to declaratively wait for anything asynchronous, including data. It will be, in many ways, a paradigm shift in our thinking about data in React as we switch from a “fetch-on-render” to a “render-as-you-fetch” approach (more information about this shift can be found [here](https://reactjs.org/docs/concurrent-mode-suspense.html#traditional-approaches-vs-suspense)).

Let’s re-implement our component with Suspense to see how it works. First, we need to create a fake API for our data.

```js
import data from './data.json';

export function fetchData() {
  let catsPromise = fetchCats();
  return {
    cats: wrapPromise(catsPromise),
  };
}

function wrapPromise(promise) {
  let status = 'pending';
  let result;
  let suspender = promise.then(
    (r) => {
      status = 'success';
      result = r;
    },
    (e) => {
      status = 'error';
      result = e;
    }
  );
  return {
    read() {
      if (status === 'pending') {
        throw suspender;
      } else if (status === 'error') {
        throw result;
      } else if (status === 'success') {
        return result;
      }
    },
  };
}

function fetchCats() {
  console.log('fetch cats...');
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log('fetched cats');
      resolve(data);
      // reject();
    }, 1100);
  });
}
```

Note: this is just an example implementation, not production-ready code!

### Loading state with React Suspense

With the API in place, we can add our loading state to the Suspense fallback.

```js
import React, { Suspense } from "react";
import { ChakraProvider } from "@chakra-ui/react";
import * as ReactDOM from "react-dom";
import Table from "./Table";
import LoadingState from "./LoadingState";

const rootElement = document.getElementById("root");
ReactDOM.createRoot(rootElement).render(
  <ChakraProvider>
    <Suspense fallback={<LoadingState />}>
      <Table />
    </Suspense>
  </ChakraProvider>
);
And change our component accordingly:

import React from "react";
import { Table, ... } from "@chakra-ui/react";
import { SearchIcon } from "@chakra-ui/icons";
import { fetchData } from "./fakeApi";
import EmptyState from "./EmptyState"

const data = fetchData();

const TableComponent = () => {
  const cats = data.cats.read();

  if (cats?.length === 0) {
    return <EmptyState />;
  }

  return (
      <Table colorScheme="blue" overflow="none">
        ...
      </Table>
  );
};
export default TableComponent;
```

Nice, we are now using Suspense for data fetching! Also, as we can see, the empty state implementation remains the same as before.

But what happened to our error handling?

### Error state with React Suspense

Another interesting change that comes with using Suspense for data fetching is that we can handle fetching errors the same way we handle rendering errors. For this we will need to use — you guessed it — ErrorBoundary.

Let’s add it to our app:

```js
import React, { Suspense } from 'react';
import { ChakraProvider } from '@chakra-ui/react';
import * as ReactDOM from 'react-dom';
import Table from './Table';
import LoadingState from './LoadingState';
import ErrorState from './ErrorState';
import ErrorBoundary from './ErrorBoundary';

const rootElement = document.getElementById('root');
ReactDOM.createRoot(rootElement).render(
  <ChakraProvider>
    <ErrorBoundary fallback={<ErrorState />}>
      <Suspense fallback={<LoadingState />}>
        <Table />
      </Suspense>
    </ErrorBoundary>
  </ChakraProvider>
);
```

Perfect, now we are able to display our error component just as we did before. Check out this [Code Sandbox](https://codesandbox.io/s/react-suspense-example-ievxn) for a working example.

There are several advantages to using these anticipated new features. With their help, we can granularly control error and loading states in our app through the placement of the Suspense and ErrorBoundary components.

At the same time, data fetching and rendering logic remain decoupled (fetching kicks off before rendering). With Suspense, it is also possible to [avoid race conditions](https://reactjs.org/docs/concurrent-mode-suspense.html#suspense-and-race-conditions) that often plague more traditional approaches.

While React Suspense is not a data-fetching library by itself, there are steps being taken to integrate it into existing solutions.

These new React updates are very exciting and a lot of fun to play with! But it’s important to remember that it’s all still experimental and subject to change. For the most up-to-date information, you can follow the discussions in the [React 18 Working Group repo](https://github.com/reactwg/react-18/discussions).

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};

;


Here, we cover the best practices to use in client-side rendered React apps when handling loading, error, and empty state

Good practices for loading, error, and empty states in React


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

Lists are ubiquitous in modern web apps.
And keyboard accessibility is becoming increasingly important.

So let's build a keyboard-friendly list in React!

## The List component

First, we should create the list component itself. In its most simplified form, it might look something like this:

```js
const list = ['🍎 apple', '🍊 orange', '🍍 pineapple', '🍌 banana'];

const List = () => {
  return (
    <div>
      {list.map((item) => (
        <div key={item}>{item}</div>
      ))}
    </div>
  );
};
```

## useKeyPress custom hook

Next, we need to know when a user pressed `ArrowUp` or `ArrowDown` keys so we can implement the arrow key navigation logic based on these events. Let's create a custom hook to detect a key press.

```js
const useKeyPress = (targetKey) => {
  const [keyPressed, setKeyPressed] = useState(false);

  useEffect(() => {
    const downHandler = ({ key }) => {
      if (key === targetKey) {
        setKeyPressed(true);
      }
    };

    const upHandler = ({ key }) => {
      if (key === targetKey) {
        setKeyPressed(false);
      }
    };

    window.addEventListener('keydown', downHandler);
    window.addEventListener('keyup', upHandler);

    return () => {
      window.removeEventListener('keydown', downHandler);
      window.removeEventListener('keyup', upHandler);
    };
  }, [targetKey]);

  return keyPressed;
};
```

_The useKeyPress custom hook heavily inspired by [useHooks](https://usehooks.com/useKeyPress/) but slightly modified so that we comply with the [rules of hooks](https://reactjs.org/docs/hooks-rules.html) as defined in the React docs and more specifically - `exhaustive-deps`._

## Detect a key press with useEffect

Next step is to detect when the user pressed `arrowUp` or `arrowDown` in our list component. To do this, we will need our new `useKeyPress` hook and `useEffect`.

```js
const List = () => {
  const arrowUpPressed = useKeyPress('ArrowUp');
  const arrowDownPressed = useKeyPress('ArrowDown');

  useEffect(() => {
    if (arrowUpPressed) {
      console.log('arrowUpPressed');
    }
  }, [arrowUpPressed]);

  useEffect(() => {
    if (arrowDownPressed) {
      console.log('arrowDownPressed');
    }
  }, [arrowDownPressed]);

  return (
    <div>
      {list.map((item, i) => (
        <div key={item}>{item}</div>
      ))}
    </div>
  );
};
```

Perfect! We are now able to detect the relevant key press events in our component.

## Arrow key navigation logic with useReducer

Next, we need to implement the arrow key navigation logic of the component with `useReducer`.

```js
const initialState = { selectedIndex: 0 };

const reducer = (state, action) => {
  switch (action.type) {
    case 'arrowUp':
      return {
        selectedIndex:
          state.selectedIndex !== 0 ? state.selectedIndex - 1 : list.length - 1,
      };
    case 'arrowDown':
      return {
        selectedIndex:
          state.selectedIndex !== list.length - 1 ? state.selectedIndex + 1 : 0,
      };
    case 'select':
      return { selectedIndex: action.payload };
    default:
      throw new Error();
  }
};

const List = () => {
  const arrowUpPressed = useKeyPress('ArrowUp');
  const arrowDownPressed = useKeyPress('ArrowDown');
  const [state, dispatch] = useReducer(reducer, initialState);

  useEffect(() => {
    if (arrowUpPressed) {
      dispatch({ type: 'arrowUp' });
    }
  }, [arrowUpPressed]);

  useEffect(() => {
    if (arrowDownPressed) {
      dispatch({ type: 'arrowDown' });
    }
  }, [arrowDownPressed]);

  return (
    <div>
      {list.map((item, i) => (
        <div
          key={item}
          onClick={() => {
            dispatch({ type: 'select', payload: i });
          }}
          style={{
            cursor: 'pointer',
            color: i === state.selectedIndex ? 'red' : 'black',
          }}
        >
          {item}
        </div>
      ))}
    </div>
  );
};

export default List;
```

Let's break it down!

We've created a reducer with three possible actions - `arrowUp`, `arrowDown` and `select`. The first two actions are dispatched their respective `useEffect` hooks if the relevant key is pressed. The `select` action is dispatched if a user clicks on an item with the mouse.

## Enable tab navigation & accessibility

Finally, to make sure our component is fully accessible and usable for those who use the `tab` key to navigate web pages, let's add `tabIndex`, `role`, `aria-pressed` and `onKeyPress` handler to our list item:

```js
<div
  key={item}
  onClick={() => {
    dispatch({ type: 'select', payload: i });
  }}
  style={{
    cursor: 'pointer',
    color: i === state.selectedIndex ? 'red' : 'black',
  }}
  role="button"
  aria-pressed={i === state.selectedIndex}
  tabIndex={0}
  onKeyPress={(e) => {
    if (e.key === 'Enter') {
      dispatch({ type: 'select', payload: i });
      e.target.blur();
    }
  }}
>
  {item}
</div>
```

That's it! We now have a fully accessible and keyboard-friendly React list. 🚀

Please keep in mind this is a simplified example. The goal is to shine a light on the main steps in the implementation rather than to provide production-ready code!

Curious to play with the code yourself? Here is a working [CodeSandbox example](https://codesandbox.io/s/keyboard-navigable-list-in-react-4d4jt).

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


Take advantage of useEffect, useReducer and useKeyPress custom hook to build a keyboard-friendly React component

Create a List component with keyboard navigation in React

Understand the difference between React state management tools, including React context, Redux, React Query, Recoil and xState

How to choose the best state management solution in React


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

Using a GraphQL API comes with distinct advantages. With GraphQL, we can request the exact data we need without ever under- or over-fetching. We can also get multiple resources in a single request. At the same time, the requests themselves can serve as a form of documentation, making it is easy to understand what data is being used, where, and why.

But the most exciting feature of GraphQL is that the API is fully described by its schema, including all data types for each possible query or mutation.

Why does this matter?

Because, based on that schema, we can automatically create TypeScript types for the entire API on the frontend. What’s more is we can easily autogenerate fully-typed custom React hooks for a data-fetching library like [React Query](https://react-query.tanstack.com/) .

Let me show you how.

## Setting up the project with GraphQL

### React app

First, let's create our React project with Create React App with the TypeScript template.

`yarn create react-app graphql --template typescript`

### GraphQL API

Next, we need an API. [FakeQL](https://fakeql.com/) provides a great way to create a mock GraphQL API and deploy it. Because we will be using the default definition, we can set everything up simply by clicking Extend JSON and then Deploy. The tool generates a unique URL where we can access our new API.

### Data-fetching library

Now that we have our React app and our API, it is time to set up our data-fetching library, React Query.

Let's install it:

```console
yarn add react-query
```

Now, set up the React Query client.

```ts
import { QueryClient, QueryClientProvider } from 'react-query';

import Posts from 'components/Posts';

const queryClient = new QueryClient();

const App = () => {
  return (
    <QueryClientProvider client={queryClient}>
      <Posts />
    </QueryClientProvider>
  );
};

export default App;
```

### Component

Because our API provides a list of posts, we will use a `Posts` component to display them. For the moment, let’s leave it empty.

```ts
// components/Posts.tsx

const Posts = () => {
  return <></>;
};

export default Posts;
```

Next, we need a query to get the list of posts. Let’s define it in a `.graphql` file and co-locate it with our component:

```
# components/Posts/posts.graphql

query Posts {
  posts {
    id
    title
  }
}
```

Finally, let’s also add a mutation for deleting a post:

```ts
# components/Posts/deletePost.graphql

mutation DeletePost($id: ID!) {
    deletePost(id: $id)
}
```

## Auto-generate typed React Query hooks with TypeScript and GraphQL Codegen

We are now ready to auto-generate our custom and fully typed React Query hooks based on the requests we previously defined in our .`graphql` files. We will be using [GraphQL Code Generator.](https://graphql-code-generator.com/)

We start by installing it:

```console
yarn add graphql
yarn add -D @graphql-codegen/cli
```

Next, we need to initialize the wizard and go through the steps:

```console
yarn graphql-codegen init
```

First, we choose the type of app we are building:

![Application built with React](https://paper-attachments.dropbox.com/s_1C8EAE8DC9F518921163B24338607F32918C4F1A5CC5D807CB9302033C4F0861_1614500727839_image.png)

Then, we define our schema is by pasting our FakeQL url.

![Where is your schema? FakeQL url pasted](https://paper-attachments.dropbox.com/s_1C8EAE8DC9F518921163B24338607F32918C4F1A5CC5D807CB9302033C4F0861_1614500541614_image.png)

We define where our operations and fragments are:

![Where are your operations and fragments? src/**/*.graphql](https://paper-attachments.dropbox.com/s_1C8EAE8DC9F518921163B24338607F32918C4F1A5CC5D807CB9302033C4F0861_1614500628662_image.png)

We choose our plugins:

![Typescript and Typescript Operations selected](https://paper-attachments.dropbox.com/s_1C8EAE8DC9F518921163B24338607F32918C4F1A5CC5D807CB9302033C4F0861_1614500777731_image.png)

We choose where to write the output:

![Where you write the output? src/generated/index.ts](https://paper-attachments.dropbox.com/s_1C8EAE8DC9F518921163B24338607F32918C4F1A5CC5D807CB9302033C4F0861_1614500850352_image.png)

Let’s also generate an introspection file:

![Do you want to generate an introspection file? yes](https://paper-attachments.dropbox.com/s_1C8EAE8DC9F518921163B24338607F32918C4F1A5CC5D807CB9302033C4F0861_1614500882216_image.png)

We need to name our config file:

![How to name the config file? codegen.yml](https://paper-attachments.dropbox.com/s_1C8EAE8DC9F518921163B24338607F32918C4F1A5CC5D807CB9302033C4F0861_1614500917361_image.png)

Finally, let’s name our script `graphql:codegen`:

![What script in package.json should run the codegen? graphql:codegen](https://paper-attachments.dropbox.com/s_1C8EAE8DC9F518921163B24338607F32918C4F1A5CC5D807CB9302033C4F0861_1614500962771_image.png)

So far, so good!

In order to generate custom React Query hooks, we need to install the appropriate plugin:

```console
yarn add -D @graphql-codegen/typescript-react-query
```

And add a quick edit of the codegen.yml config file in order to make it work:

```yml
overwrite: true
schema: 'https://fakeql.com/graphql/2aaf00462236e8280f4c3beb197aae54'
documents: 'src/**/*.graphql'
generates:
  src/generated/index.ts:
    plugins:
      - typescript
      - typescript-operations
      - typescript-react-query
    config:
      fetcher:
        endpoint: 'https://fakeql.com/graphql/2aaf00462236e8280f4c3beb197aae54'
```

Finally, we need to run our script.

```console
yarn graphql:codegen
```

We are now done! Our fully-typed custom React Query hooks have been automatically generated and added directly to our project’s `generated` folder.

Let’s see them in action!

## Making API requests

In our `Posts` component, we are now ready to display the list of posts:

```ts
import { usePostsQuery } from 'generated';

const Posts = () => {
  const { data } = usePostsQuery();
  return (
    <>
      {isLoading && <p>Loading ...</p>}
      {data &&
        data.posts?.map((post) => (
          <div key={post?.id}>
            <p>{post?.title}</p>
            <hr />
          </div>
        ))}
    </>
  );
};

export default Posts;
```

Let’s also add the `DeletePost` mutation we defined earlier.

```ts
import { useQueryClient } from 'react-query';
import { usePostsQuery, useDeletePostMutation } from 'generated';

const Posts = () => {
  const queryClient = useQueryClient();
  const { data, isLoading } = usePostsQuery();
  const { mutate } = useDeletePostMutation({
    onSuccess: () => queryClient.invalidateQueries('Posts'),
  });

  return (
    <>
      {isLoading && <p>Loading ...</p>}
      {data &&
        data.posts?.map((post) => (
          <div key={post?.id}>
            <p>{post?.title}</p>
            <button onClick={() => post && mutate({ id: post.id })}>
              Delete
            </button>
            <hr />
          </div>
        ))}
    </>
  );
};

export default Posts;
```

That’s it, we now have a working example!

## Conclusion

The approach described above allows us to take full advantage of GraphQL on the frontend by automating both the creation of TypeScript types for the API and the generation of custom React Query hooks for each request.

By using it, we have also substantially reduced the amount of data-fetching boilerplate code we need to write. With this tooling in place, all we need to do in order to create additional React Query custom hooks for a request is to create a `.graphql` file and run the `graphql:codegen` script. Pretty cool, right?

Curious to play with the code yourself? Find a full working example in my [GitHub repo](https://github.com/IvaKop/React-Query-Typescript-GraphQL-Code-Generator-Example) .

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


A complete guide to creating the perfect data-fetching setup in React with GraphQL, React Query and Typescript

GraphQL requests made easy with React Query and TypeScript


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

NextJS is a great tool for building React apps. It comes with a lot of flexibility and awesome features like [static site generation](https://nextjs.org/docs/advanced-features/static-html-export) (with `next export`) and [image optimization](https://nextjs.org/docs/basic-features/image-optimization) (with the `next/image` component).

But there is a problem.

Currently, it is not possible to take advantage of the `Image` component when creating a fully-static site with NextJS. Image optimization at build time is not supported out of the box. What is worse, there is [little mention](https://nextjs.org/docs/migrating/from-gatsby#migrating-from-gatsby-image) of this limitation in the NextJS docs, leading many developers, including myself, to discover it the hard way - by trying to use `next/image` with `next export` and discovering that it simply does not working.

There is an [ongoing discussion](https://github.com/vercel/next.js/discussions/19065) in the community about solving the issue. Support for build time image optimization is currently one of the most requested NextJS features. Hopefully, there will be some good news on that front soon.

In the meanwhile, luckily, there is a workaround!

## next-optimized-images to the rescue!

[`next-optimized-images`](https://github.com/cyrilwanner/next-optimized-images) is a NextJS plugin which reduces image size by optimizing images during build. This means we can use it with `next export` and solve the problem of image optimization for our static site.

So let's do it!

### Install

First we need to install the plugin and the relevant optimization packages. For our use case, let's say we need to be able to optimize `jpeg`, `png` and `svg` files:

```console
yarn add next-optimized-images imagemin-mozjpeg imagemin-optipng imagemin-svgo
```

### Configure

Next, we need to add the appropriate configuration to our `next.config.js` file:

```js
// next.config.js

const withOptimizedImages = require('next-optimized-images');

module.exports = withOptimizedImages({
  handleImages: ['jpeg', 'png', 'svg'],
});
```

### TypeScript

If we are using TypeScript and we try to import an image, we will get a complaint similar to:

```console
Cannot find module 'images/logo.svg' or its corresponding type declarations.

```

Let's fix that by adding the following to types/global.d.ts

```ts
declare module '*.svg' {
  const content: any;
  export default content;
}

declare module '*.png' {
  const content: any;
  export default content;
}

declare module '*.jpeg' {
  const content: any;
  export default content;
}
```

### Tests

For our tests to work as expected, we will also need to create a file mock:

```js
// testUtil/fileMock.js

module.exports = {
  process() {
    return `module.exports = 'test-file-stub'`;
  },
};
```

And add it to the `jest.config.js`

```js
// jest.config.js

module.exports = {
    ...
    moduleNameMapper: {
        '.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$':
            '<rootDir>/testUtil/fileMock.js',
    },
}
```

### Usage

We should add our images to the `images` directory of our app (unless we have specified otherwise in the `next.config.js` file).

We can now import and use images in our components:

```js
// components/Navigation.tsx

import logo from 'images/logo.svg';

const Navigation = () => {
  return (
    <nav>
      <img src={logo} alt="logo" />
    </nav>
  );
};

export default Navigation;
```

## Generate static site

Finally, let's create our static NextJS site with optimized images:

```console
next build && next export
```

Our project `out` directory now contains our static site.

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


Learn how to do image optimization in statically exported NextJS sites

Image optimization for static NextJS sites


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

In the beginning of every new React project, one question inevitably floats to the surface - should we use client-side rendering (CSR), server-side rendering (SSR) or generate a static site (SSG). It is a strategic decision which depends on several key factors.

But first, a quick review!

> Note: Feel free to <a href="#skip">skip </a> the review if you are already familiar with the basics of the three approaches. 🚀

## Client-side rendering

In essence, CSR simply means that we are using Javascript to render the contents of our app in the browser. Imagine a standard single page React application built with [`create-react-app` ](https://reactjs.org/docs/create-a-new-react-app.html) or a similar tool. When we execute the build script, what we can expect to find in our `build` folder (among other things) is a relative bare-bone `index.html` file together with our Javascript bundle (likely split in chunks).

Whenever someone visits our app in their browser, they would be able to only see the contents of the (almost empty) `index.html` file until the necessary Javascript is downloaded and executed. Afterwards, users will be able to both view and interact with the contents of our app.

At this point, additional data may be fetched from a server and displayed by the app, if needed.

## Static site generation

By contrast, when we are creating a static site, we need all the contents and data of our app to be available upfront. The reason is that using SSG means we generate full-fledged HTML files already during the build step.

What we gain with this approach is that the user doesn't have to wait for any Javascript to download and execute before being able to see the initial content on the page. On the flip side, needing all the data upfront also means that whenever a change is needed, we have to recreate and redeploy the entire build. This can quickly become cumbersome if frequent updates are needed.

Still, static sites can be an excellent tool. And frameworks like [Gatsby](https://www.gatsbyjs.com/) and [NextJS ](https://nextjs.org/) make it increasingly easy to create them in React.

## Server-side rendering

Finally, server-side rendering means that we are using a server to render the contents of our HTML files and serve them to the client when requested. As with SSG, the user does not have to wait for the Javascript to be downloaded and executed before being able to view the page initially.

An important difference is that instead of having already generated static files, we are able to dynamically determine the content what is being served to the client. No rebuilds necessary. The trade-off is that what we gain in flexibility comes at the cost of an additional server and very possibly some added complexity compared to the other options.

Luckily, tools like [NextJS](https://nextjs.org/) do a good job of streamlining the development of React apps with SSR.

<div id="skip"></div>
## Decision time

Now that we have a basic understanding of what our options are, let's take a closer look at how we can choose between them.

### 🔍 Search engine optimization

The importance of SEO is a key consideration. As already mentioned, with CSR the initial HTML file is very minimal and Javascript is needed to render the app. This also means that the initial load time before meaningful content appears would be longer with CSR than with the alternatives. This is bad for SEO.

By contrast, with both SSR and SSG, the initial HTML files already contain meaningful content. This makes them easily crawlable and indexable by search engines. In addition, creating page-specific link previews when sharing links on social platforms, for example, is trivial with SSR and SSG while downright impossible with CSR (unless we use a service like [prerender.io](https://prerender.io/) to generate them).

Is SEO always a must? Not every app needs to be search engine optimized. SEO might not be relevant if the entire app is behind a login, for example. In this case, the contents are only accessible to logged in users anyway so the lack of SEO is not a huge concern.

### 🌀 Dynamic content

The second important factor to consider is how dynamic is the content of the website we are building. One of the main drawbacks of the SSG approach is that in order to update the content of the app, we need to rebuild it. This might be perfectly fine if the app consists of mostly static content and is not frequently updated. A good use case for SSG would be a personal blog or a marketing website, for example.

However, in many cases, our applications need to be a lot more dynamic than that. Consider a dashboard app which needs to display up to date, personalised data for each user. It would be impractical to try to generate this statically. In this case opting for CSR is a much better choice. With it, we are able to fetch the necessary data for the specific user on the client, display it and seamlessly keep it up to date.

Here is another scenario. What if we are building a news site, where the content is both public and constantly updated. What if, in addition, there is some user generated content involved like comments under the articles, for example? Once again, SSG would not be ideal in this context. It would be much preferable to take advantage of SSR instead, with its ability to serve dynamic, non-stale, search engine optimized HTML files and easily reflect updates upon each request.

### ⌛ Initial load time

Initial load time can be an important UX consideration, especially if our users are in a place with slow internet connection or we expect the app to be used on (relatively) old devices. With both SSG and SSR we are able to show initial meaningful HTML on the screen. Even though users cannot immediately interact with it (we need Javascript for that), the perception is that the app loads quickly. It is worth noting that, with the use of a CDN, statically generated sites would probably perform better than SSR since the content is already generated and cached. However, we also run the risk of it being stale at request time.

On the other hand, using CSR means that all the users see is the empty HTML file (or, at best, a loading screen) until the necessary Javascript is downloaded, executed and able to render the content of the app. This might give users the initial impression that the app is too slow.

### 🌐 Infrastructure

Finally, it is important to think about the ways in which we build and deploy our React apps and the added complexity or cost this might entail. Probably the simplest approach to deployment is if our app build consists of static files. This means we could directly deploy it on a CDN service and our website would be live. With both CSR and SSG this is exactly the case.

With SSR the infrastructure setup is more complex. Using this paradigm means we need a server to pre-render the page into HTML on every request. And even though services like [Vercel](https://vercel.com/) make the deployment of NextJS apps almost seamless, it is important to keep in mind that as the number of users for our app increases, the infrastructure cost might increase with it.

## Conclusion

Here is a quick summary for what we have discussed so far.

|                   | CSR | SSG | SSR |
| ----------------- | --- | --- | --- |
| SEO               | ❌  | ✅  | ✅  |
| Dynamic content   | ✅  | ❌  | ✅  |
| Initial load time | ❌  | ✅  | ✅  |
| Static build      | ✅  | ✅  | ❌  |

So which approach should we choose? As usual, there is no one size fits all solution. The choice should always be determined by our particular use case.

There is also the possibility to mix and match these approaches for different parts of our app. If you want to give combining them a shot, NextJS is [especially flexible](https://vercel.com/blog/nextjs-server-side-rendering-vs-static-generation) in this respect.

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


How to choose between client-side rendering, server-side rendering and static site generation for React apps

CSR, SSR or SSG - choosing the best rendering strategy for React apps


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

There are so many different ways to loop over an array in JavaScript. Sometimes, it becomes genuinely difficult to know which method to choose for a particular use case. And even though a lot of these methods can be used interchangeably to "get the job done", knowing when and how to utilize each one makes our code more readable, maintainable and, in some cases, better optimized.

Let's create an array and explore some more common use cases:

```js
const array = [4, 6, 8, 10, 8, 12, 6, 45, 8];
```

## Multiply by 2

Let's start simple. Our first task is to multiply each item in our array by 2. What do we do?

If we want to create a new array with the result the easiest path is to use `map`:

```js
const result = array.map((item) => item * 2);
```

If the goal is to mutate the original array, `forEach` is a good choice:

```js
array.forEach((item) => item * 2);
```

Cool! Let's do another one.

## Filter out `8`

Here is another common task. Let's say we want to filter the number `8` out of our array. How do we go about it?

Once again, it matters whether we want to create a new array or mutate the existing one.

To create a new array with the desired result, `filter` is a great option:

```js
const result = array.filter((item) => item !== 8);
```

If we want to change our original array, it becomes a bit more tricky. We should use a for loop and begin iterating at the end of the array in order to make sure our indices are correct as we go through the items:

```js
for (let i = array.length - 1; i > 0; i--) {
  if (array[i] === 8) {
    array.splice(i, 1);
  }
}
```

## Counting the occurrences of `8`

Here is our next problem. We want to know how many times `8` occurs in our array. Basically, what we are trying to achieve is to `reduce` the entire array to the number of times we see `8` in there.

So let's do it!

```js
const occurrencesOf8 = array.reduce((count, item) => {
  if (item === 8) {
    count++;
  }
  return count;
}, 0);
```

## Find an element

Another common problem we might encounter is to find a certain element in an array.

Let's say we want to find the number `6` and we also care about its index for some reason. The best way to approach this would be with `indexOf`:

```js
const index = array.indexOf(6); // 1
```

And if we want to know the index of the last occurrence?

```js
const index = array.lastIndexOf(6); // 6
```

But what is we just want to know if a certain item exists in an array. Then `includes` is our best friend:

```js
const has6 = array.includes(6); // true
```

How about if we want to find the first item which satisfies a condition. For example, let's find an item in our array that is greater that 5. In this case, we can take advantage of `find` :

```js
const greaterThan5 = array.find((item) => item > 5); // 6
```

## Check for odd numbers

Let's check if every number in our array is an odd number. Conveniently, we can use `every` for this:

```js
const areAllNumbersOdd = array.every((item) => item % 2 === 1); // false
```

And if we want to know whether there is at least one odd number, `some` is what we need:

```js
const isThereAnOddNumber = array.some((item) => item % 2 === 1); // true
```

## Return the first three numbers larger than `5`

What if, for some reason, we need to create an array with only the first 3 numbers from our original array which are greater than 5?

We could use some of the more succinct methods from above to achieve this. But there is a limitation. What we want is to loop over the array until we find those items and then break out of the loop to avoid unnecessary work. This is not possible with `filter` or `forEach`.

We need to use a `for` loop.

```js
let count = 0;
const result = [];

for (let number of array) {
  if (number > 5) {
    result.push(number);
    count++;
    if (count === 3) {
      break;
    }
  }
}
```

And if we wanted to record the indices, rather than the numbers themselves, we might do something like this:

```js
let count = 0;
const result = [];

for (let i = 0; i < array.length; i++) {
  if (array[i] > 5) {
    result.push(i);
    count++;
    if (count === 3) {
      break;
    }
  }
}
```

## Conclusion

The list above is not exhaustive. It is only meant as an illustration of the most common (albeit somewhat simplistic) scenarios where we need to loop over arrays in JavaScript. The goal is to think critically about the instruments we have at our disposal and do our best to use right tool for the job.

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


Learn all about the different JavaScript array methods and to use each one.

How to loop over an array in JavaScript?


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

A React component is well documented when its purpose and intended usage are clearly communicated. To be self-documenting, a component must simply convey as much relevant information as possible through its own code.

Without further ado, here are five ways to create self-documenting React components.

## 1. Types

Using prop types is always a good idea. It helps us detect unexpected props and catch potential bugs in our application.

But prop types are also a documentation tool. They give us essential information about how we expect a component to be used. Let's look at a simple button:

```js
const Button = ({ onClick, label, icon }) => {
  return (
    <button onClick={onClick}>
      {label}
      {icon}
    </button>
  );
};

Button.propTypes = {
  onClick: PropTypes.func.isRequired,
  label: PropTypes.string.isRequired,
  icon: PropTypes.node,
};
```

We get a lot from the prop types here. We know that we should't render the button without a `label` (which should be a string) or an `onClick` handler (a function) because they are required. We can skip the `icon`, though, if we want.

However, if we are not careful, we can still miss the console warnings and use our `Button` in ways that are now 'allowed'. How can we prevent that?

This is where static typing comes into the picture. Using [Typescript](https://www.typescriptlang.org/), as opposed to just prop types, means we know whether there is a problem with our types at compile time.

This behaviour makes it (almost) impossible for our type definition to become outdated. We can reliably use it as a guide to the intended usage of our component. Not to mention the added bonus of autocompleting props in our IDE.

I like to think of Typescript as a way to enforce documentation.

Let's get a taste of what it looks like:

```ts
type ButtonProps = {
  onClick: () => void;
  label: string;
  icon?: React.ReactNode;
};

const Button = ({ onClick, label, icon }: ButtonProps) => {
  return (
    <button onClick={onClick}>
      {label}
      {icon}
    </button>
  );
};
```

## 2. Tests

Unit tests are one of the best ways to convey the intended functionality of a component. To be good a documentation tool, tests should focus on behavior, not implementation details.

Let's use the `HiddenMessage` test from the [React Testing Library](https://github.com/testing-library/react-testing-library) docs as an example:

```js
import React from 'react';
import { render, fireEvent, screen } from '@testing-library/react';
import HiddenMessage from '../hidden-message';

test('shows the children when the checkbox is checked', () => {
  const testMessage = 'Test Message';
  render(<HiddenMessage>{testMessage}</HiddenMessage>);

  expect(screen.queryByText(testMessage)).toBeNull();

  fireEvent.click(screen.getByLabelText(/show/i));

  expect(screen.getByText(testMessage)).toBeInTheDocument();
});
```

Even without the context of the React component itself, its functionality is clear. We have an input with label "show" which, if clicked, will show the hidden message. The test contains all the information we need to understand the behavior. It serves as, de facto, documentation.

In more complex situations, where there is a lot of interaction and interdependence between components, unit testing might not be enough. In that case, integration tests (even e2e tests) can be an awesome tool to document entire features. [Cypress](https://www.cypress.io/) would be my library of choice in this scenario.

## 3. Storybook

[Storybook](https://storybook.js.org/) is awesome! It's a tool that allows us to develop UI components in isolation. Creating a story can be a convenient way to document every possible state of a component. And all user interactions, as well.

What does a story look like? Here's an example:

```js
import { select, text } from '@storybook/addon-knobs'

import Notification from 'components/Notification'

export const Primary = () => (
        <Notification
            color={select('Color', ['error', 'primary'], 'error')}
            title={text('Title', 'Information')}
            description={text(
                'Some description,
            )}
        />
)

Primary.storyName='Primary notification';
```

We can immediately understand the purpose of this component when looking at the code. Clearly, we can add a title and a description to the notification and also choose one of the two available colors. Using Storybook, we can also play with it in the browser. Since this is a real implementation of our code, we are sure to keep it up to date as we change our component.

As a bonus, Storybook will also automatically generate a Docs page for each component. Learn more about Storybook docs [here](https://storybook.js.org/docs/react/writing-docs/introduction) .

## 4. Names

Component names are important. We want our code to be self-explanatory. But this is such a trivial point. Why are we even mentioning it? We would never name our components in a non-obvious way.

The key issue here is that beauty is in the eyes of the beholder. Whether components are well-named depends largely on the perception of the person who is reading the code, not the one who is writing it.

Here's what I mean. Let's say we want to build a `Table` component. We might create an API like this:

```js
const TableExample = () => {
  return (
    <Table>
      <Header>
        <Cell>....</Cell>
        <Cell>....</Cell>
      </Header>
      <Row>
        <Cell>....</Cell>
        <Cell>....</Cell>
      </Row>
    </Table>
  );
};
```

While writing this code, we have the full context of what we are doing. Therefore, for us, it is self-evident that when I refer to a `Row` or a `Header`, these are part of our `Table`.

But imagine we are working on a project with many complex UI elements. `Row` or `Header` can refer to different components in a more general context. Other developers on our team can become justifiably confused. How can we fix it?

How about we do this instead:

```js
const TableExample = () => {
  return (
    <Table>
      <TableHeader>
        <TableCell>....</TableCell>
        <TableCell>....</TableCell>
      </TableHeader>
      <TableRow>
        <TableCell>....</TableCell>
        <TableCell>....</TableCell>
      </TableRow>
    </Table>
  );
};
```

With this small tweak we eliminate all ambiguity and document the intended usage of the components directly in their names. We can now be certain we have properly communicated their purpose.

## 5. File structure

There is one more way we can convey the why and how of a component within a codebase - by placing it in a specific location within the file structure.

Let's imagine we have a simple React app with two separate pages. The two pages share certain UI elements but are otherwise unique.

A simplified version of the app file structure might look something like this:

```
├── components
├── pages
│   ├── About
│   │   ├── components
│   │   ├── About.js
│   ├── Home
│   │   ├── components
│   │   ├── Home.js
├── App.js

```

We have three component folders. If we create a new component, where do we put it? Our choice communicates whether the new component belongs to the Home page, the About page or both. We have, in effect, used our file structure as a documentation tool.

## Conclusion

This list is far from exhaustive. It is only meant as an illustration of how we can think of our components as communication tools. The choices we make in our code tell a story. And what is a story, if not a document.

Although I focused heavily on React components in the examples above, most of these methods are certainly transferable. Their application goes well beyond React and arguably even beyond web development.

Check out my article on [flexible compound React components](https://whereisthemouse.com/a-guide-to-building-non-trivial-react-components) to learn more about how to build with React.

What are your favourite ways to document React components?

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


Use Typescript, Storybook and Jest, together with a sensible naming covention and file structure in order to create self-documenting React components.

5 ways to create a self-documenting React component


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

Learning how to code can be challenging. It is inherently difficult to master a new skill. Everyone needs direction, especially in the beginning. At the same time, there is so much information out there - courses, tutorials, videos, books, articles, documentation, practice websites, forums and on and on and on. It quickly becomes overwhelming.

In the middle of this information overload, it can be very satisfying to complete a tutorial. It gives us a sense of accomplishment and confidence in our skills. It is a sign that we are learning and making progress.

But after a while, we realize that we spend a lot of our time completing these tutorials. We jump from one to the next. And all we really do is follow predefined steps. The problems we face are both relatively simple and already solved for us. Are we really progressing?

Welcome to tutorial hell!

Luckily, there is a simple way to break out. All we need to do is build something, anything, on our own. It's scary, yes! But it's also essential.

## Take the leap

Let's say we want to build a portfolio website. Maybe we should just find a tutorial on how to do it. Surely, there is a suitable one out there! Or two, or three... Using a tutorial will probably result in a better website than what we could have done on our own, anyway. In the short term, this seems like a great decision.

But there is a danger with this approach. We miss out on the most important lesson - how to solve problems on our own. That's ok if all we want is a portfolio. It is, however, not ideal, if our ultimate goal is to learn how to code.

So what if, instead of opting for a tutorial, we decide to build the entire project from scratch?

It would certainly be a lot harder. We will need to create and implement the entire website structure with HTML. Then, we will have to style it with CSS. We will probably want to add some interactivity to our site, as well. We will need a bit of Javascript for that. Finally, if we want our portfolio to be accessible on our personal domain, we will also have to learn a bit about web hosting.

Phew, this sounds like a lot!

It feels we are back where we started - lost in the jungle of information and overwhelmed by all we need to learn. This is what got us stuck in tutorial hell in the first place, isn't it?

Not exactly!

## Adopt project-based learning

There are several ways in which building a project is different and, ultimately, much more beneficial.

First, the project itself serves as a guide and shows us the way forward in our learning journey. How does it work? It's as simple as continuously asking ourselves a question. What do I need to learn next in order to move the project forward? The answer is different at every stage. But what is so valuable about this approach is that is keeps us focused. Every step we take along the way is deliberate.

To understand this more clearly, look at the portfolio website example above. Already we have defined our steps and learning objectives - HTML, CSS, Javascript and so on. But because we have a concrete goal in mind, we only go through so many HTML tutorials (and yes, we do need tutorials sometimes!) before moving on to the next stage. We learn what we need in the moment. And we don't get stuck.

What is more, the knowledge we gain from building our own thing accumulates more easily. The reason is that we are able to put it into context. Since we faced the problems ourselves, we truly understand the solutions. Over time, this knowledge grows and translates into practical experience.

Finally, at the end of the process, we have a project. And we built it ourselves. We can now use it to showcase our skills.

## Conclusion

As a self-taught developer, I have been stuck in tutorial hell more than once. I know how scary and intimidating it can be to leave the safety of the step by step instructions and jump head first into building something from scratch.

But, frankly, if the goal is to be a developer, there is simply no other choice!

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};

;


When learning how to code, it's easy to get stuck in tutorial hell. The easiest way to break out is to build a real project.

Break out of tutorial help (for developers)


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

Building React components is hard. There are so many different ways to solve the same problem. How can we, as developers, make informed decisions about which approach to choose? More fundamentally, what is the mechanism through which we can ensure we are making the right choice?

Let me give you an example!

## The component

Let's go through the steps of creating a component where a user can choose a subscription plan. It might look something like this:

<iframe
  src="https://ivakop.github.io/subscriptions-component/iframe.html?id=subscription--subscriptions-basic&viewMode=story"
  style={{ width: '100%', height: '500px' }}
  title="Subscription component"
></iframe>

This is a simplified version of a component we built recently for one of our projects. I stripped away the styles so we can focus on the code.

So where do we start?

### The approach

When building a React component, it is important to have a clear idea of the ultimate goal. In this case, let's focus on the following priorities:

1. Usability - make the usage of the component (by developers) as convenient as possible

2. Flexibility - make the component as flexible as possible (without adding unnecessary complexity)

For our concrete example, we want to create our `Subscriptions` component in such a way that, ideally, it handles its state internally - both the selected plan and the selected billing period. It also has a callback though which the information is accessible from the outside.

Let's give it a try!

### The easy way out

At first, we might be tempted to do something like this:

```js
const SubscriptionsPage = ({ subscriptionPlans }) => (
  <Subscriptions
    subscriptionPlans={subscriptionPlans}
    onSelect={(selectedPlan) => {
      // Do something with this data
    }}
  />
);
```

Wow, this looks really easy to use! ✅

But what about flexibility? Imagine that in the future we need to pass a special prop to one of the subscription plans inside? We will have to go through the subscriptionPlans data (likely coming from an API) to add the new prop. Sounds inconvenient...

Or what if I need to insert a component in between those subscription plans to add a message, for example? Or maybe I need to wrap them in an additional component for some reason? I won't be able to do it easily.

Let's think of a better way!

### Array of components

What if we try this instead?

```js
const SubscriptionsPage = ({ subscriptionPlans }) => (
  <Subscriptions
    subscriptionPlans={[
      <SubscriptionPlan {...subscriptionPlanProps} />,
      <SubscriptionPlan {...subscriptionPlanProps} />,
      <SubscriptionPlan {...subscriptionPlanProps} />,
    ]}
    onSelect={(selectedPlan) => {
      // Do something with this data
    }}
  />
);
```

Hm... 🤔 This approach certainly solves some of the flexibility issues. It is now easy to add props to the `SubscriptionPlan` components. But it is still difficult to insert other components between or around those plans. Also, passing the `subscriptionPlans` prop in this way, though sometimes useful, makes the component more difficult to use in this particular case. So even though we improved the flexibility, it came at a price.

Let's try again!

### Composition

How about this?

```js
const SubscriptionsPage = () => (
  <Subscriptions
    onSelect={(selectedPlan) => {
      // Do something with this data
    }}
  >
    <SubscriptionPlan {...subscriptionPlanProps} />
    <SubscriptionPlan {...subscriptionPlanProps} />
    <SubscriptionPlan {...subscriptionPlanProps} />
  </Subscriptions>
);
```

Wow! 😲 This one is so intuitive to use - the `SubscriptionPlan` components are simply nested inside the `Subscriptions`. It is now easy to pass additional props to `SubscriptionPlan`. It is also trivial to add more components between or around any `SubscriptionPlan` component.

We have a winner! ✨

## The implementation

Now that we have a clear idea of what we want to build, it is time to get our hands dirty.

Let's start by creating the radio inputs. As we mentioned above, the state will be controlled by the `Subscriptions` component, so our `RadioGroup` component might look something like this:

```js
import React from 'react';

const RadioGroup = ({ value, onChange }) => (
  <div>
    <input
      type="radio"
      id="monthly"
      name="billingPeriod"
      value="MONTH"
      checked={value === 'MONTH'}
      onChange={(e) => onChange(e.target.value)}
    />
    <label htmlFor="monthly">Monthly</label>
    <input
      type="radio"
      id="annual"
      name="billingPeriod"
      value="ANNUAL"
      checked={value === 'ANNUAL'}
      onChange={(e) => onChange(e.target.value)}
    />
    <label htmlFor="annual">Annual</label>
  </div>
);

export default RadioGroup;
```

Nice start!

How about we add it to the `Subscriptions` component next? Let's also create the Select button with a callback, just to make sure everything works.

```js
import React, { useState } from 'react';

import RadioGroup from './RadioGroup';

const Subscriptions = ({ onSelect, children }) => {
  const [billingPeriod, setBillingPeriod] = useState('MONTH');

  return (
    <div>
      <RadioGroup
        value={billingPeriod}
        onChange={(value) => {
          setBillingPeriod(value);
        }}
      />
      {children}
      <button
        disabled={!selectedPlanId}
        onClick={() => onSelect({ billingPeriod })}
      >
        Select
      </button>
    </div>
  );
};

export default Subscriptions;
```

Good! It looks like all we are missing is the `SubscriptionPlan` and we are ready to go.

Let's create it!

```js
import React from 'react';

const SubscriptionPlan = ({
  id,
  selectedPlanId,
  annualPrice,
  monthlyPrice,
  name,
  onSelectPlan,
  billingPeriod,
}) => {
  const isSelected = selectedPlanId === id;
  const price = billingPeriod === 'MONTH' ? monthlyPrice : annualPrice;

  return (
    <div onClick={() => onSelectPlan(id)}>
      <div>
        <h2>{name}</h2>
        <h2>$ {price}</h2>
      </div>
    </div>
  );
};

export default SubscriptionPlan;
```

But wait...

`SubscriptionPlan` has to be aware of both the selected `billingPeriod` (in order to know which sum to display) and of the `selectedPlanId` (in order to know if it should apply the selected styles to itself or not). What is more, it should have an `onClick` callback which changes the selected plan state of the `Subscriptions` component. How do we handle this?

Let's look at our options.

### Lift the state up

One way that we can approach this is to give up on the idea that the `Subscriptions` component should handle its own state. Instead, we can lift the state up one level and let the parent component manage it.

This is not a good option as it goes against our "easy to use" principle. We are forcing the developer who is using our component to do a lot of work.

Let's think of something else.

### Clone the children

In React, we can copy components and add additional props to them by [cloning them](https://reactjs.org/docs/react-api.html#cloneelement). This solution might work here. Let's see what it would look like in our `Subscriptions` component.

```js
import React, { useState, Children, cloneElement } from 'react';
import RadioGroup from './RadioGroup';

const Subscriptions = ({ onSelect, children }) => {
  const [selectedPlanId, setSelectedPlanId] = useState();
  const [billingPeriod, setBillingPeriod] = useState('MONTH');

  return (
    <div>
      <RadioGroup
        value={billingPeriod}
        onChange={(value) => {
          setBillingPeriod(value);
        }}
      />

      {Children.map(children, (child) =>
        child.type === SubscriptionPlan
          ? cloneElement(child, {
              selectedPlanId: selectedPlanId,
              billingPeriod,
              onSelectPlan: (id) => {
                setSelectedPlanId(id);
              },
            })
          : child
      )}

      <button
        disabled={!selectedPlanId}
        onClick={() => onSelect({ id: selectedPlanId, billingPeriod })}
      >
        Select
      </button>
    </div>
  );
};

export default Subscriptions;
```

Not too bad! But let's think for a second. We only want to pass the additional props to `SubscriptionPlan`, never to other children that the component might have. We already check for this in the code above. But are we absolutely certain that `SubscriptionPlan` will always be a direct child of `Subscriptions`?

What happens if there is another component wrapped around `SubscriptionPlan`? To ensure our code works in that situation, we would have to recursively clone all children, check if they are of type `SubscriptionPlan` and if so, apply the additional props to them. It is certainly possible to do this but it would add so much complexity. It seems we hit a limitation with this approach.

Is there an alternative?

### Render prop

React's [render prop](https://reactjs.org/docs/render-props.html) pattern is another way to approach this. It will require a small change in the way we use the component though. Instead of adding the children directly, we need to pass a function:

```js
const SubscriptionsPage = () => (
  <Subscriptions
    onSelect={(selectedPlan) => {
      // Do something with this data
    }}
  >
    {(addedProps) => (
      <>
        <SubscriptionPlan {...subscriptionPlans} {...addedProps} />
        <SubscriptionPlan {...subscriptionPlans} {...addedProps} />
        <SubscriptionPlan {...subscriptionPlans} {...addedProps} />
      </>
    )}
  </Subscriptions>
);
```

We now have to manually pass the extra props to `SubscriptionPlan` every time we use `Subscriptions`. Not great.

Let's also take a look at the `Subscriptions` component :

```js
import React, { useState } from 'react';
import RadioGroup from './RadioGroup';

const Subscriptions = ({ onSelect, children }) => {
  const [selectedPlanId, setSelectedPlanId] = useState();
  const [billingPeriod, setBillingPeriod] = useState('MONTH');

  return (
    <div>
      <RadioGroup
        value={billingPeriod}
        onChange={(value) => {
          setBillingPeriod(value);
        }}
      />

      {children({
        selectedPlanId: selectedPlanId,
        billingPeriod,
        onSelectPlan: (id) => {
          setSelectedPlanId(id);
        },
      })}

      <button
        disabled={!selectedPlanId}
        onClick={() => onSelect({ id: selectedPlanId, billingPeriod })}
      >
        Select
      </button>
    </div>
  );
};

export default Subscriptions;
```

The render prop pattern is useful. We managed to avoid the limitations of the cloning solution. But I still don't like that we are forces to manually pass props.

Is there a way around this?

### Context

Let's leverage [React's Context API](https://reactjs.org/docs/context.html). We can create a context that is accessible for all children of `Subscriptions`. Then, we can access this context in `SubscriptionPlan` and voilà!

`Subscriptions` now looks like this:

```js
import React, { useState, createContext, useContext } from 'react';

import SubscriptionPlan from './SubscriptionPlan';
import RadioGroup from './RadioGroup';

const SubscriptionsContext = createContext({});

export const useSubscritionsContext = () => useContext(SubscriptionsContext);

const Subscriptions = ({ onSelect, children }) => {
  const [selectedPlanId, setSelectedPlanId] = useState();
  const [billingPeriod, setBillingPeriod] = useState('MONTH');

  return (
    <div>
      <RadioGroup
        value={billingPeriod}
        onChange={(value) => {
          setBillingPeriod(value);
        }}
      />
      <SubscriptionsContext.Provider
        value={{
          selectedPlanId: selectedPlanId,
          billingPeriod,
          onSelectPlan: (id) => {
            setSelectedPlanId(id);
          },
        }}
      >
        {children}
      </SubscriptionsContext.Provider>
      <button
        disabled={!selectedPlanId}
        onClick={() => onSelect({ id: selectedPlanId, billingPeriod })}
      >
        Select
      </button>
    </div>
  );
};

export { useSubscritionsContext };

export default Subscriptions;
```

We also need to edit `SubscriptionPlan` so that it uses the context we just created:

```js
import React from 'react';

import { useSubscritionsContext } from '../';

const SubscriptionPlan = ({ id, annualPrice, monthlyPrice, name }) => {
  const { selectedPlanId, onSelectPlan, billingPeriod } =
    useSubscritionsContext();

  const isSelected = selectedPlanId === id;
  const price = billingPeriod === 'MONTH' ? monthlyPrice : annualPrice;

  return (
    <div onClick={() => onSelectPlan(id)}>
      <div>
        <h2>{name}</h2>
        <h2>$ {price}</h2>
      </div>
    </div>
  );
};

export default SubscriptionPlan;
```

Using context slightly complicates the implementation of both of `Subscriptions` and `SubscriptionPlan` components. But note, we are impacted by this complication once - when we create these components. On the flip side, we reap the benefits of a simple to use component every time we reuse `Subscriptions`.

Finally, we now have the component we set out to create in the beginning! 🍾

Check out this [repo](https://github.com/IvaKop/subscriptions-component) if you want to play around with the code.

## Conclusion

Phew, that was a lot! 😅

So what is the takeaway? Should we just use context for everything?

Absolutely not! All of the approaches and patterns we discussed above and decided against for our particular use case are extremely useful in other contexts (no pun intended). The list above is also far from exhaustive, it includes only what I subjectively considered to be the most relevant solutions.

What I am really trying to convey is a mental model, an algorithm, for approaching the development of React components. What it comes down to is being aware of the different options to solve a problem, understanding the trade-offs between them and, ultimately, going with the solution that fits your goal the best.

In this case, the goal was maximum usability and flexibility. Depending on the project, the team, the stack, the speed of development, and many, many other factors, there might be different goals. As a consequence, the solutions we choose under different circumstances might also differ, even if the component itself remains unchanged.

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


Learn how to build flexible compound React components with this comprehensive guide.

A guide to building flexible compound React components


import { getArticles } from '../scripts/util';
import ArticleLayout from '../components/ArticleLayout';

I went from knowing nothing about coding to becoming a full-time web developer in 8 months. No bootcamps, no university degree. Here’s my advice to you!

## **Where to start**

Becoming a web developer sounds really cool. And, for the most part, it is. It is a challenging and rewarding career where problem solving and creative thinking become part of our daily routine.

However, being a good developer requires a lot patience and focus. It means having the ability to think deeply and dive into technical topics and documentation for hours at a time. Programming is also very difficult, especially in the beginning, when everything seems new and incomprehensible.

So before spending tons of time (and possibly money) on courses, bootcamps and/or a university degree, test the waters. Make sure coding is something you enjoy. There are many easy ways to do this given the abundance of coding resources online. Here’s what I recommend.

Go to [freeCodeCamp](https://www.freecodecamp.org/) - the most awesome (and completely free) web development educational resource. If you, like me, enjoy it when things show up on a webpage, get started with Responsive Web Design. Otherwise, I suggest jumping straight into JavaScript Algorithms and Data Structures. This will give you a feeling of what coding feels like right away. In fact, freeCodeCamp’s curriculum is so comprehensive that it might be all you need to get hired as a junior dev. It worked for me! 🙂

If you feel you need additional resources or prefer a different approach, go for it! At least now you know what you are getting into.

## **Build real projects**

Once you have a surface level understanding of JavaScript, start building projects right away. What I mean by that is not following step by step tutorials. Build your very own software solution by starting from scratch and working through the problems you encounter yourself. Obviously, you want to Google and dig into StackOverflow when you don’t know something.Тhis is what software development is like in the real world as well. Just avoid copy-pasting entire implementations. Initially, your solutions will be terrible. The goal at this stage is to make it work. Later on, through experience and feedback, it gets better.

In the interest of full disclosure, I will share one of the first projects I build with React - [Conway’s game of life](https://codepen.io/IvaKop/pen/KqXOPR). The code is truly awful, I could barely resist fixing it up before posting it. 🙈 Also, if you are wondering why the link is from Codepen, it’s because I had no idea how to setup my own development environment yet. But the point is, it works! It would have been so easy to copy (or, get inspired by) someone else’s solution. But wrestling with the problem by myself (and managing to very imperfectly solve it at the end) made me realise what is so satisfying about software development in the first place - the rush you get when your program finally works! This is a powerful motivator. It is what keeps me coding today still.

So build several small projects and put them all together in a portfolio. If you want some ideas about what to create, check out freeCodeCamp’s [Front End Libraries Projects](https://www.freecodecamp.org/learn/front-end-libraries/front-end-libraries-projects/) suggestions, completed with user stories and hints. Having a portfolio with awesome projects will lend some credibility to your job application and will hopefully convince potential employers that you have mastered the basics. But this is not enough.

## **Sell your (non-tech) strengths**

Lacking any programming experience or education, it is difficult to compete in the market for junior developer jobs. There must be some way to stand out, right? The good news is, to be a good developer, you need to be able to do more than just code. Communication, time management and team work, for example, are all essential skills in this field. And guess what? These kinds of “soft skills” are transferable across jobs. Chances are, you have already mastered a bunch of them.

As an illustration, before I became a developer, I used to be a project manager. Although my previous projects had nothing to do with tech, it turned out my skills were invaluable to my first employer - a small digital agency which relied heavily on developers to manage their own work.

Figure out what is it that you can do, apart from writing great code, that can make you a valuable addition to a team. Then take those skills and highlight them in the job application process - both in your resume and during interviews. It’s a recipe for success!

Happy coding! ✨

export async function getStaticProps(context) {
  const articles = getArticles();
  const moreArticles = articles.sort(() => 0.5 - Math.random()).slice(0, 3);
  return {
    props: {
      articles,
      moreArticles,
    },
  };
}

export default ({ children, articles, moreArticles }) => {
  return (
    <ArticleLayout articles={articles} moreArticles={moreArticles}>
      {children}
    </ArticleLayout>
  );
};


I went from knowing nothing about coding to becoming a full-time web developer in 8 months. No bootcamps, no university degree. Here’s my advice to you!