Let's kick this short one off with a little thing you may or may not know, but you definitely should know. The 

 function identity does not change on rerenders. What this means is that you can (and should) omit 

On to the main topic. For this post I'm gonna roll with the tried and true Todo List example. We have a list of 

s and let's say we can have a bunch of them. Since there can be so many of them we wrap each 

 so that each one only rerenders when its own props change.

Furthermore, each todo item can be cloned, so each 

 that makes such a clone of an existing todo item. The cloned todo is appended to the 

function TodoList() {
    const [todos, setTodos] = useState([])

    const handleClone = useCallback((todo) => {
        setTodos([...todos, cloneTodo(todo)])
    }, [todos])
    
    return (
        <div>
            {todos.map(todo => (
                <TodoItem key={todo.id} todo={todo} onClone={handleClone} />
            ))}
        </div>
    )
}

Uh oh, users have started reporting that their todo lists are really slow, particularly when cloning todo items. What happened? We wrapped our 

, so why are they all rendering? Well, one of the props of 

 for that. And... oh, one of the dependencies of 

 state changes every time we clone a todo (because we add a new todo to the array). So cloning a todo rerenders 

const handleClone = useCallback((todo) => {
    setTodos(currentTodos => [...currentTodos, cloneTodo(todo)])
}, [])

 does not need to be added to the dependency list. So now this new version of 

 doesn't have any dependencies and its identity remains stable throughout the lifetime of the component! Now whenever we clone a todo, that new todo is added to the list without rerendering the already existing ones.

If you want to see these examples live, check them out here:

Little React Things: Cleaning up dependencies

Back when React Hooks first came out, the 

 was introduced and many like myself were like "great, a utility to react to things changing and keeping things in sync". And that is partially true, but it's not as simple as that. The new React docs that are under construction are more explicit about how and how not to use 

Even with the guidance from the new docs, these 

s still tend to pop up in the wild. They can be more than just unnecessary, and actually problems that should be fixed.

Let's say we have an app where a user can buy clothes, but instead of picking out each individual article of clothing, they can pick a bunch of articles of clothing that they like and set a price. Then the application shows the user a bunch of outfits that fit the chosen parameters.

The parent component of the app is where the user can pick the different pieces of clothing from the main list. Then there is a child component, 

 that lists all the outfits that fit the parameters.  This list of outfits is generated by a very cool helper function called 

; it's not an outrageously expensive function, but we definitely don't want to call it each time the 

 is rendered (this kind of function would not be done in the browser typically, but this is a React post, so here we are).

Let's take a look at a way we could create this 

function OutfitList({ clothingItems, maxPrice }) {
  const [outfits, setOutfits] = useState(null)

  useEffect(() => {
    const createdOutfits = createOutfits(clothingItems, maxPrice)
    setOutfits(createdOutfits)
  }, [clothingItems, maxPrice])

  return (
    <div>
      {outfits ? outfits.map(outfit => (
        <Outfit key={outfit.id} outfit={outfit} />
      )) : null}
    </div>
  )
}

 set up to react to changes in the clothing item list or price limit and recreates the list of outfits and updates the 

 in sync. All good? Well, there are a couple of issues with this solution.

Hold up, but it's called "React", what do you mean reactions aren't a good idea? Well, the reacting that we 

 want is reacting to user actions primarily and also asynchronous events. Code that synchronously reacts to your own code, on the other hand, is not desirable.

 runs after the render. So, for the first render we have populated 

. The state is out of sync for that first render which is no good. Our components then need to be made in such a way to account for these discrepancies. For example, we need to add a check to see if 

Furthermore, in the last post, I gave the guidance to not call the 

 is calling that function immediately after it is first called. So instead of one render, we will always have at least two renders each time either 

 are state in the parent component. Given that, we have three states: 

. But are those three states actually representing different things? I would argue no. 

This isn't good, state should be a source of truth. But here we have 

 as state, so which is the source of truth? From the user's perspective, I would probably say it's 

