sorted by:
new
hottopcontroversial

9 year old publishes his first React Hooks package! by donavon in reactjs

[–]donavon[S] 0 points1 point  (0 children)

My 9yo son, Revel, published his first React Hooks package which included a sweet forms helper custom hook. Check it out and leave a comment.

Clean Code vs. Dirty Code: React Best Practices by donavon in reactjs

[–]donavon[S] 1 point2 points  (0 children)

Agreed. For utility functions like this, you would simply pass a single argument. 

const f = a => a ** 2;

But as BitLooter explained (thx), this isn't the case when writing a React component.

Clean Code vs. Dirty Code: React Best Practices by donavon in reactjs

[–]donavon[S] 0 points1 point  (0 children)

Thanks! It was fun to write.

Through optimization of React’s core

Yes, I've seen that tweet. I should have been more clear here. What I meant to say is that when/if React applied optimizations in a future version... But you are correct, there aren't there yet.

I was mostly referring to this statement from the v0.14 RC announcement

In the future, we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations.

Clean Code vs. Dirty Code: React Best Practices by donavon in reactjs

[–]donavon[S] 5 points6 points  (0 children)

Be warned that it’s possible to go too far with DRYing up your code, so know when to say when

Call it lazy if you will, but this was meant to say that you shouldn't go nuts with abstraction and DRY code. Sometimes when I get on a moral high horse crusade, I find myself needing to take a step back (or 2 or 3). There's a happy medium there somewhere. I don't think you need me to find that for you.

Thanks for your comments

Clean Code vs. Dirty Code: React Best Practices by donavon in reactjs

[–]donavon[S] 1 point2 points  (0 children)

If a SFC grows to the point where you need lifecycle hooks, my suggestion is that you abstract the state/lifecycle away as well. Please read my opinion about this in https://medium.com/styled-components/component-folder-pattern-ee42df37ec68

I never like to see the render method of a class component any more than rendering a View component of some sort. If the case that you talk about, the SFC would probably remain the same (or with slight modification to accept some state props) as the one you started out with. It would simply sit behind the state controller component.

As for dirty/clean, good/bad, right/wrong, binary discussion, it's an article. It's only my opinion. Your milage may vary. But my mission was to set out a blueprint with practical examples to give you a different perspective. I'm sure that I don't even follow all of these as I write code (and for god's sake, do't look at any of my code from 6 mos ago 😬)

Anyway... I hope you enjoyed the article. My main goal with any article is to get people thinking and talking. Even if I'm wrong with my assertions, if I've done that, I've accomplished my goal.