Forem: Zeke Hernandez

Little React Things: Cleaning up dependencies

Zeke Hernandez — Tue, 24 Jan 2023 15:17:05 +0000

Little React Things is a series of short, React-focused posts where I share some things I've learned over the past few years of developing with React. I hope you find them helpful. These posts might be most helpful for those who have at least a little experience with React already.

Let's kick this short one off with a little thing you may or may not know, but you definitely should know. The setState function identity does not change on rerenders. What this means is that you can (and should) omit setStates from the dependency lists of useEffect and useCallback. This behavior is noted in the official React docs.

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 TodoItems and let's say we can have a bunch of them. Since there can be so many of them we wrap each TodoItem with memo so that each one only rerenders when its own props change.

Furthermore, each todo item can be cloned, so each TodoItem has a callback, onClone. And we have a little helper function cloneTodo that makes such a clone of an existing todo item. The cloned todo is appended to the todos state in handleClone (if you want to know why I wrapped handleClone with useCallback take a look at Your Guide to React.useCallback()).

Here's our React component:

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>
    )
}

Pretty reasonable right? Ship it!

...a few minutes later...

Uh oh, users have started reporting that their todo lists are really slow, particularly when cloning todo items. What happened? We wrapped our TodoItems with memo, so why are they all rendering? Well, one of the props of TodoItem is onClone and we used useCallback for that. And... oh, one of the dependencies of handleClone is todos. And that todos state changes everytime we clone a todo (because we add a new todo to the array). So cloning a todo rerenders all the todos. Not great.

Let's make a small change to handleClone:

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

As I mentioned at the beginning, setTodos does not need to be added to the dependency list. So now this new version of handleClone 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: Less reacting, more deriving

Zeke Hernandez — Tue, 17 Jan 2023 14:51:33 +0000

Back when React Hooks first came out, the useEffect 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 useEffect in the You Might Not Need an Effect.

Even with the guidance from the new docs, these useEffects still tend to pop up in the wild. They can be more than just unnecessary, and actually problems that should be fixed.

A hasty reaction

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, OutfitList that lists all the outfits that fit the parameters. This list of outfits is generated by a very cool helper function called createOutfits; it's not an outrageously expensive function, but we definitely don't want to call it each time the OutfitList 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 OutfitList component.

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>
    )
}

It's great right? We have a useEffect set up to react to changes in the clothing item list or price limit and recreates the list of outfits and updates the outfits state. We only call the createOutfits function when we need to and we keep outfits in sync. All good? Well, there are a couple of issues with this solution.

Reactions are usually not a good idea

Hold up, but it's called "React", what do you mean reactions aren't a good idea? Well, the reacting that we do 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.

When the OutfitList first renders, even if clothingItems is already populated outfits will still be null. This is because useEffect runs after the render. So, for the first render we have populated clothingItems and null outfits. 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 outfits is null as shown in the code above.

Furthermore, in the last post, I gave the guidance to not call the function that is a React application more than you need to, and here the useEffect 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 outfits or maxPrice changes.

State should be the source of truth

For our OutfitList component, let's assume that clothingItems and maxPrice are state in the parent component. Given that, we have three states: clothingItems, maxPrice and outfits. But are those three states actually representing different things? I would argue no. outfits is just a derivation of clothingItems and maxPrice.

This isn't good, state should be a source of truth. But here we have clothingItems, maxPrice, and outfits as state, so which is the source of truth? From the user's perspective, I would probably say it's clothingItems and maxPrice.

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 clothingItems list or that was a slightly higher price than maxPrice and then if the user picks one of those outfits, adjust those states accordingly. But this developer could see some state called outfits 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 not be created from our set of clothingItems 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.

Deriving forward

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>
    )
}

Here we are being explicit that outfits are derived from clothingItems and maxPrice. On the first render, outfits will have a value (given that clothingItems and maxPrice have values of course), we aren't immediately re-rendering after the first render, and we are still only calling createOutfits when clothingItems or maxPrice changes thanks to useMemo.

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: React applications are functions

Zeke Hernandez — Thu, 05 Jan 2023 14:27:58 +0000

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!

React applications are functions

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.

Many of you have seen this notation f(x) = y where f is a function, x the input, and y the output. A React application is the f in that equation, x is your React state, and y is the resulting user interface.

Just a note, when I say "React state", I'm talking about all the React state in your application, from all your uses of useState, useReducer, 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 f, it might look something like:

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

where f1, f2, and f3 are various React children components (with bodies that can also look like the code above) of this component.

When is the function called?

The React function is called whenever x 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 f1 in the code above), React is aware enough to call just that sub-function and not the whole thing.

Does `f(x)` always return the same `y`?

In other words, are React applications "pure functions"? No, they are not. They can be! But often 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.

Implications

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.

Keep the parameters simple

Let's say you have a function, numberStuff(x: number). 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.

