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.
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)?