Neat Little React Tricks

Here are some React tricks that are too small to warrant a separate blogpost, neat nonetheless.

1. Conditionally Swap Component Type

JSX can ‘dynamic’, in the sense that the component type can be determined at runtime as long the variable name is capitalized ¹. It’s just how JSX desugars

This can be useful when having to switch between two different components that take the same props, like variants of styled components:

Another real world use case is conditionally replacing an old component with a newly refactored one:

Yeah you could conditionally render the element with a ternary expression, or an early return if that’s your jam, as well but this is less work when the component has a lot of props and the props are the same for both.

2. Single-Action Reducer for Toggle State

Have some state that only ever updates in one particular way? Consider using a single-action useReducer over useState!

Take for example, a boolean in useState that can only be toggled. Maybe you’re already using a state updater function to avoid reading the state variable from component scope: setIsOpen((prevIsOpen) => !prevIsOpen). Knock it off and put that logic in a reducer instead, then just call the dispatch without any arguments.

A nice benefit is that the dispatch function toggleOpen is stable (referentially the same function each render), whereas a callback for setting state is not. Calling a setter-wrapping callback in a useEffect requires wrapping it in useCallback to make it referentially stable. And, sure, that works but it’s quite some boilerplate for something as simple as flipping a switch.

Also, a reducer restricts what can be done to the state ². Suppose you’re working in a team on a gigantic app and pass a state setter for a toggle down to parts of the app that fall under your teammates responsibilty. They can now set the state to whatever, which is not what a toggle should be able to do! OK, this might be slightly farfetched but you get what I mean, limiting possibilites is good design✨ .

In my opinion, using a dispatch or a state updater function is much nicer than using a callback to setState.

3. Default children

Real simple, barely a trick but here you go. Just like setting default values on props, you can set a default for the special children prop ³. Set it to a sane default string or element and render children where you want.

I often use it on small reusable (styled) UI components, like buttons and links, that contain the same text most of the time, but need to overriden every now and then. I’m talking about text like “Read more…”, or “Open”,

4. Conditionally Wrap an Element

JSX is just another way to React.createElement, and React elements are just plain objects ⁴. We can declare element variables before the return for reuse.

Here’s an example, it’s a component I use on this blog, it’s a fleshed out <blockquote> as seen on its MDN page. You can pass the component a url props which will both be set as the url attribute on the blockquote element and as the href on the anchor tag inside the cite element. If no url is given, no anchor element should be inside the <cite>.

Another use case could be to conditionally wrap an element with a tooltip.

5. useState to Initialize a Value Once Per Component

First off, putting things in state that don’t belong there is a bad idea, you’ll have a hard time when you do so. Remember that state is reserved for data that changes over time ⁵.

There’s one exception to this rule and it’s using useState to initialize a value once per component, and it sure is a neat trick.

Why would we want to do this? Well, values defined in React components are reevaluated every render, that can be problematic. Sometimes it’s important that a value is initialized strictly once, like an external library. Other times, an object can be ‘expensive’ to create, for instance a huge array or heavy class. If you need to initialize such a value per component, useState can help.

First, the state value is guaranteed to be stable. On top of that, useState accepts an initializer function to ensure the initial state is created just once. React calls the initializer only on mount of the component. The value should never change, so we can just ignore the state setter by not destructuring it.

Voila, a lazily-created, stable value.

“Isn’t this what useMemo is for?” No, not really. useMemo should be seen as a performance optimization for expensive computations based on props and state, we shouldn’t rely on it for one-time initializations ⁶. Or as the docs put it:

You can achieve the same with useRef, below is the example from How to create expensive objects lazily? section Hooks FAQ in the legacy React docs.

But I think it’s not as nice as useState with an initializer. I’d love for useRef to have an initializer function too but it doesn’t.

6. Single-line useEffect with void

The useEffect callback should return nothing at all or if needed, a cleanup function ⁷. No other returns are allowed. This is why the callback can’t be async, because async functions implicitly return a Promise.

It’s also why the function body should be wrapped in curly brackets for arrow functions. If those are left off, the expression implicitly becomes the return value ⁸. With curly brackets, Prettier will dilligently move the function body to a new line.

But sometimes I prefer a small fire-and-forget useEffect to be on a single line. How can we do that?

Here, removing the curly brackets would result in the callback returning a fetch promise ⁹, which is not allowed.

We can make the useEffect single-line by adding a void operator, it evaluates the expression and then returns undefined ¹⁰, that’s the trick.

Now Prettier is satisfied and so am I.

And those were all the tricks for this time!