
export const image = 'assets/with-router.webp';
export const title =
  'How to use withRouter HOC in React Router v6 with Typescript';
export const slug =
  'how-to-use-withrouter-hoc-in-react-router-v6-with-typescript';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="Complete guide on how to re-create and use withRouter HOC in React Router v6 with Typescipt"
  image={image}
/>
<ArticleImage src={image} alt="Using withRouter HOC in React Router v6" />

# How to use withRouter HOC in React Router v6 with Typescript

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.

<CTA title={title} slug={slug} />

## 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 = <T extends WithRouterProps>(
  Component: React.ComponentType<T>
) => {
  return (props: Omit<T, keyof WithRouterProps>) => {
    const location = useLocation();
    const params = useParams();
    const navigate = useNavigate();

    return (
      <Component
        {...(props as T)}
        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 [here](https://reactrouter.com/docs/en/v6/upgrading/v5).
Happy coding! ✨


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


export const image = 'assets/dead-code.webp';
export const title = 'How to detect dead code in a front-end project';
export const slug = 'how-to-detect-dead-code-in-a-front-end-project';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="Explore different approaches to detect dead code in your frontend project with EsLint, Webpack and Typescript"
  image={image}
  canonicalUrl="https://blog.logrocket.com/how-detect-dead-code-frontend-project/"
/>
<ArticleImage src={image} alt="Detect dead code on the frontend" />

# How to detect dead code in a front-end project

Having large amounts of dead code in a project can be detrimental to your app for many reasons. Dead code makes the codebase substantially harder to maintain at scale. It also has the potential to create confusion within the development team as to which pieces of code are relevant and actively worked on and which ones can be safely ignored.

The best way to avoid these pitfalls is to ensure we have the appropriate tooling in place to allow us to detect dead code both reliably and automatically.

In this article, we’ll cover three ways to detect dead code in your frontend project.

## Using ESLint to detect and remove dead code

[ESLint](https://eslint.org/) is perhaps the most widely used JavaScript linter, with nearly 25 million weekly downloads on npm. It is — or at least should be — an integral part of every JavaScript project. Among [many other useful things](https://blog.logrocket.com/using-prettier-eslint-automate-formatting-fixing-javascript/), ESLint allows us to detect unused variables in our files with its aptly named `no-unused-vars` [rule](https://eslint.org/docs/rules/no-unused-vars).

This rule protects us from introducing dead code in two ways. First, it will tell us if we have declared a variable that is not used elsewhere in the file:

```js
// Variable is defined but never used
let x;

// Write-only variables are not considered as used.
let y = 10;
y = 5;

// A read for a modification of itself is not considered as used.
let z = 0;
z = z + 1;
```

Second, it will tell us if there are unused arguments in our functions:

```js
// By default, unused arguments cause warnings.
(function (foo) {
  return 5;
})();

// Unused recursive functions also cause warnings.
function fact(n) {
  if (n < 2) return 1;
  return n * fact(n - 1);
}

// When a function definition destructures an array, unused entries from the array also cause warnings.
function getY([x, y]) {
  return y;
}
```

To enable the rule, you can simply add it to the `rules` object in your ESLint configuration file. The `"extends": "eslint:recommended"` property in the same file also enables the rule. Find more information on ESLint rules and how to configure them [here](https://eslint.org/docs/rules/). Most of the behavior described above is configurable and can be tweaked to fit specific project needs.

The `no-unused-vars` ESLint rule is an excellent tool for dead code detection. Its usage is strongly recommended both for local development and as part of a continuous integration pipeline.

But on its own, this rule is not enough to ensure we detect all dead code in our project. How come?

The vast majority of modern frontend projects use [ECMAScript](https://blog.logrocket.com/how-to-use-ecmascript-modules-with-node-js/) modules to organize and reuse code via imports and exports. This means that even if a variable or function is not used within the file, as long as it is exported, it is no longer considered unused.

```js
// Variable is defined but never used
const x = 10;

// The no-unused-vars rule is not broken
export const y = 20;
```

We seem to have hit the limit of this ESLint rule. So, how can we know all exported code is imported and used elsewhere in our project and, therefore, not dead?

We can continue using our linter and take advantage of a plugin called `eslint-plugin-import` and, more specifically, its [rule](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-unused-modules.md) `no-unused-modules`, which allows us to detect both modules without exports, as well as exports that are not imported in other modules.

To set it up, simply install it:

```
npm install eslint-plugin-import --save-dev
```

Then, add the plugin and the rule to the ESLint configuration file:

```js
 "plugins: {
      ...otherPlugins,
      'import',
    },
    "rules: {
      ...otherRules,
      "import/no-unused-modules": [1, {"unusedExports": true}]
    }
```

While the plugin is excellent and actively supported, there still might be good reasons to use another approach. For example, what if our project is not using ESLint at all? Perhaps we want to detect unused imports and exports only in our CI pipeline to make our linter lighter for speedier local development, and we don’t want to support different configurations for both environments. Or maybe we ran into some of the [open issues](https://github.com/import-js/eslint-plugin-import/issues?q=is%3Aissue+is%3Aopen+no-unused-modules) with this setup.

Whatever the case may be, there is an alternative solution: webpack

## Using webpack for dead code detection

[Webpack](https://webpack.js.org/) is a module bundler that is widely used in modern web apps. Its main purpose is to [bundle JavaScript files for usage in a browser.](https://blog.logrocket.com/guide-performance-optimization-webpack/) Essentially, webpack is used to create a dependency graph of your application and combine every module of your project into a bundle. This makes the tool perfectly positioned to detect unused imports and exports, i.e., dead code.

<CTA slug={slug} title={title} />

While webpack will automatically attempt to [remove unused code in the bundle it produces](https://blog.logrocket.com/tree-shaking-json-files-webpack/) (learn more about tree-shaking [here](https://webpack.js.org/guides/tree-shaking/)), there is a handy [plugin](https://www.npmjs.com/package/webpack-deadcode-plugin) to help us detect unused files and exports in our code in the process of writing it — webpack-deadcode-plugin.

To add the plugin to your project, first install it:

```
npm install webpack-deadcode-plugin --save-dev
```

Now add it to your webpack configuration file, like so:

```js
const DeadCodePlugin = require('webpack-deadcode-plugin');

    const webpackConfig = {
      ...
      optimization: {
        usedExports: true,
      },
      plugins: [
        new DeadCodePlugin({
          patterns: [
            'src/**/*.(js|jsx|css)',
          ],
          exclude: [
            '**/*.(stories|spec).(js|jsx)',
          ],
        })
      ]
    }
```

The plugin will then automatically report unused files and unused exports into your terminal. It’s a useful tool that can enhance the development process and ensure we are not introducing dead code in a project.

But it has its limitations.

First, the tool’s output in the terminal can get lost or be difficult to parse, depending on other outputs shown in the same place. This can make it inconvenient to use.

Second, it might be slightly more difficult to include it in your CI pipeline. The reason is that, according to the [documentation](https://www.npmjs.com/package/webpack-deadcode-plugin):

> The plugin will report unused files and unused exports into your terminal but those are not part of your webpack build process, therefore, it will not fail your build

There is a possibility to opt out of this behaviour, though, by enabling the `failOnHint` [setting](https://github.com/MQuy/webpack-deadcode-plugin#optionsfailonhint-default-false).

Finally, and perhaps most importantly, the plugin’s output might be incorrect when using it in a TypeScript project.

Lucky for us, TypeScript itself can be used for dead code detection!

## Using TypeScript to detect dead code

Using TypeScript in our project has a number of advantages. One of them is that it provides us with an easy way to detect dead code.

First, we can configure TypeScript in a way that doesn’t allow for unused [local variables](https://www.typescriptlang.org/tsconfig#noUnusedLocals) and [function parameters](https://www.typescriptlang.org/tsconfig#noUnusedParameters). This is similar to the `no-unused-vars` ESLint rule above. To enforce these rules via TypeScript, we can add them to our `tsconfig` file:

```js
{
  "compilerOptions": {
    ...otherOptions
    "noUnusedLocals": true,
    "noUnusedParameters": true
  }
}
```

But, even with these checks in place, we still face the issue of unused exports. Let’s use [ts-prune](https://www.npmjs.com/package/ts-prune) for the job. It is easy to use and requires very little (if any) configuration.

To use it, we need to install it:

```
npm install ts-prune --save-dev
```

Then, add a script for it to our `package.json` file:

```json
{
  "scripts": {
    "find-deadcode": "ts-prune"
  }
}
```

Now, every time we run `npm run find-deadcode` in our project, we will have a list of all unused exports.

Note that the script above will detect unused exports, even if they are used internally within the module. To opt out of this behavior, modify your script to exclude these:

```
"find-deadcode": "ts-prune | grep -v '(used in module)'"
```

Finally, if you want to use `ts-prune` in CI, you will need to change the exit code so that an error occurs when there are unused exports. Here’s the final modification:

```
"find-deadcode": "ts-prune | (! grep -v 'used in module')"
```

Of the presented options, TypeScript can arguably enforce dead code detection in the strictest way. So, if you are working on a TypeScript project, using Typescript-specific tooling — including the compile options in `tsconfig` , `@typescript-eslint/eslint-plugin` (to combine with ESLint) and `ts-prune` — is often going to be the optimal approach.

## Bonus: detect unused dependencies with depcheck

While we’re on the subject of dead code detection, let’s briefly discuss how to ensure we don’t have unused dependencies in our project. Let’s use d[epcheck](https://www.npmjs.com/package/depcheck), a tool for analyzing the dependencies in a project. It can tell us:

- How each dependency is used
- Which dependencies are useless
- Which dependencies are missing from `package.json`

Install it with:

```
npm install -g depcheck
```

Next, run the check.

```
npx depcheck
```

Depcheck uses a `special` component that allows us to recognize dependencies used outside of the regular import/export flow. These include dependencies used in configuration files, npm commands, scripts, and more.

## Conclusion

In this article, we explored different approaches to detect dead code in your frontend project. These approaches can be used both interchangeably and in combination with one another. As is often the case, choosing our ideal setup depends heavily on the particular use case.

It’s also important to note that these are not the only existing dead code detection tools. They were selected based on the prevalence and popularity of the underlying tools (ESLint, webpack, and TypeScript). But, depending on the particularities of the project, the optimal solution might not be on this list.

Happy coding! ✨


Explore different approaches to detect dead code in your frontend project with EsLint, Webpack and Typescript

How to detect dead code in a front-end project


export const image = 'assets/states-react.webp';
export const title =
  'Good practices for loading, error, and empty states in React';
export const slug =
  'good-practices-for-loading-error-and-empty-states-in-react';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="Here, we cover the best practices to use in client-side rendered React apps when handling loading, error, and empty state"
  image={image}
  canonicalUrl="https://blog.logrocket.com/ui-design-best-practices-loading-error-empty-state-react/"
/>

<ArticleImage src={image} alt="Robust React App Setup" />

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

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.

<CTA title={title} slug={slug} />

## 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! ✨


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


export const image = 'assets/robust-app.webp';
export const title =
  'Build a robust React app with Husky pre-commit hooks and GitHub Actions';
export const slug =
  'build-a-robust-react-app-with-husky-pre-commit-hooks-and-github-actions';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="Building robust React projects may seem complex at first, but this guide will explain how you can do so with Husky hooks and GitHub Actions"
  image={image}
  canonicalUrl="https://blog.logrocket.com/build-robust-react-app-with-husky-pre-commit-hooks-and-github-actions/"
/>

<ArticleImage src={image} alt="Robust React App Setup" />

# Build a robust React app with Husky pre-commit hooks and GitHub Actions

It can be incredibly challenging to build complex React projects from the ground up. They require both upfront knowledge and a deep understanding of an entire ecosystem.

In this already complex environment, a robust setup for your React app is crucial for its success because it can instantly improve the developer experience and free your team to focus on what truly matters — building an amazing product.

Curious how to go about building a robust React app? Let’s dive in.

## Building the foundation with TypeScript, React Testing Library, ESLint, and Prettier

The first step toward creating a robust setup for our React app is simple. All we need is four main ingredients:

- [TypeScript](https://www.typescriptlang.org/): a powerful tool to take advantage of static types in your React app. Use TypeScript to create documentation, refactoring, and debugging infinitely easier for your team
- [React Testing Library](https://testing-library.com/docs/react-testing-library/intro/): ensures developers have the setup they need to write basic unit tests. Healthy test coverage helps develop, refactor, and deploy apps with confidence
- [ESLint](https://eslint.org/): a reliable and highly customizable linter is a must for a robust project setup
- [Prettier](https://prettier.io/): ensures your team uses consistent code formatting

Let’s set them up!

### Starting with Create React App

To begin with, let’s create a React app with the following command:

```console
npx create-react-app react-app-setup --template typescript
```

Because we used the TypeScript template, we already have TypeScript in place. Let’s also add the following script to `package.json` to make type checking a bit easier:

```console
"typescript": "tsc --project tsconfig.json --noEmit"
```

In addition, [Create React App](https://create-react-app.dev/) gave us a very basic setup for React Testing Library, a test script in `package.json`, and a passing test to work with.

This is a nice start, but there is more to do.

<blockquote>
  Note: If you are unable to use Create React App for the initial project setup
  or prefer a different toolchain, you might need to setup TypeScript and React
  Testing Library manually.
</blockquote>

### Installing ESLint for linting

To set up our linter, we first need to install it:

```
npm install eslint --save-dev
```

Then initialize it with the following command:

```
npm run eslint --init
```

Following the prompts, our final output should resemble the screenshot below:

![](https://paper-attachments.dropbox.com/s_853C69E868FEC2A3131F37A2E709F832AF8FA3AC7F390FF6287DBB38F58B2140_1630938817824_image.png)

In the end, we should have a `.eslintrc.json` file at the root of our projects similar to this:

```json
{
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaFeatures": {
      "jsx": true
    },
    "ecmaVersion": 12,
    "sourceType": "module"
  },
  "plugins": ["react", "@typescript-eslint"],
  "rules": {}
}
```

We can additionally configure the linter settings according to our needs. Let’s also add a lint script to `package.json`:

```
"lint": "eslint src --color"
```

### Formatting with Prettier

Finally, we need to install Prettier:

```
npm install prettier --save-dev
```

And create a basic config file, `.prettierrc.json`, at the root of the project. The settings in this file depend entirely on your project’s needs and requirements.

```json
{
  "printWidth": 80,
  "trailingComma": "all",
  "tabWidth": 4,
  "semi": false,
  "singleQuote": true,
  "arrowParens": "avoid"
}
```

Let’s also add a script to `package.json` that will check if our code is formatted correctly:

```json
"prettier": "prettier src -check"
```

<CTA title={title} slug={slug} />

## Adding a pre-commit hook with Husky and lint-staged

We now have some excellent tooling in place but no easy way to take advantage of it automatically. One great way to improve our setup further is to add a `pre-commit` hook to our project that will trigger certain checks to be performed by our tooling.

In our hook, we will check for linter errors and warnings, type errors, failing tests, and it will also automatically format our code. This probably sounds like a lot for a pre-commit hook — that’s because it is! To make the process more efficient, these checks will not be performed for the entire project, only for the staged files we are about to commit.

First, we need to install [Husky](https://typicode.github.io/husky/#) and [lint-staged](https://github.com/okonet/lint-staged):

```
npm install husky lint-staged --save-dev
```

To ensure we can only check the types of staged files, we should also install [tsc-files](https://github.com/gustavopch/tsc-files):

    npm install tsc-files --save-dev

Let’s also add our lint-staged config, defining the necessary checks to `lint-staged.js` at the root of our projects:

```js
module.exports = {
  '*.{js,jsx,ts,tsx}': [
    'eslint --max-warnings=0',
    'react-scripts test --bail --watchAll=false --findRelatedTests --passWithNoTests',
    () => 'tsc-files --noEmit',
  ],
  '*.{js,jsx,ts,tsx,json,css,js}': ['prettier --write'],
};
```

Next, add a script for it in `package.json`:

```
"lint-staged": "lint-staged --config lint-staged.js",
```

<blockquote>
  {' '}
  Note: Depending on the project we are working on, even with `lint-staged` in place,
  performing all four checks on every commit might become too heavy and create a
  hurdle for developers to commit early and often. If this turns out to be the case,
  it’s good practice to reduce the load in the pre-commit hook in favor of performing
  the same checks in CI (see below).
</blockquote>

To set up the pre-commit hook, create a script in `package.json`:

```json
"husky-install": "husky install"
```

And run it with:

```console
npm run husky-install
```

Then create your hook with the following command:

```console
npx husky add .husky/pre-commit "npm run lint-staged"
```

The following file will be automatically generated in the `.husky` folder at the root of the project:

```
#!/bin/sh
    . "$(dirname "$0")/_/husky.sh"
    npm run lint-staged
```

From now on, the checks defined in the `lint-staged` config will run on every commit. We’ve successfully automated our tooling and freed ourselves from having to worry about it when we make new commits.

But wait, we are currently performing checks only on staged files. What about taking the entire project into account? With these partial checks, how can we even be certain that our app builds successfully and that it is truly ready to be deployed?

## Continuous integration (CI) workflow with GitHub Actions

As seen above, there are limitations to the local checks we can perform via pre-commit hooks. To take full advantage of our tooling, we need to set up comprehensive checks that will run for the entire project and notify us and our team when there is a problem. How?

Let’s set up a continuous integration workflow with [GitHub Actions](https://github.com/features/actions).

First, we need to create a GitHub repo and push our project into it:

```console
git remote add origin git@github.com:[your-username]/react-app-setup.git
git branch -M master
git push -u origin master
```

Then, to set up our CI workflow, we go to **GitHub Actions**, click **New workflow**, then choose **Set up a workflow yourself**. Finally, we need to add the following to our `main.yml` file.

```yml
name: React App CI
    # Controls when the action will run.
    on:
        # Triggers the workflow on push or pull request events but only for the master branch
        push:
            branches: [master]
        pull_request:
            branches: [master]
    # A workflow run is made up of one or more jobs that can run sequentially or in parallel
    jobs:
        react-app-workflow:
            # The type of runner that the job will run on
            runs-on: ubuntu-latest
            # Steps represent a sequence of tasks that will be executed as part of the job
            steps:
                - uses: actions/checkout@v2
                - name: Use Node.js 14.x
                  uses: actions/setup-node@v2
                  with:
                      node-version: 14.x
                - name: npm ci
                  run: npm ci
                - name: test
                  run: npm test
                - name: format
                  run: npm run prettier
                - name: lint
                  run: npm run lint
                - name: typescript
                  run: npm run typescript
                - name: build
                  run: npm run build --if-present
```

Click `Start commit`, fill in the form, and commit the new workflow to see it in action. Let’s break down the configuration.

First, we define when the workflow should be triggered. In our case, this will happen on `push` and `pull_request` for the master branch.

Then we define our runner, `ubuntu-latest`. Finally, we describe the steps that need to be completed for the workflow run to be successful.

As you can see, we are performing the same checks as in our pre-commit hook — lint, test, format, and type-checks — but this time, we are not limited to only the staged files.

In addition, we test if our project dependencies install correctly at the beginning of the workflow and if the build is successful.

This workflow can be very different and will likely be much more complicated in a real-world React project. It will probably include at the very least multiple environments, different integrations, e2e tests, and a deploy step — the CD part of CI/CD. You can also achieve similar results with a number of other CI/CD tooling. The above is simply a basic illustration to highlight the power of CI checks and their ability to make our lives easier through automation.

## Conclusion

Two basic elements together form a robust project setup: suitable tooling and sensible automation. The example above focused on a React app to showcase one possible approach toward creating a robust setup.

Many of the same principles, tools, and concepts apply to a much wider array of software projects.

Additionally, keep in mind that the setup above is highly simplified. It is meant to serve as an illustration rather than a definitive guide and cannot replace thinking critically about the ideal setup for your project and your team.

Curious to play with the code yourself? Find a working example in [this repo](https://github.com/IvaKop/react-app-setup).

Happy coding! ✨

Image by [katemangostar](https://www.freepik.com/katemangostar)


Building robust React projects may seem complex at first, but this guide will explain how you can do so with Husky hooks and GitHub Actions

Build a robust React app with Husky pre-commit hooks and GitHub Actions


export const image = 'assets/list.webp';
export const title =
  'Create a List component with keyboard navigation in React';
export const slug = 'create-a-list-component-with-keyboard-navigation-in-react';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="Take advantage of useEffect, useReducer and useKeyPress custom hook to build a keyboard-friendly React component"
  image={image}
/>
<ArticleImage src={image} alt="Keyboard accessible React component" />

# Create a List component with keyboard navigation in React

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`._

<CTA title={title} slug={slug} />

## 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! ✨


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


export const image = 'assets/library.webp';
export const title = 'Choosing when to build a custom React component library';
export const slug = 'choosing-when-to-build-a-custom-react-component-library';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="Learn how to decide if building a custom React component library is worth it"
  image={image}
  canonicalUrl="https://blog.logrocket.com/choosing-when-to-build-a-custom-react-component-library/"
/>
<ArticleImage src={image} alt="React component libraries" />

# Choosing when to build a custom React component library

React component libraries are becoming increasingly popular, and for good reason. They are great tools that guarantee consistency and reusability of UI elements both within and across digital products, all while having the potential to significantly reduce development time and effort.

In this tutorial, we will outline different approaches to building a custom component library. But first, I have a question for you: do you really need your own component library? Let’s talk about benefits and trade-offs of customizing one.

## Benefits of building a component library

### Consistency within code

One of the greatest benefits of using a component library is that it guarantees our components look and behave consistently throughout the app. UI inconsistencies can seriously damage user experience and become the source of frustration.

### Reusability

Components that live in a component library are by definition reusable. This is true both within and between web apps. If a change is needed, we change it once in the component library and it’s then reflected everywhere.

### Accessibility

It is important to ensure our web apps are as accessible as possible. With the use of a component library, a basic level of accessibility can (and should) be built directly into our components.

### Development time

A component library can become a huge time-saver. Having a repository of ready-to-use components means less time to build new features. What’s more, there is less communication overhead between designers and developers because UI behavior is pre-defined.

### Documentation

Component libraries are a great way to create useful and comprehensive documentation about UI components. For more details on this, check out my article on [self-documenting React components](https://blog.whereisthemouse.com/5-ways-to-create-a-self-documenting-react-component).

### Community

A well-built component library might be useful to others. It can be open-sourced and shared with the web dev community.

Building a custom component library sounds great, doesn’t it? But there is always a flip side.

## Trade-offs to building a custom React component library

### Resources

Building a component library requires a significant cross-functional, upfront effort involving design, product, and development teams. It is a huge undertaking that requires the appropriate level of resources and expertise to get all the benefits.

### Maintenance

Maintaining a custom component library is a continuous effort. It requires constant attention to keep it up to date. Involving an open-source community creates even more overhead.

### Setup

The use of a component library adds complexity to a project setup. Normally, in order to be reusable across projects, the component library lives separately from our apps and is installed as a dependency. That means every time there is a change, the component library needs to be re-published and all dependent apps updated.

### Customization

A component library by design puts many constraints on what is possible to do with our components. This is usually a good thing. However, there are certain cases when the need for customization is inevitable. Striking the right balance between the flexibility and simplicity of component APIs can be extremely challenging.

## To build or not to build a custom React component library?

Given the above, it seems that for most projects, building your own component library from scratch is simply not worth the time and effort. The good news is, you might not have to!

There are a multitude of ways to balance the benefits and trade-offs of creating component libraries, and the React ecosystem is here to help.

## Approaches to building a React component library

### 1. From scratch

As implied by the name, with this approach, we create everything ourselves — from UI rules and patterns to the components themselves. We use React, perhaps together with our favorite CSS-in-JS library (if you are into that kind of thing 😉), but everything else is up to us to build.

✅ **Pros:**

- Almost infinite freedom to create, build, and customize as needed
- Minimal dependence on third parties
- Full control over the source code

❌ **Cons:**

- Huge cross-functional upfront effort
- Continuous maintenance cost

Building a React component library from scratch is mainly suitable for complex and somewhat idiosyncratic digital products, spanning across multiple web apps, and with a large enough development team to be able to withstand the cost.

<CTA slug={slug} title={title} />

### 2. Introduce constraints

Building our own structure and constraints when it comes to the basic building blocks of our component library — colors, typography, spacing, shadows, etc. — is both difficult and, in most cases, unnecessary. Great solutions already exist!

What immediately comes to mind in this context is [Tailwind](https://tailwindcss.com/) [](https://tailwindcss.com/)[CSS](https://tailwindcss.com/). It allows us to build complex UIs with a limited and constrained-based set of style utilities. Tailwind is easy for developers to adopt and get familiar with and is also extremely customizable and flexible.

If we opt for a CSS-in-JS solution and [styled-components](https://styled-components.com/) in particular, another approach to introducing some useful constraints is to use [Styled](https://styled-system.com/) [S](https://styled-system.com/)[ystem](https://styled-system.com/). With it, we can structure our theme in extremely useful ways and take advantage of a number of utilities while retaining significant control when it comes to building our components.

✅ **Pros:**

- Freedom to create, build, and customize as needed
- The basic constraint-based building blocks provide structure

❌ **Cons:**

- We introduce a dependency at the very core of our component library — migrating away from it down the line might prove impossible
- Maintenance costs (while somewhat reduced) remains our responsibility

This approach is suitable for projects with UI components that require a lot of flexibility and freedom to customize. Before settling on a solution, ensure the constraints that are introduced are suitable for the project’s particular use cases and are in line with design and development requirements.

### 3. Use selected components

There are certain React components that are notoriously difficult to create from scratch. Think of a select component that needs to support features like search, multi-select, creating your own option is non-exists, keyboard control, and responsiveness.

What about a date picker with a calendar, keyboard controls, masked input, and validations that are also accessible? And how about a tooltip that is animated, customizable, and always positions itself correctly? Even widely used components like modal and tabs can be challenging to create properly from scratch.

A great way to save time and effort while creating a component library is to leverage React’s ecosystem for these more complex components. Going back to the list from above, here are some examples.

When it comes to a select component, [react-select](https://react-select.com/home) comes with all of the already mentioned features and more out of the box. For date pickers, there are also some great options, depending on the use case, including [react-date-picker](https://projects.wojtekmaj.pl/react-date-picker/), [react-datepicker](https://www.npmjs.com/package/react-datepicker), and AirBnB’s [react-dates](https://www.npmjs.com/package/react-dates).

When it comes to tooltips, [react-tippy](https://tvkhoa.github.io/testlib/) has us covered. Finally, [Reach](https://reach.tech/) [](https://reach.tech/)[UI](https://reach.tech/) is an example of a library that provides truly accessible and customizable components like modals, tabs, menus and so much more. They can all be installed separately, so choose all or only some of them to add to your project.

On the flip side, adding third-party components to your library comes with some trade-offs.

✅ **Pros:**

- Saves time and resources by taking advantage of battle-tested UIs while reducing complexity in our own codebase
- Using external components selectively minimizes the impact of the dependencies
- Maintenance cost for the component library is somewhat reduced

❌ **Cons:**

- Places significant constraints on the behavior and features of our dependent components
- Introduces a number of third-party dependencies that we have little control over
- External components are sometimes difficult to fully customize

Using this approach takes a huge load off the component library development team. Still, when deciding to integrate third-party components, you must consider the long-term impact and make sure, to the extent that it is possible, that these components correspond to the project needs.

### 4. Highly customizable third-party React component libraries

It is often the case that the time and resources we are willing to invest in a component library for our project simply does not equate to what is needed to implement the approaches above. This could be the case if the scope of our project is somewhat limited or, even with bigger projects, if the UI components we need are relatively standard.

We still want to be able to style and somewhat customize our components, but we are happy to rely on the sensible component APIs determined by an external base component library. Luckily, there are several options to choose from in the React ecosystem. While comprehensive lists of React component libraries can be found elsewhere, I consider [Chakra](https://chakra-ui.com/) [](https://chakra-ui.com/)[UI](https://chakra-ui.com/) to be a suitable choice for this approach in the vast majority of cases.

✅ **Pros:**

- Reduces significantly the time and effort needed to implement components
- Component styling is easy to customize
- Offloads most of the maintenance cost

❌ **Cons:**

- We are fully dependent on our library of choice, so migrating away from it may prove impossible
- There is a risk of project requirements diverging from what is available in the external library over time

Using an existing component library for our project is the way to go if we value development speed while being confident that future requirements will not clash with our choice.

### 5. Ready-to-use component libraries

Finally, we can build our project with a component library that is ready to use. These solutions, while being somewhat customizable, provide us with everything we need straight away, from color schemas and a theme to a comprehensive collection of components.

A prime example of this is Google’s [Material](https://material-ui.com/) [](https://material-ui.com/)[UI](https://material-ui.com/). This library is truly extensive, which makes it perfect if you want to start building your React app with minimal setup. Because of this, Material UI is, without a doubt, my tool of choice when building prototypes and proofs of concept. It is also handy during interview tasks when time is of the essence.

There are, however, significant downsides to tightly coupling a real-life project to a strongly opinionated component library. Let’s break it down.

✅ **Pros:**

- Easy and simple to get started, meaning minimal upfront effort required
- Minimal maintenance cost

❌ **Cons:**

- Customization is difficult from the start
- Most of the functionality and styles are pre-defined. This can make our UI feel generic and similar to others that use the same library
- Both designers and developers must deal with constraints and design principles that they have no control over

## Conclusion

The approach we choose when building (or not building) our custom component library is a strategic decision that will impact our React project from start to finish. Understanding the implications of this choice and being able to adequately assess benefits and trade-offs is of paramount importance. I hope the above overview helps us be better equipped for the challenge.

Happy coding! ✨

**If you found this article useful consider [sponsoring](https://blog.whereisthemouse.com/sponsor) my content!**

**[Follow me](https://twitter.com/iva_kop) on Twitter for more!**


Learn how to decide if building a custom React component library is worth it

Choosing when to build a custom React component library

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


export const image = 'assets/graphql.webp';
export const title =
  'GraphQL requests made easy with React Query and TypeScript';
export const slug =
  'graphql-requests-made-easy-with-react-query-and-typescript';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="A complete guide to creating the perfect data-fetching setup in React with GraphQL, React Query and Typescript"
  image={image}
  canonicalUrl="https://blog.logrocket.com/making-graphql-requests-easy-with-react-typescript-and-react-query/"
/>
<ArticleImage
  src={image}
  alt="GraphQL requests with React Query and TypeScript"
/>

# GraphQL requests made easy with React Query and TypeScript

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!

<CTA slug={slug} title={title} />

## 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! ✨


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


export const image = 'assets/next-image.webp';
export const title = 'Image optimization for static NextJS sites';
export const slug = 'image-optimization-for-static-nextjs-sites';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="Learn how to do image optimization in statically exported NextJS sites"
  image={image}
/>
<ArticleImage src={image} alt="Image optimization for static NextJS sites" />

# Image optimization for static NextJS sites

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',
    },
}
```

<CTA title={title} slug={slug} />

### 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! ✨


Learn how to do image optimization in statically exported NextJS sites

Image optimization for static NextJS sites


export const image = 'assets/rendering-methods.webp';
export const title =
  'Choosing the best rendering strategy for React apps - CSR, SSR or SSG';
export const slug =
  'choosing-between-client-side-rendering-server-side-rendering-and-static-site-generation-for-react-apps';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="How to choose between client-side rendering, server-side rendering and static site generation for React apps"
  image={image}
/>
<ArticleImage src={image} alt="CSR, SSR or SSG for React apps" />

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

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.

<CTA slug={slug} title={title} />

## 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! ✨


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

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


export const title =
  'What is the best way to loop over an array in JavaScript?';
export const slug = 'loop-over-arrays-in-javascript';

import CTA from '../components/CTA';
import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';

<SEO
  slug={slug}
  title={title}
  description="Learn all about the different JavaScript array methods and to use each one."
  image="assets/arrays.webp"
/>
<ArticleImage src="assets/arrays.webp" alt="JavaScript Arrays" />

# What is the best way to loop over an array in JavaScript?

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;
    }
  }
}
```

<CTA title={title} slug={slug} />

## 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! ✨


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

What is the best way to loop over an array in JavaScript?


export const image = 'assets/self-documenting-react-components.webp';
export const title = '5 ways to create a self-documenting React component';
export const slug = '5-ways-to-create-a-self-documenting-react-component';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="Use Typescript, Storybook and Jest, together with a sensible naming covention and file structure in order to create self-documenting React components"
  image={image}
/>
<ArticleImage src={image} alt="Self-documenting React component" />

# 5 ways to create a self-documenting React component

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.

<CTA slug={slug} title={title} />

## 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.

What are your favourite ways to document React components?

Happy coding! ✨


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


export const image = 'assets/tutorial-hell.webp';
export const title = "Stuck in tutorial hell? Here's how to break out";
export const slug = 'breaking-out-of-tutorial-hell';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="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"
  image={image}
/>
<ArticleImage src={image} alt="Tutorial hell" />

# Stuck in tutorial hell? Here's how to break out

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!

<CTA slug={slug} title={title} />

## 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! ✨


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.

Stuck in tutorial hell? Here's how to break out


export const image = 'assets/non-trivial.webp';
export const title = 'A guide to building flexible compound React components';
export const slug = 'a-guide-to-building-non-trivial-react-components';

import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';
import CTA from '../components/CTA';

<SEO
  slug={slug}
  title={title}
  description="Learn how to build flexible compound React components with this comprehensive guide."
  image={image}
/>
<ArticleImage src={image} alt="Non-trivial React components" />

# A guide to building flexible compound React components

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.

<CTA slug={slug} title={title} />

### 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! ✨


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

A guide to building flexible compound React components


export const title =
  'So, you want to become a web developer? Here are the lessons I learned along the way';
export const slug = 'so-you-want-to-become-a-web-developer';

import CTA from '../components/CTA';
import ArticleImage from '../components/ArticleImage';
import SEO from '../components/SEO';

<SEO
  slug={slug}
  title={title}
  description="I went from knowing nothing about coding to becoming a full-time web developer in 8 months. Here’s my advice to you!"
  image="assets/become-developer.webp"
/>
<ArticleImage
  src="assets/become-developer.webp"
  alt="Becoming a web developer?"
/>

# So, you want to become a web developer? Here are the lessons I learned along the way

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.

<CTA title={title} slug={slug} />

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! ✨


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!