Now let's say you have another function, moreNumberStuff(x: number, y:number). With two parameters, you need to be even more careful how you write this function. This function needs to work gracefully if x is positive and y 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.

Use memoization

From Wikipedia:

In computing, memoization or memoisation is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again.

React has a built in higher order component for performing this technique, memo. Memoization like any technique is not a silver bullet. Like anything in software development, there are tradeoffs. When and how to use memo 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!

Handy tips for software support

Zeke Hernandez — Mon, 23 Apr 2018 13:36:55 +0000

This post was first published on my blog, here.

One thing I did not realize when I started my career as a software engineer was how much time would be spent investigating issues and fixing bugs. At my current company, my teammates and I take turns being the point-person for production issues and support tickets; it's not my favorite shift, but it needs to be done.

Being responsible for several issues and bugs can be quite overwhelming, especially if you bounce between several support tickets multiple times a day. Over the past few years, I've adopted several practices that I've found helpful, and maybe they can help you too!

1. Be organized

It sounds obvious, but organization can drastically improve your efficiency as a programmer. When returning to work on a ticket in the morning or after a weekend or after working on something else, we want to spend less time asking "what was this all about again?" or "how far along was I in this?" and more time fixing the problem. Here's how I like to stay organized.

Folder

I like to have a folder that contains a folder for each ticket I'm dealing with that shift. Each folder is labeled with the ticket number and a brief description (usually the title of the ticket). In each folder, I keep any data files that I may have copied from one of our file servers. If I have taken any notes that don't need to be shared on the ticket itself, I'll keep those here too. Lastly, I keep a SQL file here (more on that later).

An extra note about files: if you are investigating a data issue and you have a set of files that have good data and some that have bad, clearly label them GOOD and BAD. It sounds obvious, but I've only just started doing this, and it really helps. The less you have to access the hard-drive that is your long term memory, the faster you work. More significantly, there's nothing worse than scrutinizing a file thinking it's a bad file when, in fact, it is not.

Bookmarks

Similar to our filesystem folder, it is good to have a clearly labeled bookmark folder that has bookmarks to any and all pages relevant to the ticket. Links to reading material, Stack Overflow questions, and documentation are all valuable items to preserve. If you are working on a web application, bookmarks to the pages of issue are very handy as well.

SQL

Lastly, I like to have a SQL file that contains any queries that I use in my investigation of the ticket. Personally, this has been the most helpful practice of all. When jumping back and forth between tickets, I found that I was having to recreate certain queries each time to catch up to where I was before. This is an absolute waste of time. If you have any queries that aren't obvious in their function, slap a comment on them; you may remember what they do now, but you might not after a long weekend.

2. Be humble

Ask for help

You want to find an optimal balance between asking for help and figuring it out yourself. In my experience, that balance is found in asking for help more often than not. What I mean by "asking for help" is not asking someone to solve your problems, but rather to point you in the right direction. If you are afraid that you are bothering your teammates, remember, it's better to spend 15 minutes of both of your time figuring something out than you banging your head against that problem for an hour. If your teammates have been in the game for awhile, I'm sure they understand this.

Your fellow engineers aren't the only people who can help you in fixing issues. If the issue was reported by technical support or customer representative; make sure to chat with them about anything ambiguous or unclear in the ticket. Avoid wasting time solving the wrong problems.

Don't be arrogant, just don't

If a client is reporting behavior in your application as a bug or issue, and tech support sends it up to you, but it turns out the application is working as intended, or the issue is due to customer error; be gracious in your response.

Don't make the tech support person or client feel dumb for not realizing this.
Do use this as an opportunity to reevaluate your application to see if there are ways to prevent this issue from happening again.
Seriously, be kind. It goes a long way.

3. Be helpful

Work with your support team

If you aren't interfacing with customers directly, someone else is, and they are probably the person who reported the ticket. Be conscious of the pressure this position can bring. Be quick in your first response to a ticket; if there's any information you can give immediately, provide that as soon as you can. Also, keep them posted on any updates; you don't want your customers to feel like you aren't working on their issue. Furthermore, if there is a tech support / customer support manager, talk to him or her to see if they have a priority list of which issues should be addressed first. It can be tempting to work on issues that appeal to you, but that is not helpful for your team. Trust your support teams to accurately gauge the feelings of the customer.

Lend a hand to your fellow engineers

In larger engineer teams, it's hard to know the ins and outs of every software component. When you are done investigating and resolving an issue, document it. If you found yourself debugging an poorly documented system, fix that! Don't let the next developer have to go through the same thing as you. You can both document this in a permanent place where your teammates can easily find it, but also I'd encourage just sending a message to your teammates saying something along the lines of "Hey all, I just was investigating x and found out y and z, let me know if you'd like to hear more about it."

Okay, that's all I got. I hope you find at least some of this helpful. If you have any additional tips to share, please do below. Now go put out those fires!

How's your Omnibox game?

