💻🔍 React: Things You Might Want to Know

Heyyy everyone!

Wishing you all a Happy New Year! May it bring out the best in all of us!

With this post, I want to showcase some tips and tricks that you might not know—little things that can simplify your code and make it cleaner. So, let’s get down to business!

1. Simple useEffects Usages Can Be Super Simplified

We've all seen something like this:

import React, { useState, useEffect } from "react";

const MyComponent = ({ propValue }) => {
  const [internalValue, setInternalValue] = useState("");

  useEffect(() => {
    setInternalValue(...); // Some extra logic modifying the propValue

  }, [propValue]);

  return <div>{internalValue}</div>;
};

But all of this could be simplified by deriving the value directly from the prop. React’s props and re-rendering mechanism can handle this seamlessly, giving you much simpler and cleaner code.

Simplified Version:

import React from "react";

const MyComponent = ({ propValue }) => {
  const internalValue = // Some extra logic modifying the propValue

  return <div>{internalValue}</div>;
};

Why It's Better:

Less Boilerplate: No need for useState or useEffect.
Immediate Updates: The value updates automatically when the prop changes.
Cleaner Code: Easier to read and maintain.

---

2. State Might Not Need to Live in the Parent Component

A common sort of defaut ish pattern I've seen is allocating state to a parent component without a valid reason. If the state is only used in one child component, it’s better to move it there. This keeps the parent cleaner and improves reusability of the child component.

Non-Optimal Example: State in the Parent Component

Here, the parent holds state (name and age) that is only relevant to one child:

import React, { useState } from "react";

const Parent = () => {
  const [name, setName] = useState("");
  const [age, setAge] = useState("");

  return (
    <div>
      <h1>Parent Component</h1>
      <Child name={name} setName={setName} age={age} setAge={setAge} />
      <Sibling />
      <AnotherSibling />
    </div>
  );
};

Good Example: State in the Child Component

Here, the state is encapsulated within the Child component, ensuring only it re-renders when needed:

import React, { useState } from "react";

const Parent = () => {
  return (
    <div>
      <h1>Parent Component</h1>
      <Child />
      <Sibling />
      <AnotherSibling />
    </div>
  );
};

const Child = () => {
  const [name, setName] = useState("");
  const [age, setAge] = useState("");

  return (
    <div>
      <h2>Child Component</h2>
      <input
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
        placeholder="Enter name"
      />
      <input
        type="number"
        value={age}
        onChange={(e) => setAge(e.target.value)}
        placeholder="Enter age"
      />
    </div>
  );
};

Why It's Better:

Encapsulation: State belongs to the component that uses it.
Improved Performance: Other siblings don’t re-render unnecessarily.
Cleaner Parent Component: The parent focuses only on orchestrating its children.

---

3. On most cases, React's optimization methods might not be needed

Now this is a harsh one to touch on, but lets just say React is really really good at handling re-renders and the situations where you really need optimization mechanisms are very rare.

This isnt to say they are useless, its just that you need to keep in mind that premature optimization is a thing.. I dont really support the "if its not completely broken dont fix it" but lets just say, you need to give it a proper check before you go to those mechanism and not just go to them straight away.

Even though, realistically there are some really good articles that I believe show us that there isnt as much drawback from using them a lot (i guess except bugs they might cause due to lack of people's understanding of how they might work). But my point is, you might not need to go through them at all, and well .. save you some time too

---

4. You don't have to "hookify" everything ...

Hooks are cool, right? They give us the ability to manage state, side effects, and more in a functional way. But just because hooks are available doesn't mean you need to create one for everything. I've seen a lot of developers fall into the trap of turning simple logic into custom hooks just for the sake of it. Instead you should be thinking in the direction of what problem will it help you? will you be reusing it? will it abstract some logic away for you? And so on...

---

I think I'll end it here, I really hope this helps and that we can all learn something new :))) Please feel free to reply with any possible scenario I might have missed with these, or improvements. I'd love to hear them and learn as well.