Forem: Christopher Borchert

Using block-scoped variable at the module level

Christopher Borchert — Thu, 26 Nov 2020 11:26:06 +0000

I was doing some code review today, and I found myself correcting a relatively junior dev's code, leaving the message, "Using let outside the component scope tends to be an antipattern. Use a useRef or a useState inside the component scope instead."

I think that this is generally true, and it was definitely true in the case of the other dev (they should have been using useState in this case). But I got to asking myself whether it is globally true. Is using block-scoped variables at the module level of React components, generally, an anti-pattern?

An example

For the purposes of demonstrating what I'm talking about, imagine the following code.

// MyComponent.js
import React, { useState } from "react";

let blockScopedVal = 0;

export default () => {
  const [myVal, setMyVal] = useState(0);

  return (
    <div>
      <button onClick={() => blockScopedVal ++)}>blockScopedVal: {blockScopedVal}</button>
      <button onClick={() => setMyVal((old) => old + 1)}>myVal: {myVal}</button>
    </div>
  );
};

There are two basic implications of this code:

First, clicking on the first button will not cause a rerender of the component, similar to as if I had used a useRef.

For example, if I click the first button 10 times, I won't notice anything change in the UI, but when I click the second button, the first button's displayed value will jump to 10 and the second button's displayed value will increment correctly to 1.

Second, if you have more than one <MyComponent />, they will share the variable blockScopedVal behind the scenes.

For example, imagine that I have two MyComponents. If I click the first button (the blockScopeVal incrementer) of the MyComponent 10 times, I won't notice anything change in the UI, but when I click its second button, the first button's displayed value will jump to 10 and the second button's displayed value will increment correctly to 1. The second MyComponent will still be at "blockScopedVal: 0" "myVal: 0". But, if I click the second MyComponent's second button, I'll have "blockScopedVal: 10" "myVal: 1". The blockScopedVal's value is shared between the two instances.

This is where using a block-scoped variable differs significantly from using a useRef.

The question(s)

Is using block-scoped variables in React component modules an anti-pattern? If so, why? If not, what are some use cases?

My "don't do this" alarm went wild when I saw the let during code review, and in the case I was presented, my intuition was completely right, but I was unable to say why a priori this is definitively an antipattern. Imagine that you do want to share scope across all instances of the same component and only across the instances of that component ¹ Is there any good reason not do to it this way, instead of reaching for some slick library?

I guess the difficulty is that I can't think of a great use case. Can any of you? Or, conversely, can you explain why we should never do this, ever?

I look forward to hearing from you all, and if you want to play around with the concept a bit, I made a code sandbox.

... and to do so in a way that doesn't trigger rerenders. Ok I might be reaching here since the number of use cases seems to be diminishing before my eyes. But still. Imagine. ↩

The great iterate debate: filter/map, reduce, or for?

Christopher Borchert — Wed, 29 May 2019 15:52:36 +0000

Originally published on my blog

Intro

Imagine the following, relatively common scenario: I have an array which I need to pick specific items out of and transform into a new format.

I've noticed that this problem comes up especially frequently in React land when there's an array of components that needs to be generated from an array of objects.

An example

For example, imagine that, given an array of user objects, we need to take only the users that have verified their account, and create a list of their emails:

The user list:

const users = [
  { name: 'alex', isVerified: true, email: 'alex@mail.net' },
  { name: 'bobby', isVerified: false, email: 'bobby@mail.net' },
  { name: 'charlie', isVerified: true, email: 'charlie@mail.net' },
  { name: 'dannie', isVerified: false, email: 'dannie@mail.net' },
  { name: 'elliot', isVerified: false, email: 'elliot@mail.net' },
  { name: 'finn', isVerified: true, email: 'finn@mail.net' },
]

We want the following array as a result:

['alex@mail.net', 'charlie@mail.net', 'finn@mail.net']

A visual example

For those who prefer a visual, imagine that we have objects with a shape and a number value, and we want an array of all the numbers from the squares:

Three common paths

How would you get to the goal from the examples above?

