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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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...
Well of course, but you wouldn't use
initialState
in that use case.Yes, again, if you're doing this then you don't understand the use of
initialState
.No, it clearly has an example of exactly this:
Yes, again, then you shouldn't be using
initialState
in that use case. If theinitialState
can change then it's not andinitialState
, 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:
Which exactly reiterates my point - understanding React's lifecycle and the use of
initialState
.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.
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.
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.
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
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)?
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.
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!
So if we don't use index as key..please what should we use as key then?
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:
Instead of
uuid
, you could use this function that just returns an incrementing integer (guaranteed to be unique and no external dependencies):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.
Thank you for this
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...
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.
True true..thank you
Do you mind providing an example of what you mean by "Declaring components inside of components"?
Good article, thank you.
Of course I don't mind, here is an example of it:
Keep in mind that this is a bad practice
Agreed completely.
Another case could be when we know for sure that props may not change.
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.
That statement was referring to class components, assigning the prop to state inside the constructor.
Anyways, thank you for clarifying!