Forem: Dave M

Quit Using Anonymous Functions in Props!

Dave M — Fri, 27 Dec 2024 17:03:22 +0000

Okay, the title is a bit of click-bait. There are times when you need to use anonymous functions as props, but they're probably a lot less thank you think. But first, let's describe the issue.

Anonymous Functions as Props

In component libraries like Svelte and React, anonymous functions used as component props have become a kind of lazy go-to that threatens bloat at larger scale.

I see so many devs do this:

<button onclick={() => handleSubmit()}>Submit</button>

Instead of this:

<button onclick={handleSubmit}>Submit</button>

Each of these code blocks will literally accomplish the exact same result. The only difference is that an anonymous function has been interposed in the first example, and all it does is call a named function with no arguments.

Do you see why using the anon approach could be a problem? Every time this button renders, a brand new anon function is created and held in memory. If you have ten of these rendered on the same page, you have ten distinct anonymous functions held in memory.

Now you might say, "Okay, but how often am I going to have more than, say, ten or twenty interactive elmements on a page?" And the answer is, "You might think it's an edge case, but it comes up more than you might guess. And you might as well be ready for the edge with good habits!"

A prime example of where this can be a problem is in larger tables or lists with interactive features, such as deleting or editing a row or item. If you've got, for example, a data grid type of component on your page and your pagination for it is, say, 100 rows per page, then whatever anonymous function every row creates will be there 100 times. If you've got a checkbox that does something on every row, along with Edit and Delete buttons, you now have 300 anonymous functions held in memory, along with the original 3 functions named and declared, getting called by the anonymous functions.

It's even worse if do trickery like pre-rendering but hiding the next page of data for efficiency's sake. In that example, you now have 600 anonymous function instances sitting in memory.

Okay, then Why Do People Do This?

I can think of at least two reasons why this habit is so prevalent and ingrained.

Reactivity or Other Desired Behavior

At least in Svelte, there are times when you need to do this to ensure the function is called reactively. There may be other types of situations that require you to do this to get your logic to work as predicted, and although it's been a few years since I've worked with React, I bet there are some similar examples in that library too.

But these are edge cases you can address as needed while coding.

Simplifying the passing of function params

This one is likely the most common culprit. It allows you to pass some kind of state directly into the function, so it's easier to grasp and work with when you first learn a UI library like Svelte or React. That's maybe why most tutorials show anonymous functions as props.

Here's an example (in Svelte 5):

// EditButton.svelte

<script>  
  // productId is sent to this component as a prop
  let { productId } = $props()
</script>

const onEditToggle = (productId) => {
  // Do some stuff with productId...
}

<button onclick={() => onEditToggle(productId)}>
  Edit
</button>

Nice and clean, right? But we have this potential performance issue if we have hundreds of instances of this button on this page. How do we refactor this to be more potentially performant?

The Simpler Solution

As is often the case in programming, a simple and straightforward solution is to make sure we create individual components for things like EditButton, and then we have the productId scoped just to that instance. So, we don't have to pass anything to our handler function because it's inside a discrete component that already knows what that productId is. This is why it's generally good if code is more modular than monolithic.

You should definitely attempt to go for this solution first, if you can. And notice that because our component is isolated to handling only one productId, we just don't need that anonymous function. Instead, our component function can handle it directly.

// EditButton.svelte

<script>  
  let { productId } = $props()
</script>

// This is all you really have to do in a component isolated like this!
const onEditToggle = () => {
  // Do some stuff with productId, because we already have it
  // as a prop in memory and scoped here.
}

<button onclick={onEditToggle}>
  Edit
</button>

The More Complex Solution

But there are times when we can't have the update logic confined to a local scale like this due to system architecture or whatever else. To handle this kind of situation, we do something that is, yes, a little bit more complex and, I hate to say it, is slightly less declarative than sending an anon function as a prop. But it's still very readable and works for our purposes of not pushing a bunch of anon functions into memory.

It involves using data attributes on the html element that gets the event you're handling (such as click). And it looks like this:

// EditButton.svelte

<script>  
  // productId and onEditToggle are sent to this component as props
  let { productId, onEditToggle } = $props()
</script>

<button onclick={onEditToggle} data-product-id={productId}>
  Edit