I've come across three main patterns for dealing with this situation: using a for loop, filtering the array and then mapping the result, or using a reducer. Let's take a closer look at each of these approaches, using the users object from the first example and the goal of having an array of email addresses as the result. Note that in the code I'm going to try my best to make the code intelligible, so I'll skip destructuring parameters and nitpicking every character. This isn't code golf, after all 😉!

For loop

Code

const users = [
  { name: 'alex', isVerified: true, email: 'alex@mail.net' },
  { name: 'bobby', isVerified: false, email: 'bobby@mail.net' },
  { name: 'charlie', isVerified: true, email: 'charlie@mail.net' },
  { name: 'dannie', isVerified: false, email: 'dannie@mail.net' },
  { name: 'elliot', isVerified: false, email: 'elliot@mail.net' },
  { name: 'finn', isVerified: true, email: 'finn@mail.net' },
]

// initialize array
const userEmails = []
// loop through each item, pushing their email to the list if the user isVerified
for (let i = 0; i < users.length; i++) {
  if (users[i].isVerified) {
    userEmails.push(users[i].email)
  }
}

console.log(userEmails)
// [ 'alex@mail.net', 'charlie@mail.net', 'finn@mail.net' ]

Ah, the for loop: one of the corner stones of most programming languages. Simple and versatile! There's not too much to explain here, and if you've done some programming in any language you should be able to see what's going on here. We're initiating a new array and pushing elements into it.

Pros

By far the fastest option to compute (see the section below about performance).
Relatively readable (I'd give it a score of 3/5: if you read the code you'll see what's going on because we're not doing anything fancy).

Cons

Verbose (minified length of 96 characters)
Easy to mess up: even though the code itself is simple, there are more moving parts here. You could easily make a mistake such as writing for (let i = 0; i <= users.length; i++) and not necessarily realize it.
It's not hip. I mean we've had ES6 array methods, for, like, ever! Why would we ever mutate the value of any variable? (While true, this is meant to be sarcastic.)

filter + map

const users = [
  { name: 'alex', isVerified: true, email: 'alex@mail.net' },
  { name: 'bobby', isVerified: false, email: 'bobby@mail.net' },
  { name: 'charlie', isVerified: true, email: 'charlie@mail.net' },
  { name: 'dannie', isVerified: false, email: 'dannie@mail.net' },
  { name: 'elliot', isVerified: false, email: 'elliot@mail.net' },
  { name: 'finn', isVerified: true, email: 'finn@mail.net' },
]

const userEmails = users
  .filter(user => user.isVerified) // keep if user.isVerified is truthy
  .map(user => user.email) // for each filtered user, return the email

console.log(userEmails)
// [ 'alex@mail.net', 'charlie@mail.net', 'finn@mail.net' ]

I'm not going to hide anything here. This is the winner in my mind (with the exception of if you're really looking to improve your the performance of your app by shaving off microseconds.

Pros

The second fastest option to compute (see the section below about performance).
Very readable (I'd give it a score of 5/5: just at a glance, we know that we are filtering (removing) items from an array, and then mapping (transforming) the remaining items. We know that we'll get an array back after the operations are performed.).
The least verbose (minified length of 63 characters)
Hard to mess up. For the same reason that makes this code easy to read, this code is hard to mess up. Performing small, chained operations for the win!

Cons

I'll wait for someone to correct me, but I'm going with "none" unless you're supporting IE10 or something.

reduce

const users = [
  { name: 'alex', isVerified: true, email: 'alex@mail.net' },
  { name: 'bobby', isVerified: false, email: 'bobby@mail.net' },
  { name: 'charlie', isVerified: true, email: 'charlie@mail.net' },
  { name: 'dannie', isVerified: false, email: 'dannie@mail.net' },
  { name: 'elliot', isVerified: false, email: 'elliot@mail.net' },
  { name: 'finn', isVerified: true, email: 'finn@mail.net' },
]

const userEmails = users.reduce((accumulator, user) => {
  if (user.isVerified) {
    return [...accumulator, user.email] // return the previous array plus the new user email
  }
  return accumulator // otherwise return the array without changes
}, []) // initialize accumulator as an empty array

console.log(userEmails)
// [ 'alex@mail.net', 'charlie@mail.net', 'finn@mail.net' ]

