
[Redux](https://redux.js.org/) is for many considered the industry _standard_ way to manage state in React applications. But much like using a cannon to kill a mosquito, more often than not Redux is overkill for many scenarios. From my personal experience, it's very easy for a Redux-based application to grow out of control in complexity really fast if you are not diligent in you code reviews.

I'll list here a few scenarios where Redux isn't necessary, and a few where it can be a good call.

## Local state is king

In the same way you wouldn't store all your variables inside the `window` object, you shouldn't store all your state inside a global store. A global store is for, you guessed it, _for state that should be globally available_. There's no need to save the current color of an button in said store.

## Avoiding prop drilling

If all you need is a way to avoid prop drilling, then [Context](https://reactjs.org/docs/context.html) is your friend. Since version `16.3`, React ships with this API that allows you to declare some data in a `Provider` component, and have this data available anywhere down the tree from a `useContext` hook:

### `ThemeContext.jsx`

```jsx
import { createContext } from 'react'

export const ThemeContext = createContext('light')
```

### `index.jsx`

```jsx
import { MyComponent } from './MyComponent.jsx'
import { ThemeContext } from './ThemeContext.jsx'
import { render } from 'react-dom'

render(
	<ThemeContext.Provider value="dark">
		<MyComponent />
	</ThemeContext.Provider>,
	document.getElementById('root'),
)
```

### `Component.jsx`

```jsx
import { useContext } from 'react'
import { ThemeContext } from './ThemeContext.jsx'

export const MyComponent = () => {
	const currentTheme = useContext(ThemeContext)
	return <p>This app is using the {currentTheme} theme.</p>
}
```

### Result

```html
<p>This app is using the dark theme.</p>
```

On the above example, we didn't need to pass the theme value as props, instead we recovered it directly from our Context.

## Updating data on distant components

You have two components that are distant from each other in the render tree, but still need to be able to share and update the same data for both. This problem can also be solved with Context, in combination with `useState` hooks:

### `CounterProvider.jsx`

```jsx
import { createContext, useState, useContext } from 'react'

const CounterContext = createContext({
	value: 0,
	setValue: () => {}
})

export const useCounter = () => useContext(CounterContext)

export const CounterProvider = ({ children  }) => {
	const [value, setValue] = useState(0)

	return (
		<CounterContext.Provider value={{ value, setValue }}>
			{children}
		</ThemeContext.Provider>
	)
}
```

In the example above, all components under `CounterProvider` that use `useCounter` will receive a `{ value, setValue }` object. Calling `setValue()` with a new number will update the `value` for all other components using `useCounter`.

You can also make a version with [useReducer](https://reactjs.org/docs/hooks-reference.html#usereducer) if you need more control on how the value must be updated.

## Saving the fetch result of an endpoint

It's a common pattern in Redux-heavy applications to have _all_ you application logic living inside reducers and action creators, including async operations like fetching data from a server, with the help of middleware like [redux-thunk](https://github.com/reduxjs/redux-thunk#redux-thunk).

If you see yourself repeating those patterns to have this external data available in your application, manually creating some `isLoading` and `error` states in your reducers, then a much simpler solution is to have a data fetching/caching library that was specifically built to handle this situation.

[React Query](https://react-query.tanstack.com/) and [SWR](https://swr.vercel.app/) are very popular ones, and [Apollo Client](https://www.apollographql.com/docs/react/) uses a similar logic for GraphQL endpoints.

Here's how it would look like fetching data from a REST API using React Query:

### `index.jsx`

```jsx
import { Example } from './Example.jsx'
import { QueryClient, QueryClientProvider } from 'react-query'
import { render } from 'react-dom'

const queryClient = new QueryClient()

render(
	<QueryClientProvider client={queryClient}>
		<Example />
	</QueryClientProvider>,
	document.getElementById('root'),
)
```

### `Example.jsx`

```jsx
import { useQuery } from 'react-query'

const fetchData = async () => {
	const response = await fetch('https://api.test.com/v1/endpoint')
	const data = await response.json()
	return data
}

export const Example = () => {
	const { isLoading, error, data, isFetching } = useQuery('myData', fetchData)

	if (isLoading) return 'Loading...'

	if (error) return 'An error has occurred: ' + error.message

	return (
		<div>
			<p>{data.content}</p>
			<div>{isFetching ? 'Updating...' : ''}</div>
		</div>
	)
}
```

Notice how it automatically handles first load, error and update states for you. The data is also cached, so multiple calls to `useQuery` using the same [query keys](https://react-query.tanstack.com/guides/query-keys) will make use of the local cache.

## Managing form state

If you're using any Redux tooling to manage state and validation of a form, I've got good news for you! We now have [react-hook-form](https://github.com/react-hook-form/react-hook-form#readme), and as the name suggests, it's a form library built around React Hooks, and it's very simple to use.

Here's a quick start example:

```jsx
import { useForm } from 'react-hook-form'

const MyForm = () => {
	const {
		register,
		handleSubmit,
		formState: { errors },
	} = useForm()

	const onSubmit = (data) => console.log(data)

	return (
		<form onSubmit={handleSubmit(onSubmit)}>
			<input {...register('firstName')} />
			<input {...register('lastName', { required: true })} />
			{errors.lastName && <p>Last name is required.</p>}
			<input {...register('age', { pattern: /\d+/ })} />
			{errors.age && <p>Please enter number for age.</p>}
			<input type="submit" />
		</form>
	)
}
```

Notice how all the validation is described inside `register()` calls, and you get the updated form state from the `useForm()` hook. The `data` sent to `onSubmit` will be an object with all the form data, with the input names as keys. No actions, action creators, dispatchers, reducers or selectors in sight.

## OK, when should I use Redux then?

The Redux team itself answered this question very eloquently in [their FAQ](https://redux.js.org/faq/general#when-should-i-use-redux). But to quote the most important bit:

> Redux is most useful when in cases when:
>
> - You have large amounts of application state that are needed in many places in the app
> - The app state is updated frequently
> - The logic to update that state may be complex
> - The app has a medium or large-sized codebase, and might be worked on by many people
> - You need to see how that state is being updated over time

Dan Abramov also created an [equally titled post](https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367), where here describes a few more situations where Redux shines:

> - Persist state to a local storage and then boot up from it, out of the box.
> - Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box.
> - Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers can replay them to reproduce the errors.
> - Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.
> - Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written.
> - Travel between the state history in development, and re-evaluate the current state from the action history when the code changes, a la TDD.
> - Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their apps.
> - Provide alternative UIs while reusing most of the business logic.


You Might Not Need Redux


Naming things in software development is often considered a difficult task. This is especially true when writing CSS selectors that can potentially clash with each other without warning, if you're not careful. To avoid this problem, it's common for developers to adopt a CSS _naming convention_, like [BEM](http://getbem.com/), [SMACSS](http://smacss.com/) and other letter soup acronyms.

But what if I told you _shouldn't_ have to use those conventions? That there is a way to style your web application without ever need to worry about styles being overridden ever again? In fact there are several options available to remove this burden from your developer life, and we're going to explore them here.

## Using your front end framework

Any modern front end framework like React, Angular or Vue will have an official CLI tool to help you quickly bootstrap and build a new project.

For React it's [Create React APP](https://create-react-app.dev/), and if you have created your project using this tool, you can already say good bye to CSS naming conventions by making use of [CSS Modules](https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/). In short, you can create a separate `MyComponent.module.css` and import it directly inside your `MyComponent.js` file:

### `MyComponent.module.css`

```css
.myClass {
	color: green;
}
```

### `MyComponent.js`

```jsx
import styles from './MyComponent.module.css'

export const MyComponent = () => {
	return <p className={styles.myClass}>Hello World!</p>
}
```

### Result

```html
<p class="MyComponent_myClass_by3yq">Hello World!</p>
```

Note that the resulting class name was changed from the original `myClass` name. This is CRA doing to automatically avoid class name collisions with other components. So it does not matter if in another component you create a `.myClass` class with different styling, it will never be applied to `MyComponent` since they will be changed at build time. However this will only work if you add `.module` at the end of your css filename.

And for the same purpose, Angular has [Component Styles](https://angular.io/guide/component-styles) and Vue has [Scoped CSS](https://vue-loader.vuejs.org/guide/scoped-css.html). If you're using another front end framework, check if it has a way to scope CSS styling to a single component.

## Using a CSS-in-JS library

CSS-in-JS is like what the name suggests: you write your CSS styles as JavaScript code, and a library will convert it to individual component styles at run time. Some of the more popular libraries for this are [Styled Components](https://styled-components.com/) and [Emotion](https://emotion.sh/docs/introduction).

Here's the same example as before, but now using _Styled Components_:

### `MyComponent.js`

```jsx
import styled from 'styled-components'

const Styled = styled.p`
	color: green;
`

export const MyComponent = () => {
	return <Styled>Hello World!</Styled>
}
```

### Result

```html
<p class="sc-hgKiOD DFGGm">Hello World!</p>
```

Notice that you didn't need to write a CSS class at all, and instead the styling was written as part of the JS code. The `styled.p` in this case is a [Tagged template](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates), a special function that you can call by passing a template literal.

There's also popular frameworks that bundle CSS-in-JS solutions themselves, like [Next.js](https://nextjs.org/docs/basic-features/built-in-css-support#css-in-js) with `<style jsx>` support, or [Chakra UI](https://chakra-ui.com/docs/features/style-props) providing a lot of custom styling props.

## Using an Atomic Design System

The idea behind the Atomic Design methodology is that, instead of having highly specialized CSS classes for each use case, you have a lot of generic classes that apply a single style at the time, and you compose those classes inside your component. There's no name clashes because you would not be creating new CSS classes, only using what's available in the design system.

The most popular CSS framework that uses this concept is [TailwindCSS](https://tailwindcss.com/). It gives you a lot of generic classes like `font-bold` or `text-lg`, and you add as many as necessary to your component until you're satisfied with the design. For example:

### `MyComponent.js`

```jsx
export const MyComponent = () => {
	return <p className="text-green-500">Hello World!</p>
}
```

### Result

```html
<p class="text-green-500">Hello World!</p>
```

With this approach, you can end up with a lot of classes applied to a single element, but the idea is that all this should be abstracted away in a custom component, and you reuse this component instead. I.E instead of adding `text-green-500` to every paragraph that needs it, you would reuse the `MyComponent` component, that applies the `text-green-500` class internally.

## Using Web Components with Shadow DOM

Web components are the web native way to create custom reusable elements. They have something called a _shadow DOM_, which can encapsulate styling to single component. You can learn more about web components in general [here](https://developer.mozilla.org/en-US/docs/Web/Web_Components), and about the shadow DOM [here](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM).

However even this being the native way to do style encapsulation, it's a much more involved and complex solution to do in your own. That's why I recommend using a library that already provides ready to use web components, like [Material Web](https://github.com/material-components/material-web), or something more developer friendly that compiles down to native Web Components, like [Lit](https://lit.dev/) or [Stencil](https://stenciljs.com/).


You shouldn't have to worry about CSS class names


If you have worked with any sizable JavaScript project, be a front-end React application or a back-end Node service, you are most likely aware of the importance of using ESLint and other static code analysis tools.

In this article I'll show you a less know ESLint plugin that will help keep your codebase clean, by detecting early _bugs_ and _code smells_. It's the [eslint-plugin-sonarjs](https://github.com/SonarSource/eslint-plugin-sonarjs), made by the same guys behind [SonarQube](https://www.sonarqube.org/).

## Installation

You'll need a JavaScript/Typescript project with [ESLint configured](https://github.com/eslint/eslint#installation-and-usage) in it.

On your project, install `eslint-plugin-sonarjs` as a dev dependency using `npm`:

```bash
npm install eslint-plugin-sonarjs --save-dev
```

Once installed, update your `.eslintrc` file to include the following:

```json
{
	"plugins": ["sonarjs"],
	"extends": ["plugin:sonarjs/recommended"]
}
```

## What is it checking?

You can check the [full list of rules here](https://github.com/SonarSource/eslint-plugin-sonarjs#rules). By using the `plugin:sonarjs/recommended` configuration you'll have all of them enabled, with a few exceptions.

All those rules are intended to catch code that have potential bugs or code smells, like [having too many switch case statements](https://github.com/SonarSource/eslint-plugin-sonarjs/blob/master/docs/rules/max-switch-cases.md) or [duplicated branches of code](https://github.com/SonarSource/eslint-plugin-sonarjs/blob/master/docs/rules/no-all-duplicated-branches.md).

But the most important rule of this set is the **[Cognitive Complexity](https://github.com/SonarSource/eslint-plugin-sonarjs/blob/master/docs/rules/cognitive-complexity.md)** one.

## The Cognitive Complexity Rule

It checks against actual perceived complexity in code, given it a score on how hard is for a human to understand it. It's _not_ the same as [Cyclomatic Complexity](https://eslint.org/docs/rules/complexity), which measures how many different paths a programs code can take. You can read [the full paper on Cognitive Complexity](https://www.sonarsource.com/docs/CognitiveComplexity.pdf) to learn more about it.

This rule alone can act as a guard rail to prevent a project from becoming increasingly more complex and hard to maintain over time. You can also mix in a [max-lines](https://eslint.org/docs/rules/max-lines#enforce-a-maximum-file-length-max-lines) rule to be even safer.

And since it's a ESLint rule with a configurable score, it helps reduce discussions about code quality and maintainability inside a pull request, making them more focused around the problem the PR is trying to solve.


Hi, I'm Tiso <_/>

Latest Post

You Might Not Need Redux

Latest Project

ESLint Config TS React