</button>


// DataGridRow.svelte

<script>

  import EditButton from "./EditButton.svelte"

  let { productId, onEditToggle } = $props()
</script>

<tr>
  // ... other cells in the row
  <td><EditButton {productId} {onEditToggle} /></td>
</tr>


// DataGrid.svelte
<script>

  import DataGridRow from "./DataGridRow.svelte"

  let { products } = $props()

  const onEditToggle = event => {
    // Retrieve product ID from element data attribute
    const productId = event.currentTarget.getAttribute("data-product-id")
    // Then do some stuff with that ID...
  }

</script>

{#each products as product}
  <DataGridRow productId={product.id} {onEditToggle} />
{/each}

Do you see what's happening there? We put the product ID into a custom data attribute on the html button element inside EditButton. When the handler function fires, it can retrieve the product ID right off the element's data attribute.

Now we have just one function, onEditToggle, declared in memory, and everything else just points to it by reference.

The Balance Between Readability and Performance

My personal feeling is to always begin with code so well-modularized that the passing of key data is done through props right to that component, rather than having the component be monolithic and have to determine all this internally. This is what I'm describing above in the "The Simpler Solution."

If you absolutely can't do that, then go for the second solution with data attributes.

Now, you could argue that because using anon functions is a little bit more readable than handling data attributes, it's the better thing to start with, so you could just adapt it later if you encounter performance issues.

I agree with that line of thinking generally, but this is one case in which complications from doing it this way are a little bit common enough to just always do it the same way. This way you don't have to think about whether/when to use one approach versus the other. They both work, and one won't require refactoring later if you find you have these performance problems.

Finally, a Caveat

It's entirely possible that Svelte somehow handles this during transpilation to smooth over these anon functions somehow. I'm not enough of an expert on Svelte's runtime or compiler to say for sure. But I personally feel that this is a safer pattern that applies to any JS library you might wind up using, and so it's just a better habit to adopt up-front.

What do you think? Do you have counterpoints? Or maybe can provide insight into what happens at a runtime and compilation level with Svelte that might change my opinion? Let me know in the comments!

Why You Should Be Writing React Custom Hooks

Dave M — Sat, 30 Jan 2021 16:14:48 +0000

You’re probably familiar with built-in React hooks like useEffect and useState. But have you explored writing custom hooks? Or thought about why you would want to?

“No, why would I?” You might ask. And since you’re playing along so kindly, I’ll tell you!

Custom hooks are a handy way to encapsulate hook-related logic that can be re-used across components when using component composition isn’t really something that will help, make sense, or just "look" semantically right.

Think of a custom hook as a super-powered helper function. According to the rules of hooks, you can't call a hook (like useEffect) in an ordinary helper function that is declared outside of a component. But you can call hooks inside custom hooks!

Additionally, if you have a component in which you have two or more separate pieces of useEffect logic going on, you might want to consider putting them into custom hooks to separate and name them, even if this isn’t logic that will be shared by any other component.

This is much like encapsulating logic into a well-named function for the sake of readability and code organization. After all, it’s a bit tough to read a string of useEffect routines and understand what’s going on. But if, on the other hand, you have one called something like useSyncCustomerRecordStore, then your consumer code is that much more readable.

Headless Components

It’s not quite a perfect comparison, but in a way, you can think of custom hooks as being a bit like headless components. Mostly because they can call hooks themselves, such as useEffect and useState. These built-in React hooks can work in custom hooks the same way they work in components.

The difference between a custom hook and a component is that a custom hook will return values, not React components or markup. In this way, they’re sort of like component helpers.

The Shape Of A Custom Hook

Custom hooks are really just:

Functions whose names begin with 'use...'
Functions which can call other hooks

A simple custom hook might look like this:

// Custom hook code
function useMyCustomHook(someDataKey) {

    const [someValue, setSomeValue] = useState(null);

    useEffect(() => {
        setSomeValue(useSomeOtherHook(someDataKey));
    }, [someDataKey]);

    return someNewValue;
}

// Consumer component code
function MyAwesomeComponent({someDataKey}) {

    const someValue = useMyCustomHook(someDataKey);

    return (<p>The new value is {someValue}</p>);
}

Example: Page Data

I’m currently working on an enterprise application suite realized in the form of micro-service applications. To the user, it seems like one large application, but really, under the hood, it’s a collection of several independent React apps.

These apps need to refer to each others’ pages with links and common titles, and that data — called pageData — is set up in a context provider so that any component at any level in the apps can access it with a useContext hook.

Now, it is pretty simple to use this data without writing a custom hook. All a consumer component has to do is import the PageDataContext and then call useContext on it, like this:

// External Libraries
import React, { useContext } from 'react';

// App Modules
import PageDataContext from './PageDataContext';

function MyComponent() {

    const pageData = useContext(PageDataContext);

    return (<h1>{pageData.home.title}</h1>);
}

Okay, So Why Use A Custom Hook For This?

Okay, so that's pretty simple, right? It's only three lines of code: two import statements, and a call to useContext. In that case, why am I still recommending a custom hook for a situation like this?

Here are a few reasons, from least to most important:

Eliminating Boilerplate Adds Up

If you just look at this one example, I'm only eliminating one line of boilerplate, because I will still have to import my custom hook, usePageData. I only really eliminate the line that imports useContext.

So what's the big deal? The thing is, just about every page in my enterprise app suite needs to use this pageData object, so we're talking hundreds of components. If we eliminate even one line of boilerplate from each one, we're talking hundreds of lines.

And believe me, just writing that extra line every time I create a new page feels that much more annoying, so there's a sort of pscychological/motivational benefit that adds up over time, too.

Well-Named Functions

If you've used hooks like useEffect much in your code, you've probably come across situations where there are two or three pieces of useEffect logic (either in separate calls to useEffect, or combined into one). This quickly gets hard to take in when you're reading the code.

If you're like me, you wind up putting comments about each piece of useEffect logic, such as:

    // Get the page data
    useEffect(() {
        // ...  stuff happens here
    });

But one of the fundamental concepts of readable code is noticing where you're writing blocks of comments in big dumping ground "main" type functions, and instead separating those pieces of logic into their own, individual, well-named functions. Another developer reading your code is going to have a much easier time taking it all in when these details are abstracted away from the big picture. But when they're ready to drill into detail, they can go look at the function declaration.

The same is true of custom hooks. If I see this in the component code, I have a pretty good idea of what is going on:

   const pageData = useGetPageData();

Encapsulation

I've saved the most important reason for last, and that's that it is good to encapsulate the logic in one place. Sure it's only two lines of code, but what if we decide to store pageData in a Redux or Mobx store instead of React Context?

If we're already using a custom hook, no problem! We just change the internal code in the hook and return the same pageData object back to the consumer code. What we don't have to do is go and update hundreds of components to import, say, useSelector, and then call it instead of useContext.

What useGetPageData Looks Like

It's dead simple! Just:

// External Libraries
import { useContext } from React;

// App Modules
import PageDataContext from './PageDataContext';

function useGetPageData() {
    return useContext(PageDataContext);
}

Other Things You Can Do With Custom Hooks

The example I gave for page data is intentionally very basic, but there are many more useful things you can do with custom hooks, such as encapsulating shared logic for updating and reading Redux state. Just think of anything you want to do with hooks but for which you want to avoid a bunch of copy/paste boilerplate, and you're set to start getting creative with it.

Have fun!

Developers' Perceived Performance

Dave M — Wed, 18 Mar 2020 15:07:00 +0000

We talk about perceived performance by users, but there's also such a thing as perceived speed for a developer. It feels "faster" to dive in writing code without planning, or, for example, doing TDD. But in the end it winds up costing you much more time than it feels like it "saves."

Declarative Programming

Dave M — Fri, 06 Mar 2020 16:40:07 +0000

I've noticed that the concept developers on my teams have the most trouble understanding is declarative coding. I think I have a blog post in me about this. But more importantly, I wonder, is this just a concept that isn't really taught anywhere? If not, we need more emphasis on this very important concept.

Why Worry About Test Coverage?

Dave M — Tue, 03 Mar 2020 15:24:29 +0000

Someone asked me today why we don't just skip failing tests we can't fix quickly and move on. My answer is, imagine a city with a pothole problem. Instead of fixing the potholes, they just close streets and mark detours. After a while, there's no road left.