DEV Community: Donavon West

A Mental Model for Writing React Hook Components

Donavon West — Thu, 17 Sep 2020 17:17:22 +0000

By now we've probably all written a component that uses React hooks. Many times, however, we struggle with what hooks we need or if we need a custom hook.

This article will explain my mental model or how I go about determining how to write my component. We'll do this a step at a time so you can see my process and I'll tell you what I'm thinking at each step.

Write the render first

I think visually, so I like to start with what I'd like to render. This will help me determine what data elements I'm going to need.

For example, if I'm writing a weather component that displays the temp and current conditions, I start with the markup.

💭 What I'm thinking...
I want to display the current temperature and weather conditions for a given city.

It could be something like this.

const Weather = ({ city }) => {
  return <span>{temp}˚F - {conditions}</span>;
};

Cool! Now I know what I want to render and in doing so, I've discovered what pieces of data that I'll need.

Stub in the data

💭 What I'm thinking...
I'd like to see my markup visually before I proceed.

At this point, the app won't compile as there are missing variables, so often I'll mock that data so I can see things working.

const Weather = ({ city }) => {
  const temp = 72;
  const conditions = 'Perfect';

  return <span>{temp}˚F - {conditions}</span>;
};

As you can see above, I've mocked temp and conditions. Now when I run the app I can see my component.

Note: In reality, your component will probably need to have a loading state (unless you're using Suspense), as the data is loaded asynchronously, but for simplicity's sake, I'm not showing that here.

If I like what I see visually, I can move on to actually getting the data. And for this, I like to encapsulate everything into a custom hook.

Write the call to the custom hook

💭 What I'm thinking...
What will the custom hook signature look like?

We now have everything we need to write a custom hook. We know the input (i.e. city) and the output (i.e. temp and conditions). This is our contract.

Now let's replace the mock data in the component with a call to our yet-to-be-written custom hook. Our component will now look like this.

const Weather = ({ city }) => {
  const { temp, conditions } = useWeather(city);

  return <span>{temp}˚F - {conditions}</span>;
};

Write a custom hook

💭 What I'm thinking...
Now I'll write a custom hook that satisfies the contract.

With everything in place, it's time to write a hook that fulfills our contract.

Here is a stubbed out custom hook called useWeather which, for now, will return mocked data.

const useWeather = (city) => {
  return {
    temp: 72,
    conditions: 'Perfect',
  };
};

The app should still run as the mock data is coming from the custom hook.

It should be noted that how we get the data in the hook is an "implementation detail". Meaning that the component shouldn't care how or where it gets the data. We could write something that fetches from a REST endpoint or uses Apollo to get the data from a GraphQL server. The point is that once we've designed the contract, it doesn't matter to the component.

Let's recap

When designing a component...

Start with the rendered markup
Stub in the variables needed
Replace the stubbed variables with a call to get the data
Write a custom hook that fulfills the contract

I find that if I follow these steps, using this as my mental model, writing React components with hooks becomes more straightforward.

I code using const (and why you should too)

Donavon West — Fri, 03 Apr 2020 16:23:56 +0000

There have been endless tweets and many blog posts (even this expletive-laden rant) about how const really isn't constant or how "It's just compiled down to let by Babel anyway, so why use it?"

I'm here to tell you why I ignore all of this "sound advice" and rely on const as an indication of code quality.

Myth: const isn't constant

The fact is you can never re-assign a const. The value that's assigned to it will remain that value until the variable loses scope and is destroyed ('til death do us part?)

Let's take a look.

const myCar = carA;
myCar = carB;

VM101:1 Uncaught TypeError: Assignment to constant variable.

In the example above, you see that you can not, re-assign myCar. If you do, you get an exception.

Selectively assign a value to a const

Hold on. If a const is, um… constant, then how in the world can you selective assign it a value?

Let's look at some code that sets a variable based on some user preference.

let myCar;
if (perferSportsCar) {
  myCar = sportsCar;
} else {
  myCar = minivan;
}

The code above is something that you might find in many a source code repo today. Some people point to this as a valid use case for using let over const. I see it as "code smell". It's verbose, repetitive, and adds visual clutter.

Let's try it again using a const instead.

VM101:1 Uncaught TypeError: Assignment to constant variable.

Yeah, we all should have seen that coming.

How then can we use a const and what was all that talk about code smell?

When I see a let, it tells me that maybe there is a better way to express what you are trying to accomplish. Let's refactor the code to allow for a const.

const myCar = perferSportsCar ? sportsCar : minivan;

Here we decide on a value using a ternary and then assign it. The value of myCar is never re-assigned, but its initial value is selectively determined.

What if we can't use a simple ternary?

There are times when a simple ternary won't cut it. Take this common scenario.

let myCar;
if (type === 'sportscar') {
  myCar = sportsCar;
} else if (type === 'minivan') {
  myCar = minivan;
} else if (type === 'suv') {
  myCar = suv;
} else if (type === 'luxury') {
  myCar = luxury;
} else {
  myCar = economy;
}

Based on type we assign myCar to one of four different cars and default to economy if it's not one of the tested conditions.

When I'm doing a code review and something like this and see that let, it's a red flag. 🚩

Here's something a little more maintainable.

const cars = { sportscar, minivan, suv, luxury };
const myCar = cars[type] || economy;