If your intuition was to reach for a reducer, you're too cool for me. While reduce is versatile I find it unintuitive, unfriendly to junior developers and code reviewers, and generally not the best tool for this operation.

Pros

The second least verbose (minified length of 71 characters)
Super hip. I don't know why, but when you use a reducer you've suddenly reached a new leve of hipness.

Cons

The slowest of the three options, computationally (see the section below about performance).
Not very readable (I'd give it a score of 2/5: every time I run into a reduce, it's like the for loops: I need to read every line to wrap my head around the operation; and the return value isn't necessarily an array (you can use a reducer to get a string or a boolean or whatever you want: it's flexibility makes it harder to understand at a glance). Additionally, I just don't like that the initial value of a reduce comes after the reducer function. I find that generally unintuitive.).

Performance

This article actually comes from a code review and the ensuing debate that I had engaged in at work where someone had written some technically incorrect code (they had used just a map, and had not filtered out the unwanted items). In general, we tend to use reduce for everything, and I was arguing for .filter().map(). I ended up writing a JSPerf test outlining the speed difference between the operations discussed here and a few others. I was surprised by the results: .filter().map() performed twice as well as .reduce and for performed three times as well as .filter().map()!

I was surprised by the results, especially, as one of my colleagues pointed out, "We're looping over the data twice with the filter-map, and only once with the reducer." Results may vary by how you write your functions, and the reduce end up being faster than the filter-map, but noy bu much. As for the for loop, I wasn't surprised that it was the winner, but I didn't expect it to win by so much. It turns out that invoking the reduce function repeatedly is pretty time consuming, as briefly described in this article, but some of the details are over my head. If someone can explain why this is the case, I'd love to hear about it.

Verdict

As interesting as the performance results are, we are talking about saving microseconds in the end, and, while it might make sense in some situations to insist on those savings, I don't think that the time savings warrant more obtuse code. For that reason, I'd suggest going with the friendly, self-documenting, hard to screw up .filter().map() for this specific operation.

For the record, I think that reduce probably still has its place, but it's not to replace .filter().map(). I'd actually be hard-pressed to say that it should replace any given for loop since it's just about as descriptive as the for loop, and slower. For me, reduce shines when you can create reusable reducer functions that you need throughout your application, and you just need to drop in myArray.reduce(myReducer, []). I'd love if someone could point out why we should use reduce more often!

Cover Image Credits:
Photo by Javier Allegue Barros on Unsplash

This week I learned: How to mock a Render Props Component in React

Christopher Borchert — Fri, 24 May 2019 13:12:12 +0000

Originally posted on cborchert.blog

Intro

So this little article, as the title says, is about how you might mock Render Props for your test suites, especially if you run across the following error while running your tests:

Warning: Functions are not valid as a React child. This may happen if you return a Component instead of from render. Or maybe you meant to call this function rather than return it.

TL;DR

Your mocks need to support having functions as children or you should use shallow rendering. I ended up replacing my basic mock with the following:

