DEV Community

Bad ReactJs practices to avoid

Juraj Pavlović on November 15, 2021

There are plenty of articles and blogs that contain useful information on how to do things the right way. Best practices, good design patterns, cle...

Read full post

Juraj Pavlović • Nov 15 '21

The issue with passing the prop to the initial state is that one may think the state will change if the prop does. This could make young developers confused. With that, your latter example makes much more sense. Keeping the state in a container and passing the state handlers down to the presentation component.

Thank you for your contribution.

James Thomson • Nov 16 '21

The issue with passing the prop to the initial state is that one may think the state will change if the prop does. This could make young developers confused.

I don't think that's a good enough reason. If you think this way, then you don't understand how React's lifecycle works and that's a far bigger problem - avoiding a perfectly acceptable practice (which is discussed within React's official docs) only accentuates that problem.

Juraj Pavlović • Nov 16 '21

It doesn't make a lot of sense in a way of how a React app should have its state structured. If a prop is higher up in the component tree, it shouldn’t be used as a part of the separate state within a component. What is the benefit if you do such a thing? It makes sense to use the prop to determine the state implicitly, but not to directly copy the prop in the state. This is clearly a code smell and it is discouraged by many.
Another thing, regarding the React docs, I think you misread them. The link you provided only offers an example with useState and some initialState inside, it does not state or show using props as initialState. This is what actual docs say about it: “There should be a single “source of truth” for any data that changes in a React application.” and “If something can be derived from either props or state, it probably shouldn’t be in the state.” In another words using props to generate state often leads to duplication of “source of truth”, i.e. where the real data is. Meaning this is a bad practice.

Other than that, there are plenty other articles, blogs and the React docs covering this topic which agree with the stated:
reactjs.org/docs/lifting-state-up....
stackoverflow.com/questions/400634...
medium.com/@justintulk/react-anti-...
vhudyma-blog.eu/react-antipatterns...

James Thomson • Nov 16 '21

If a prop is higher up in the component tree, it shouldn’t be used as a part of the separate state within a component.

Well of course, but you wouldn't use initialState in that use case.

It makes sense to use the prop to determine the state implicitly, but not to directly copy the prop in the state. This is clearly a code smell an it is discouraged by many.

Yes, again, if you're doing this then you don't understand the use of initialState.

Another thing, regarding the React docs, I think you misread them. The link you provided only offers an example with useState and some initialState inside, it does not state or show using props as initialState.

No, it clearly has an example of exactly this:

function Counter({initialCount}) {
  const [count, setCount] = useState(initialCount);
  return (
    <>
      Count: {count}
      <button onClick={() => setCount(initialCount)}>Reset</button>
      <button onClick={() => setCount(prevCount => prevCount - 1)}>-</button>
      <button onClick={() => setCount(prevCount => prevCount + 1)}>+</button>
    </>
  );
}

This is what actual docs say about it: “There should be a single “source of truth” for any data that changes in a React application.” and “If something can be derived from either props or state, it probably shouldn’t be in the state.”

Yes, again, then you shouldn't be using initialState in that use case. If the initialState can change then it's not and initialState, it's a reactive prop.

I'm not sure what you're trying to prove with the links provided. My comment was that initialState isn't something bad as long as you know how to use it and placing a blanket "never use initialState" only avoids properly understanding the use case.

Even within the last link you provide the author goes into detail on proper use cases and states:

In general, props should be avoided in the initial state unless you only need them to initialize the internal state of the component and either props are never updated or the component should not react to their updates.

Let's look at the example above - we pass the initialValue prop, which is used to initialize the internal state of the ChildComponent and is never changed.

This is perfectly fine, but it is an exception rather than the general rule.

The real problem occurs when the initialValue in the ParentComponent can be changed

Which exactly reiterates my point - understanding React's lifecycle and the use of initialState.

Juraj Pavlović • Nov 17 '21

Using initial state for generic components is perfectly fine. My initial point was one for outside generic components. That's why you see examples provided in the last comment. Will make an edit explaining in it in more detail.

Starver • Nov 17 '21