Zeke Hernandez — Mon, 08 Jan 2018 00:00:00 +0000

This post was first published on my blog, here.

If you are developer in 2018 chances are, if you are on your computer, you have a web browser open. And according to this, there's over a 60% chance that it's Chrome. If so, this is for you.

By now, many of you know that you can set up custom search engines to use in Chrome's Omnibox, they're super handy. If you know how to set one up, skip down a paragraph; if not, here's how:
In Chrome, go to Settings > Manage search engines. Here you can define custom search engines that have three properties: a name, an alias, and a URL. For example, I have a custom search engine called Wikipedia, with an alias wiki, and http://en.wikipedia.org/w/index.php?title=Special:Search&search=%s as the URL. The %s will be replaced by the search string. If I want to search Wikipedia, all I have to do is, in the Omnibox, type wiki (space or tab) and then the search string (whatever I want to search for), and bam, it is searched.

Now, being able to search websites easily through the Omnibox is well and good, but let's try thinking outside of the (Omni)box. I will share with you some of my favorite custom search engines, and why they are great (or at least neat).

In order from neat to necessary:

5. Translate (for me, English to Spanish)

URL: https://translate.google.com/?source=osdd#en/es/%s
Where en is the "from" language, and es is the "to" language. I would rank this higher if I used it more, but still, handy in a pinch! I'm sure you could do the same with another translating service.

4. Thesaurus/Dictionary

Thesaurus URL: http://www.thesaurus.com/browse/%s?s=t
Dictionary URL: https://www.merriam-webster.com/dictionary/%s
Obviously, use whatever dictionary website you want. Once I set up the thesaurus search engine, I find that I use it a surprising amount! And now I write illustriously.

3. Work related things

I use a lot Atlassian products, like Jira and Confluence, and I've set up a custom search engine for Confluence, and one search engine for each Jira board I'm interested in. If you or your company has some sort of intranet site or wiki or online documentation, a custom search engine works like a charm.

2. Maps

URL: https://www.google.com/maps/search/%s
I use maps as the alias, so I can type "maps Chipotle" and will immediately be shown the nearest Chipotles, which is cool, but we can take it a step further. I can also type "maps here to Chipotle" and I will be given directions to the nearest Chipotle. Technology at it's finest. Furthermore, if you have your home or work location set with Google Maps, you can type things like "maps work to Chipotle" and be given directions for that.

1. Gifs

Google URL: https://www.google.com/search?q=%s&tbm=isch&tbs=itp:animated
Giphy URL: https://giphy.com/search/%s
You want to be the fastest gif in the West? This is how. Call me old-fashioned, but I prefer Google's animated image search over Giphy, especially at work. I mean, the last thing I want is a bunch of flashing colors and images on my screen to draw attention to the fact that I'm looking for a gif.

Honorable Mentions
Amazon, YouTube, Google Calendar, Bible Gateway, Spotify

Happy searching in a customized way!

Also, let me know if you have any custom search engines that you like!

A fresh coat of paint

Zeke Hernandez — Sun, 12 Nov 2017 00:00:00 +0000

My wife and I recently painted several rooms in our house. The old colors were from the previous owners and we wanted to make the house more our own. It really is surprising how much a new wall color can change the overall vibe of a room. It's quite refreshing and brings a new life to the space.

Similarly, I have now been working at my current company for a little more than four months; and up until recently, had been using the default fonts and colors for Visual Studio. But a couple weeks ago I switched from a light theme to a dark theme, hand selected a few colors for major text editor elements (like keywords, comments, and literals), and switched the font to Inconsolata.

All these changes are very superficial, but they helped usher in a new energy when coding. Furthermore, it encouraged me to treat my code as an art: visually pleasing, easy to read and understand, and structurally consistent.

If you feel like your maybe in a rut with coding, try shaking things up a little. Small changes can help add some excitement from what can easily become a daily grind.

Introducing Creative Owlet

Zeke Hernandez — Fri, 10 Nov 2017 18:22:00 +0000

Hey all, so there's this part of my brain that is constantly trying to come up with interesting/unique mechanics for video games. I've tried my hand at implementing these ideas in Unity and whatnot, but I just don't have the resources to allocate to see them through. So if any of you are indie game developers and need some inspiration, check out my blog Creative Owlet for some inspiration.

I'm not saying that these are all amazing, full fledged game pitches, but maybe they could serve as a jumping point for some great games.

Memoization in the wild

Zeke Hernandez — Wed, 07 Jun 2017 23:18:32 +0000

Hi, I'm Zeke

Zeke Hernandez — Wed, 07 Jun 2017 19:04:07 +0000

I have been coding for about six years now, four of those professionally.
Just moved to the Twin Cities, and had my first child. Working remotely for an investment firm in Chicagoland.

I mostly program in Delphi and Java, but I am currently learning more about Angular 2, and front-end development in general.

pictured above is one of the many, many lakes in Minnesota