The goal of this exercise is to talk about a little known hook called useRef
. This hook is similar to the ref
system I spoke about in a previous article (link here), but there are some key differences to keep in mind.
To illustrate this hook we’re going to create a dropdown, where the overall goal will be to show a list of options. A user will click on the dropdown and a menu will open up with a list of colors that a user can select…whatever color is selected, some text will show up in that color. Easy enough.
I was recently asked a question about how to scale an app. When I work on my own personal React projects, I don’t really think about scaling…I mainly focus on playing around with code to understand all its nuances. That’s probably the case with a lot of new developers…if you’re just working on a small project, thinking about scaling can actually get in the way of the creative work. In fact, a number of solutions to scaling introduce complexity and abstraction, which in turn can make testing code harder, fixing bugs and introducing new features becomes more difficult and and…
In the first part of this two part series (link here), I started a deep dive into the useEffect
hook. We built a search bar that called on the Wikipedia API to return a list of results based on a user’s input…and then we displayed those results. The end product looked like this:
In a previous article (link here), I took a deeper dive into React’s useState
hook and promised I would do the same with the useEffect
hook. I’ll break this examination into two parts, since I want to deal with a couple odds and ends that relate to a small widget I built to illustrate useEffect
.
Ok, so, to illustrate this hook, we’re going to build a simple search widget that calls on the Wikipedia API.
In a previous article (link here), I briefly touched on the benefits of using React hooks to allow your Functional components to act more like Class components. In this post, and a subsequent one, I’d like to take a slightly deeper dive into the two most commonly used Hooks, useState and useEffect.
One of the most important reasons why Class components are so popular in React is the ability to hold state. Up until the creation of the hooks system, Functional components were totally unable to compete with that functionality. …
In a previous blog post I wrote (here), I talked about how important it was to determine the runtime complexity of the code you use to tackle problems. Developers are always looking for the most efficient solution. In some cases, the solution you come up with immediately is not the most performative one and you will want to rewrite the code completely; in other cases, however, you do not necessarily have to completely scrap the code you wrote initially.
Let’s take the Fibonacci algorithm as an example. The Fibonacci series is an ordering of numbers where each number is the…
Whenever you tackle a problem in code, there is a good chance that the solution you come up with will not be identical to solutions arrived at by other developers. Maybe one developer likes building character maps, while another likes bubble sorting. Depending on what you’re working on this MAY (notice the caps there) not be a big deal. However, in many cases you DO need to pay attention to exactly which solution you choose. Why? Isn’t the point to just solve a problem, no matter how it’s done? Obviously, since I’m asking the question, the answer is clearly no…you…
In quite a few of my React apps, I’ve pulled images from some outside API to then be displayed on a page to users. It’s a fairly simple process, BUT there is almost always an issue when it comes to rendering the images; oftentimes the images that are returned are large and not uniformly formatted.