Blog#148: You Might Not Need Redux⭐

The main goal of this article is to help you improve your English level. I will use Simple English to introduce to you the concepts related to software development. In terms of IT knowledge, it might have been explained better and more clearly on the internet, but remember that the main target of this article is still to LEARN ENGLISH.

---

Hi, I'm Tuan, a Full-stack Web Developer from Tokyo 😊. Follow my blog to not miss out on useful and interesting articles in the future.

Many people decide to use Redux before they actually need it, worrying that their app won't work properly if they don't. Later, developers regret this decision because Redux makes their code more complicated and they have to edit multiple files to make even small changes.

People are blaming different things, like Redux, React, functional programming, and immutability, for their problems. I understand why they are doing this. It is normal to compare Redux to an approach that doesn't need extra code to change the state, and then decide that Redux is too complicated. In some ways it is, and that is intentional.

Redux offers a tradeoff. It asks you to:

• Describe application state as plain objects and arrays.
• Describe changes in the system as plain objects.
• Describe the logic for handling changes as pure functions.

You do not have to use any of these restrictions when creating an app, whether it uses React or not. These are very strict rules and you should think carefully before using any of them in your app.

Do you have good reasons for doing so?

These limitations are appealing to me because they help build apps that:

1. Save the state of the application on the user's device and start up the application with that saved state.
2. Pre-fill the state on the server, send it to the user's device in HTML, and start up the application with that pre-filled state.
3. Record the user's actions and save them with a snapshot of the state, so that the product developers can replay them to find and fix errors.
4. Send action objects over the internet to create collaborative environments without making major changes to the code.
5. Keep a record of changes or make changes without making major changes to the code.
6. Go back and forth between the state history while developing, and test the current state from the action history when the code changes.
7. Give the product developers full control and inspection capabilities so they can create custom tools for their applications.
8. Create alternative user interfaces while reusing most of the business logic.

If you are developing a terminal that can be extended, a JavaScript debugger, or a web application, it could be worth trying out or at least thinking about some of the concepts (they are not new!).

If you are new to React, do not choose Redux as your first option.

Try to think in React first, and only use Redux if you really need it or if you want to try something new. Be careful when using Redux, just like you would with any other tool that has strong opinions.

If you feel like you have to do things a certain way because of Redux, it might mean that you or the people you are working with are taking it too seriously. Redux is just one of the tools you can use, and it shouldn't be taken too seriously.

Finally, remember that you can use some of the concepts from Redux in your code without actually using Redux. For example, you can use local state in a React component:

import { useState } from "react";

const Counter = () => {
  const [value, setValue] = useState(0);

  const increment = () => {
    setValue((prevState) => prevState + 1);
  };

  const decrement = () => {
    setValue((prevState) => prevState - 1);
  };

  return (
    <div>
      Counter:
      {value}
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
    </div>
  );
};

export default Counter;

It is okay the way it is. You should really remember this.

Local state is fine.

Redux offers a tradeoff where we can separate the details of what happened from how the state changes, but it is not always the best choice. It is a tradeoff that we must consider when deciding how to structure our code. For example, we can move the logic of how the state changes out of our component and into a reducer:

import { useReducer } from "react";

const counter = (state = { value: 0 }, action) => {
  switch (action.type) {
    case "INCREMENT":
      return { value: state.value + 1 };
    case "DECREMENT":
      return { value: state.value - 1 };
    default:
      return state;
  }
};

const CounterReducer = () => {
  const [state, dispatch] = useReducer(counter, { value: 0 });

  const increment = () => {
    dispatch({ type: "INCREMENT" });
  };

  const decrement = () => {
    dispatch({ type: "DECREMENT" });
  };

  return (
    <div>
      CounterReducer:
      {state.value}
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
    </div>
  );
};

export default CounterReducer;

We were able to use Redux without having to download it first (npm install...). Amazing!

You should not do this to your stateful components unless you have a good reason to do so. You need to have a plan to make it worth it. Having a plan is the 🔑 to success.

Redux is a set of tools that help you combine different pieces of data into one global store. You can choose how much or how little of Redux you want to use.

If you give something away, make sure you get something back in exchange.

And Finally

As always, I hope you enjoyed this article and learned something new. Thank you and see you in the next articles!

If you liked this article, please give me a like and subscribe to support me. Thank you. 😊

---

The main goal of this article is to help you improve your English level. I will use Simple English to introduce to you the concepts related to software development. In terms of IT knowledge, it might have been explained better and more clearly on the internet, but remember that the main target of this article is still to LEARN ENGLISH.