jest.mock(
  './path/to/MyComponent', 
  ({ children, ...rest }) => (
    <mock-my-component {...rest}>
      {typeof children === 'function' ? '[Child as a function]' : children}
    </mock-my-component>
  )

Nota Bene

I want to point out that the situation in this article comes from an unidealized, real-life years-old code base with dozens of people working on it. I may discuss doing things that might not be idealized practices or the most cutting edge, but there might be someone out there trying to fix the warning above. This post is for you. If it helps someone else understand something, even better.

Also, I'm still a newb on some of this stuff, so positive criticism is encouraged :)

Preface: Render Props ?

Feel free to skip this section if you know what a Render Prop Component is.

Understanding the Render Props component pattern in React (a.k.a. the Function as a child component pattern) takes some mental gymnastics. The first time I came across one in the wild, I'm pretty sure that I just sat staring incredulously at my screen for a few minutes before deciding that I wasn't smart enough for the code in front of me and moving on to do something else.

There are plenty of other articles written by eloquent and intelligent people that explain Render Props better than I could, so I'm just going to give a broad overview: "Render Props" is a component pattern in React used to separate the concerns of logic and rendering. For example, say you have a DataProvider component which, uh, provides some data, but you know that you'll want to use this data in different ways throughout your app. In this case, you don't want to limit yourself to rendering the data in a specific way every time. So you create a component <DataProvider /> which handles the data and doesn't really have an opinion of what to do with this data when it comes to rendering. The catch is that we can pass it a function into a property (called render for example) which tells <DataProvider /> how to display the data. Voilà. Render props.

<DataProvider render={data => (
  <h1>Hello {data.target}</h1>
)}/>

You can read a bit more about this pattern in the React Docs or in this blog post (by Robin Wieruch). The gist is that you pass a rendering function to a data management component. It's just another way to separate concerns, and you sometimes come across them in the wild or may find yourself writing one some day for some reason.

It's worth mentioning that sometimes you don't use a named prop at all to pass the render logic, but, strangely, you pass it directly as a child. The above <DataProvider/> component ends up getting used like this if we did it this way:

<DataProvider>
{data => (
  <h1>Hello {data.target}</h1>
)}
<DataProvider/>

Basically, we pass the function to props.children instead of props.render. The reason for this is that it nests better, I guess? I'm not sure, but people do it this way sometimes, and this is little pattern is actually at the crux of what went wrong in my code this week, so look out!

I've also set up a small project on codepen that can give a small illustration of render props/functions as children, mostly taken from the React Docs, for those that like to get hands on.

The error

In my case, I ran into the following situation this week. I'm updating all the unit tests for my current client's rather large testing suite (701 test suites; 3296 individual tests -- yikes!) to fix all warnings and error outputs that occur during the testing process. These are often the result of using i as a key or not using a key at all, or not using act to wrap updates, or that kind of bad practice thing that results in a passing test (and therefore successful pull requests), but indicates a problem either in the code or the tests.

One of these errors which I kept coming up against was:

Warning: Functions are not valid as a React child. This may happen if you return a Component instead of from render. Or maybe you meant to call this function rather than return it.

Following the stack trace, I inevitably came back to the test suite of a component that had a Render Props component as a child. So what's going on?

The mock setup

Well, we often mock the children of our components for our tests, especially if we're using snapshots to check the output of the component that we're testing. This means that if we change the child, we don't need to worry about that breaking a parent's test suite.

The most basic way of doing this is, and the way we often do it to the point of being formulaic is:

jest.mock('./path/to/MyComponent', () => 'mock-my-component');

This way, <MyComponent /> and its props are replaced with <mock-my-component /> with the same props; i.e. <MyComponent foo="bar" />is replaced with <mock-my-component foo="bar" />.

The problem

Are you still with me? Have you figured out what my problem is? It took me a minute.

Basically, we're taking a render props / function as a child prop component and swapping it out (using mock) with a component that expects a normal props.children, then we're passing it the old children, which is still a function.

I mean, does this make sense to you ?

function adds(a, b){ return a+b; };

// ... some time later
const myComponent = ()=>(<div> {adds} </div>)

I hope not. This is why React is freaking out at me: I'm literally passing a dumb component what should be a non-valid child.

So what do we do?

The solution

The two solutions that I've found are 1) Don't mock at all, 2) to use shallow rendering or 3) to write a better mock.

It turns out that using shallow rendering cuts the children prop out of our components so the fact that we're passing functions in is not a problem. In that case, we don't even need a mock! That's great, but maybe that's not your jam. In our case, we have a lot of tests, and using a shallow renderer, in my experience, is slower.

So, I stuck with solution 3) write better mocks.

Instead of

jest.mock('path/to/MyComponent', () => 'mock-my-component');

I ended up going with something along the lines of

jest.mock(
  './path/to/MyComponent', 
  ({ children, ...rest }) => (
    <mock-my-component {...rest}>
      {typeof children === 'function' ? '[Child as a function]' : null}
    </mock-my-component>
  )
);

This mock has the advantage of showing us all the properties we pass into the component, not throwing us a big error, and informing us in the case of a snapshot test, that we've passed a function in as a child to the component.

That's it!

I hope that this helps someone running into the same issues as me, and, please, if there's something in here that you liked or disliked or had trouble with, please leave a comment. Let's start a discussion.

Thanks!