loading...

re: Thinking in hooks VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Hey, given this is for beginners try to not promote bad patterns like having a local state that is a direct clone of props and is in sync with the ...
 

Hi Aviral! I'm not promoting bad patterns:

  1. If you check the first part on this series, I said that we should avoid state in components to make them reusable and easy to maintain.
  2. If you read this article carefully, you'll notice that I said Counter is good enough without state, but this article wanted to show how you can add local state with hooks, even if Counter doesn't need it.
  3. If you, after that first article and the clarification in this one, still want to add internal state to your component, you should try to not be isolated from the external world, so if the parent tries to change something from the outside, ideally that should be reflected internally. What you end up taking home is that doing that is far more tedious than just keeping it stateless.

TL;DR: Read the closing thoughts at the end of this article.

 

Yeah I get that but that doesn't change the fact that the code example still promotes a terrible anti pattern. I would rather use a code example that doesn't have to use an anti-pattern as a tool of teaching.

I chose to use state directly on a known component like the Counter and keep it simple, instead of creating a container/top level component just to show this. The post is an intro to hooks and how to migrate from life cycle methods, not about "best practices with hooks" 😃

So go ahead! Create a similar post with examples that you consider "good" and without "anti-patterns". The site is full of posts like mine, so the same time that you're using to comment in every post on the topic to highlight anti-patterns, can be invested in actually show it in a post of yours (turning those "I would" into actions) 🎉

I'm sorry; please don't take it so personally; I'm just saying that this post is one of the top results on Google for thinking in react so it shouldn't take much energy or time to make sure that newbies don't get bad ideas. I actually liked this post a lot; wanted to send this over to someone who hated React and now wants to try it instead of Angular; and I couldn't send this over just because of the examples and how they do exactly what we have to set rejection rules in code reviews for. I'll try to find some time to write docs around this; and I'll link it here if I do; thanks!

Don't worry! I didn't took it personally at all! 😊 ... I'm just saying that this site is great for sharing knowledge about code, and is far better to have different perspectives in different posts instead of continuously fix a pre-existing one.
I appreciate the time you put into responding to point out stuff that could be confusing, but I think that creating a new post would be more impactful.
That's the same thought that drove me to make this series of post (because the original "thinking in React" felt super outdated) 😋

code of conduct - report abuse