This was a very informative article and also this thread was a good discussions. What i get from this thread is that props can be used as initial state only when we are sure that the prop is not going to change or the component is not bothered by the change in prop.

Juraj Pavlović • Nov 17 '21

Thats what this amazing community is for. Contributing even more to a post with a discussion makes each of us learn more. The Props in Initial State heading and content have been edited to provide more details. It should be more clear now when is it good and when it isn't to use such a thing. I kindly ask you to check it out.

Christian Kozalla • Nov 20 '21

I agree that derived state from props isn't a bad practice. Then again, writing a component like that may not always be intentional, but due to lack of experience with React. It is a common beginner's mistake. I think, that's why it is considered a bad practice altogether.

Your two examples of the Counter are nice, however they do not behave the same. First one is managing its on internal state, the second Counter is only a presentational component. Image you want many independent counters on the page, so you would need more than one instance of Counter.

I've recently read "Writing Resilient Components" by Dan Abramov

However, a common mistake when learning React is to copy props into state. (Example with class component) This might seem more intuitive at first if you used classes outside of React. However, by copying a prop into state you’re ignoring all updates to it. In the rare case that this behavior is intentional, make sure to call that prop initialColor or defaultColor to clarify that changes to it are ignored.

overreacted.io/writing-resilient-c...

If initialCount prop of your first Counter would change, would the instance update/re-render or not (like in Dan's example)?

Mark Erikson • Nov 15 '21

Yeah, I covered the "Context vs Redux" question in much more detail in my post Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux).

Also, since I did that "When to Reach for Redux" podcast interview, we've added a new RTK Query data fetching and caching API to Redux Toolkit, which solves the same use case as React Query, Apollo, Urql, and SWR. I've also added a new section on how to use RTK Query to the "Redux Essentials" tutorial as well.

Juraj Pavlović • Nov 15 '21

Your articles about Redux and how Redux compares to Context are incredibly thorough and well written. I specially loved them and mentioned one of them in the resources. Thank you so much for stopping by!

Juraj Pavlović • Nov 16 '21

Now this example makes me understand your initial point more clearly. In such cases I agree with you completely. When making such generic components to be used throughout the app, it makes sense. Thank you.

Reotech • Nov 15 '21

So if we don't use index as key..please what should we use as key then?

Juraj Pavlović • Nov 15 '21 • Edited

Good question! One major thing to avoid alongside index is random keys such as uuid. A proper key should be a unique identifier from the data object you are passing. Check out the following example:

Mike Robinson • Nov 16 '21 • Edited

Instead of uuid, you could use this function that just returns an incrementing integer (guaranteed to be unique and no external dependencies):

var getNextKey = (function(n) {
  return () => ++n;
}(0));

James Thomson • Nov 16 '21

One major thing to avoid alongside index is random keys such as uuid
All you need to avoid is setting the key an each render. It's perfectly fine to use a uuid if you define it as part of the object being consumed and that uuid persists.

Juraj Pavlović • Nov 16 '21

Indeed, if the uuid is a part of the object, then of course it is fine to use it. That way it is not a random key like I've mentioned.

Reotech • Nov 15 '21

Thank you for this

Cédric Teyton • Feb 16 '23

Hi there, FYI we've added your blog post on a GitHub project gathering content about best coding practices :)
github.com/promyze/best-coding-pra...

hasn-ab • Dec 1 '21

Agreed completely.
Another case could be when we know for sure that props may not change.

Chaz Gatian • Nov 19 '21

Do you mind providing an example of what you mean by "Declaring components inside of components"?

Good article, thank you.

Juraj Pavlović • Nov 22 '21

Of course I don't mind, here is an example of it:

Keep in mind that this is a bad practice

Reotech • Nov 15 '21

True true..thank you

Alfredo Salzillo • Nov 22 '21

Declaring components inside of components
is not a bad practice is wrong

Christian Kozalla • Nov 21 '21

That statement was referring to class components, assigning the prop to state inside the constructor.

Anyways, thank you for clarifying!

tanth1993 • Nov 16 '21

I think Using props in Initial State in case we need to update data from props. ex: a input field needs defaultValue is prop then we change it and the new data in state.