Why is this important? Well, what if down the road a developer is going to add a feature where the user can add a new outfit to the outfit list. The correct way to do this would be suggest some outfits that include a piece that weren't in the 

 list or that was a slightly higher price than 

 and then if the user picks one of those outfits, adjust those states accordingly. But this developer could see some state called 

 and simply just append a new outfit to that list. Uh oh, now we're really out of sync. We have a list of outfits that could 

 or that is a higher price than the price limit. This example is a little contrived, but I hope you get the point at least.

function OutfitList({ clothingItems, maxPrice }) {
  const outfits = useMemo(() => {
    return createOutfits(clothingItems, maxPrice)
  }, [clothingItems, maxPrice])
	
  return (
    <div>
      {outfits.map(outfit => (
        <Outfit key={outfit.id} outfit={outfit} />
      )}
    </div>
  )
}

 have values of course), we aren't immediately re-rendering after the first render, and we are still only calling 

So there you have it, with one technique we followed all three guidelines from the last post, we reduced the number of function calls (renders), simplified the parameters (state), and used memoization. Until next time!

Little React Things: Less reacting, more deriving

This is the first post of the Little React Things series and lays the foundation for the posts to follow. Consequently, it will probably be the longest post of the series, so hang in there!

What are React applications? A React application is a React component that is often made up of smaller React components. What is a React component? It's a function. Then according to the transitive property, a React application is a function. Hooray logic.

Just a note, when I say "React state", I'm talking about 

 the React state in your application, from all your uses of 

, or your favorite state management library (or your least favorite).

If we were to take a closer look at the body of such a function 

function f(x) {
	return (
		<div id="my-react-application">
			<h1>Hello, {x.name}</h1>
			{f1(x)}
			{f2(x)}
			{f3(x)}
		</div>
	)
}

 are various React children components (with bodies that can also look like the code above) of this component.

 changes. Whenever the React state changes, the function is "called" and a new UI is returned. Now, technically, if a piece of state is only scoped to a child component (like let's say 

 in the code above), React is aware enough to call just that sub-function and not the whole thing.

In other words, are React applications "pure functions"? No, they are not. They can be! But usually are not. Though state changes are the only thing to cause the function to be called, there are other things outside React state that affect the resulting UI. The resulting UI could be affected by the browser window size, the current time, or even just a random number generator.

If React applications are functions, then it follows that guidance for writing good functions applies to writing good React applications (more logic!).

Call the function as few times as possible

Calling the same function over and over and over again obviously can cause performance issues in any kind of system. Furthermore, the more you call the function, the more opportunities you are creating for that function to fail.

. You'll want to make sure you write your function in such a way that it works gracefully with whatever number the user passes in. They could pass in a positive number, a negative number, or even zero - not too many options to worry about there.

Now let's say you have another function, 

. With two parameters, you need to be even more careful how you write this function. This function needs to work gracefully if 

 is negative, if they're both positive, if one is zero, or if they're both zero. You've potentially increased the complexity just by adding another parameter.

The same applies to your React state, the more complex your React state, the more complex your React components need to be in order to render a reasonable UI given all the potential permutations.

React has a built in higher order component for performing this technique, 

. Memoization like any technique is not a silver bullet. Like anything in software development, there are tradeoffs. When and how to use 

 could be a post on its own, in fact it often is. One that I recommend is 

Use React.memo() wisely (dmitripavlutin.com)

I hope to provide practical React tips to apply these guidelines in the following posts of this series. So, stay tuned!

Little React Things: React applications are functions

Off and on I've been working on making a game with React, you can read more about it and try it here:

Current side project

's second annual game jam. The theme for this year was "spicy" which was kind of a tough one. 

 won the second prize for Most Polished. Anyway, I don't have the game ported to my site, but you can play it on Replit.

Deliverwing

Goliath Title Screen

, a game jam put on by Replit. Goliath won the second prize for Best Kaboom Game; Kaboom was the featured game engine for the game jam. You can play the original game jam version on 

Goliath

Senior Software Engineer

I've participated in two game jams - both times with winning entries. You can check those games out here.

Games

I started a small, Minnesota-themed greeting card company. Check out some of the cards!