According to the React maintainers, React developers reach for the `useEffect` hook too quickly](https://beta.reactjs.org/learn/you-might-not-need-an-effect).  It is far from the only hook with many naive usages. Why won't we go through my favorite example of an incorrect usage for `useRef`?

## What is the `useRef` hook?

In React, the data used for rendering is immutable. A change in a piece of state is committed through a setter or reducer.
```tsx
const Component = () => {
	const [name, setName] = useState<string>('');

	return (
		<input
			type="text"
			value={name}
			onChange={e => setName(e.target.value)}
		/>
	);
};
```
These changes are observable to execute effects, invalidate memoization and rerender your component.

`useRef` initializes and gives you access to a mutable variable across executions of your component or hook.
Mutable because on each render, `useRef` will return the same `RefObject` to which you can store data.
```tsx
const Component = () => {
	const buttonPresses = useRef<number>(0);
	return <button onClick={() => buttonPresses.current++}/>;
};
```
They do not trigger all the cool stuff that the observable state does.



A powerful and straightforward way to look at React is that it wants us to [keep our state and UI in sync](https://twitter.com/RyanCarniato/status/1353801411331416070).

## Where and when can you use `useRef`?
`useRef` is not just an escape hatch but can be used to read and write data in event handlers and effects. Remember that changing the ref won't trigger the `useEffect` through its dependency array.

It's not unreasonable to think that you can only pass a `RefObject` to a jsx `ref` attribute.

```tsx
const container = useRef<HTMLDivElement>(null);
return <div ref={container}>{children}</div>;
```
> Note that we initialise `useRef` with `null`.  `container.current` is reset to `null` whenever the node unmounts.
> Therefore `container.current` will only ever be an `HTMLDivElement` or `null`.
> It is important for typesafety and generally considered good practice to always pass something to the `useRef` initializer.

You should use this pattern whenever you want to access your DOM nodes inside `useEffect` or event handlers.

For example, when we want a click on the `::backdrop` of a [`<dialog>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog) to close it.
In the `onClick` event handler, we first check if the click target is the dialog element.
Then we can use the native [`dialog.close()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/close) API to close it.

```tsx
const Dialog = ({ children, state }) => {
	const dialogRef = useRef<HTMLDialogElement>(null);
	
	const handleClick = (e) => {
		if (e.target === dialogRef.current) dialogRef.current.close()
	}
	
	return (
		<dialog ref={dialogRef} onClick={handleClick}>
			{children}
		</dialog>
	);
}
```

## Where it breaks down

When I explained you could use mutable refs inside of `useEffect`, and you can assign a DOM node to that mutable ref through the ref attribute, you might try to add and remove event listeners inside of `useEffect`.

This pattern was deployed inside [formkit's auto-animate](https://auto-animate.formkit.com. I discovered this when I checked why their react hook was only sometimes working for me.

This is a slightly simplified version of the [bundled hook](https://github.com/formkit/auto-animate/blob/master/src/react/index.ts):
```ts
import { useEffect, useRef, RefObject } from 'react'
import autoAnimate, { AutoAnimateOptions } from '../index'

/**
* AutoAnimate hook for adding dead-simple transitions and animations to react.
* @param options - Auto animate options
* @returns
*/

export function useAutoAnimate<T extends Element>(
	options: Partial<AutoAnimateOptions> = {}
): [RefObject<T>] {
	const element = useRef<T>(null)
	
	useEffect(() => {
		if (element.current instanceof HTMLElement)
			autoAnimate(element.current, options)
	}, [element])
	
	return [element]
}
```

And this is how I consumed the `useAutoAnimate` hook.

```tsx
import { useAutoAnimate } from '@formkit/auto-animate/react'

const Component = () => {
	const [container] = useAutoAnimate<HTMLUlElement>();
	const [items, error] = useSwr(/* swr config */);

	return (
		<section>
		{!items && !error && (<spinner />)}
		{items && (
			<ul ref={container}>
				{items.map(/* item renderer */)}
			</ul>
		)}	
		</section>
	)
};
```

Did you spot the problem?
This fragment has the unobservable reference `element` inside the dependency array of a `useEffect`, which does not work. This `useEffect` will only execute after the initial render. If the initial render has `items`, the ref will hold the `<ul>` DOM node.

Due to waiting for data to fetch, `element` hasn't received the DOM node and fails to register the autoAnimate.

## Callback refs to the rescue

Let us figure out what the jsx `ref` attribute accepts as value.

```ts
interface RefObject<T> { 
	readonly current: T | null;  
}  
type RefCallback<T> = (instance: T | null) => void;

type Ref<T> = RefCallback<T> | RefObject<T> | null;
```

From the React docs, we know that `RefCallback` receives the DOM node when being rendered and `null` on unmount. With this knowledge, we can rewrite the hook to accept DOM updates.

```ts
import { useCallback } from 'react';  
import autoAnimate, { AutoAnimateOptions } from '@formkit/auto-animate';  
  
type Options = Partial<AutoAnimateOptions>;  
  
const useAutoAnimate = <T extends HTMLElement>(options?: Options): ((element: T | null) => void) => {  
    return useCallback(  
        (element: T | null) => {  
            if (!element) return;  
            autoAnimate(element, options);  
        },  
        [options]  
    );  
};

```

## An example with ResizeObserver

I was building a new pagination interaction for Flare's redesign, and a `ResizeObserver` came into play. This example shows that `useRef` is useful in other ways than accessing the DOM and how registering and cleaning up DOM observers/listeners can be accomplished using a callback ref.

```tsx
const Component = () => {
	const [size, setSize] = useState<ResizeObserverSize | null>(null);
	
	const observer = useRef<ResizeObserver>(new ResizeObserver((entries) => {
		setSize(entries[0].borderBoxSize);
	}));
	
	const registerResizeObserver = useCallback(instance => {  
	    if (instance) return observer.current.observe(instance);  
	    
	    observer.current.disconnect();   
	}, []);

	return (
		<ul ref={registerResizeObserver}>
			{/* ... */}
		</ul>
	);
};
```

Note that by defining the `ResizeObserver`'s callback inside of `Component` it can access state setters but cannot access the updated state because it created a closure on initialisation.

## Read more

The React team is hard at work on building better documentation so that we can focus on writing better React code.
[referencing values with refs](https://beta.reactjs.org/learn/referencing-values-with-refs) goes into more detail on how to use `useRef` safely.
The challenges at the bottom of [manipulating the dom with refs](https://beta.reactjs.org/learn/manipulating-the-dom-with-refs) can build up your understanding of using DOM apis in react.

The old [callback refs](https://reactjs.org/docs/refs-and-the-dom.html#callback-refs) documentation outlines the idea of using a function for more fine-grained control over when refs are set and unset. The caveats of which can be solved using the `useCallback` hook.


You might not need useRef for that

Hi!
I'm new here and I guess so are you.
I am one of those developers with tons of ideas and no time to bring them all to life; who starts working on each and every one of these ideas barely finishing any.

With this blog I hope to focus myself on finishing some of my most interesting ideas and sharing what I learn along the way.

### Trigger
Yesterday my new employer filled out their [about us](https://spatie.be/about-us) section with my information.

🎉 Yay 🎉

Unsurprisingly they had linked one of my unfinished projects as "my website".

"I should finish this website right now!" - washed over me as I went to my (endless) folder of unfinished projects. Some other projects drew my eye and my brain got excited again.

That's how I made some big steps in the technical redesign of [my girlfriend's webshop](https://hope.tigrr.be).

### First time?
As I was converting an old JavaScript webcomponent codebase to Next.js with typescript I  copied the server function that communicated the order to the payment provider.

```
ERROR: Total amount (€35.49) does not match the cumulative price of the items in this order (€35.48).
```

I quickly spotted the one cent difference and started looking for my code that converted numbers into currency.

```ts
const toCurrency = (amount: number) => {
	return {
		currency: 'EUR',
		value: toDoubleDecimalString(amount)
	}
};

const toDoubleDecimalString = (value: number) => {
	const e2 = `${Math.floor(value * 100)}`;
	if(e2 === '0') return '0.00';
	if(e2.length === 1) return `0.0${value}`;
	if(e2.length === 2) return `0.${value}`;
	return `${e2.slice(0, e2.length - 2)}.${e2.slice(e2.length - 2)}`;
};
```

Did you spot it?

I floored a floating point number and it broke my payment flow when people ordered an amount of an item...
Since I wasn't expecting anything more specific than one cent I could fix this with `Math.round`.

That's where I learned my lesson and never made any floating point errors ever again.

Right?

After publishing the webshop I moved on to one of my favorite projects on the list, a javascript [3D toolpath generator](https://slicer.sams.land) for my polar 3D printer.

## Hours of debugging
Picking this project up I started by importing some new models to test with and found a big list of problems in no time. Tracking down where my code went wrong was orders of magnitude more dificult.

One of the critical parts of the slicer was converting a set of edges into a set of continuous shapes; matching the end vertex of an edge to another edge – a slice. the slicer kept generating multiple open shapes in very specific cases and it took me hours of debugging to  rediscover that I was working with an aproximate numbering system.

The implementation of my new `equals` function uses an arbitrarily small number as a tolerance and suddenly half of my problems were solved.

– For the first time since I picked up JavaScript, I would love to have python's `__eq__` now.

```ts
const TOLERANCE = 0.00000001;
const equalsWithTolerance = (a: number, b: number, tolerance = TOLERANCE) =>
	Math.abs(a - b) < tolerance;
```


## Pick perfect precisions
The arbitrarily chosen tolerance in `equalsWithTolerance` didn't only match vertices but also ran a calculation that removes vertices that lay in the middle of straight lines. Upon closer inspection, the tolerance needed was exponentially higher than the one I had been using.

## Conclusion
Try to make a concious decision on the tolerance needed when working with floating point number, figure out what happens in each function with tiny margins of error and tolerate them accordingly.

Reading my old code made my happy with the strides I took the last 2.5 years of coding professionally. I now look to the future knowing there will always be stuff lined up for me to learn about and share.

Blog

You might not need useRef for that

=== doesn't float

Why are we not thinking about tolerances in floating point equality checks.

In progress

Home of hope

Footprints garden