How many times have we heard these and similar pronouncements? It’s enough to make you believe that all code comments are bad.
They aren’t. Comments are vital. Written wisely, comments are lifelines for future developers, even yourself.
When developers are admonished that comments are a failure to code well, they are taught to believe that everything must be explainable in code. Sometimes, that’s not enough.
We’re going to use the following code snippet…
On February 2, the Chicago researchers Robert A. Pape and Keven Ruby published their findings on the arrested January 6 insurrectionists in the Atlantic. They discovered that a majority were well-educated and well-to-do, from liberal bastions such as San Francisco and Silicon Valley. Their research couldn’t identify why this new wave of radicalism came forward, but I’d like to propose a reason that could move some, apart from racism or white supremacy: The American Dream, interpreted by the black sheep of our families.
When most of us think of The American Dream, we think of the inspiration that, if we…
How many times have we wanted to update a component’s internal state with data from its properties? There are a variety of ways to do it, but some come with pitfalls.
React is opinionated about not updating state to reflect prop changes, and with good reason. It gets much more challenging and complex to keep track of what the state should reflect. This is the idea behind controlled components, where the controlled component updates the parent’s state instead of trying to synchronize the two components.
The problem with fully controlled components is that, sometimes, the state inside the component can…
This is the fourth and final article on the difference between class-based and functional components. These articles are intended to help React developers who are making the switch from classes to functions, and find themselves irked when some of the mental models they’ve used with class-based components fail them with functional components.
The other articles in the series are as follows:
If you haven’t already read the…
If you’ve been developing React applications for a while, you’ve seen React’s evolution from classes to functions. But even a year after the release of Hooks, the documentation is still largely class-centric. It’s common to hear developers ask, “How do I do
componentDidUpdate with Hooks?” because they’re used to the class-based paradigm of component lifecycle.
Now that Hooks have matured, it’s time for us to move from a class-based paradigm to a functional one.
While React’s documentation highlights some of the differences, it mentions them in passing, surrounded by examples. …
This is the third of four articles devoted to banishing the idea that you can look at functional components using Hooks as if they were like class-based components. The other articles are:
If you haven’t already read the previous two, you may want to take some time and do so.
This article looks at how functional components let you consistently use variables after rendering…
Welcome back. In Part One I gave an overview on how functional components using Hooks have a completely different approach on lifecycle management versus class-based components. In Part Two, I’ll go into how Hooks manage state, and how it can surprise you if you’re used to managing state in classes.
This is Part Two in a four-part series, devoted to users of React class-based components who find functional components with Hooks confusing. The other parts are as follows:
If you’ve been using React for a while, you’ve seen it evolve from classes to functions, but the documentation hasn’t caught up. It describes Hooks, but still describes component lifecycle in class terms, and it causes a lot of confusion. A year after their introduction, people keep asking how to mimic
componentDidUpdate in Hooks, when managing side effects with Hooks is completely different and significantly easier.
This is the first article in a 3-part series that looks at how to let go of class component lifecycles when thinking about functional components. It takes a look at the fundamental differences between…
When we see examples for building reducers in most Redux tutorials, usually we see them use
switch statements, with one
case statement per action type, like so:
While this is fairly straightforward, it can also get to be a bit much, depending on the number and complexity of cases.
Of course, we can make this more readable by extracting the logic into its own set of functions, but we still start everything with this list of cases:
What this change might make apparent is that the logic for each case has a similar interface:
Front-end web developer, React enthusiast, vagabond.