What do you know, it can be expressed using a const (but you knew I was going to say that, didn't you?)

Are there exceptions to this? Certainly. Just the other day I wrote some code that set the value of a let based on a range of numeric values. This would have been more difficult, and make the code less maintainable if I had used a const.

If const is constant, then why can I change its value?

If your const contains an array or an object, yes, you can change its properties, but the value remains constant. Take this example.

const sportsCar = new Car({type: 'sportscar'});
const myCar = sportsCar;

myCar === sportsCar; // true

myCar.color = 'red';
myCar === sportsCar; // true

Notice that we've changed (i.e. mutated) myCar by setting the color property to "red", yet its value (i.e. sportsCar) remains the same.

Think of it like this. If I buy a car and then paint it red. Is it the same car? Yes. What if I install some sweet new rims? It's still the same car. Starting to get the picture?

Simply changing some aspect of my car doesn't make it a different car, just like setting myCar.color='red' doesn't change the value myCar.

Note: There are ways to freeze an object, which prevents mutation, but that's a different story.

In conclusion

Show me a project coded using all const and I'll show you one that is in all likelihood well written.

For me, const vs. let is less about re-assignment and more about what it says about your code. If your code can be written with all const then I get a better feeling that nothing fishy 🐠 is going on. And when I see that one let, it tells me that I need to examine what's going on a little further.

So let (pun intended) Babel changes my const's to let's a transpile time. As many proponents of let are quick to point out, we save one character per instance in our bundle size! 💃

Math.max() without Auguments

Donavon West — Sat, 21 Mar 2020 14:59:54 +0000

I posted the following "poll" on Twitter yesterday asking what would be returned if you called JavaScript's Math.max() function without any arguments.

donavon "#WashYourHands" west

@donavon

🏆 #JavaScript Quiz time! (no cheating) 🏆

We all know that `Math.max(1, 2, 3)` will return 3.

But what is the result if you call `Math.max()` without any arguments. Bonus points if you can explain why in the replies.

21:42 PM - 20 Mar 2020

2 11

I gave 4 possible answers: undefined, -1, 0, and -Infinity.

I'm just going to go ahead and spoil it for you. The answer is -Infinity (about half of you got it right 👏). But why?

Let's dive into the possible JavaScript-based implementations of Math.max.

Using reduce to return -Infinity

const max = (...values) => (
  values.reduce(
    (max, value) => value > max ? value : max,
    -Infinity
  )
);

Here we accept a single rest parameter called values, which will be an array. reduce is aptly named as it works to translate an array into a single value. We seed the initial max value with -Infinity.

With each iteration through the array, we return value (if it is greater than max) or max. When all values have been compared, we return max to the caller.

So because we seeded max with -Infinity if there are zero items in the array, we return the initial value of max (i.e. -Infinity).

Let's test our code by calling it with some sample data.

assert(max() === -Infinity, 'Should be -Infinity')
assert(max(-1000) === -1000, 'Should be -1000');
assert(max(1, 2, 3) === 3, 'Should be 3');

Yep. They all pass!

This is a short and sweet implementation.

Using reduce to return 0 (or -1)

If we took our code above and replaced the initial value of -Infinity with 0, the code would still work. Or would it?

Let's see this by running our tests again – changing the first one to check for zero instead.

assert(max() === 0, 'Should be 0')
assert(max(-1000) === -1000, 'Should be -1000');
assert(max(1, 2, 3) === 3, 'Should be 3');

As you see, calling max() without any arguments did correctly return 0, but we get an error with the test for -1000.

AssertionError: Should be -1000

Why is max(-1000) failing? What do you think this is returning? It is errantly returning 0 instead of -1000. This is because a value of -1000 is not greater than a max of 0.

People tend to think in terms of positive numbers. Returning 0 would break some valid conditions as we've shown.

Using reduce to return undefined

What if we wanted to return undefined? This isn't a bad idea (my 8-year-old guessed this when I "quizzed" my family) but would add complexity to our solution above.

Let's take a look.

const max = (...values) => (
  values.reduce((max, value) => {
    if (max === undefined) {
      return value;
    }
    return value > max ? value : max;
  }, undefined)
);

You see, we would explicitly need to check if max was undefined inside of our loop. It works, but conditions add time and code complexity.

In conclusion

We've learned that returning -Infinity or undefined are the only possible valid conditions of the four I presented in my Twitter poll.

However, -Infinity greatly reduces code complexity and IMO, is the best solution.

Follow up from Brendan Eich

It turns out that my guess was right! This is exactly how Math.max is implemented. I received the following tweet from the father of JavaScript, Brendan Eich.

BrendanEich

@brendaneich

@donavon That's right. Math.max in ur-JS and ES1&2 took only two parameters, but ES3 generalized to compute maximum of a variable number of arguments. This motivates -∞ as the max of the empty set (0 args) basis case, as you showed.

18:16 PM - 21 Mar 2020

0 2

Block Promoted Tweets on Twitter using Brave

Donavon West — Sun, 16 Feb 2020 21:20:24 +0000

If like me, you'd like to stop seeing obnoxious "Promoted" tweets in your Twitter feed, then this article for you!

I get it. Ad revenue powers the web. But in 2019, Twitter's annual revenue came to 3.46 billion U.S. dollars. So I'll sleep just fine tonight.

Note that this only works if you are using Brave as your browser, but I might ask why you aren't using it already. :)

Brave has a feature where you can filter HTML elements based on a CSS selector. As luck would have it, Twitter marks it's promoted tweets with a data-testid="placementTracking".

To set this in Brave:

Navigate to Twitter.
Right-click anywhere on the background and select the Brave then Block element via selector.
A popup dialog will appear like this.
Enter div[data-testid="placementTracking"] article in the text box and click the OK button.

That's it! Your feed will now be free from obnoxious ads for automobile companies, mobile phones, and others.

Note: Twitter could change it's markup at any time, making this selector invalid. If/when they do, I'll do my best to update the instructions.