DEV Community: Senthil Kumar

Stop Rewriting Browser Fingerprinting Logic in React: Meet "useFingerprint"

Senthil Kumar — Sun, 11 Oct 2026 20:09:10 +0000

Browser fingerprinting is an interesting technique for understanding whether multiple browser visits might come from the same browser environment. But if you're building React applications, implementing browser-signal collection and managing its lifecycle can quickly become repetitive.

What if you could encapsulate that functionality in a reusable React hook and use it wherever you need it?

That's the idea behind useFingerprint, one of the browser-focused hooks in useThisHook, an open-source collection of reusable React hooks.

Explore the live demo: https://usethishook.mentorbridge.in/useFingerprint

What Is Browser Fingerprinting?

Every browser exposes information about its environment. Depending on browser capabilities and permissions, this may include:

Browser and platform characteristics
Screen dimensions and display properties
Language and locale settings
Time zone information
Other browser-exposed signals

Individually, these signals may not be particularly distinctive. Combined, they can contribute to a browser fingerprint.

A browser fingerprint is a derived identifier based on characteristics of the browser environment. It can help applications assess whether visits may be associated with a similar environment.

However, there is an important distinction:

A browser fingerprint is not a guaranteed, permanent identity for a person or device.

Different browsers on the same device may produce different fingerprints. Browser updates, privacy protections, configuration changes, and fingerprinting defenses can also affect the result.

Why Use a Custom React Hook?

Imagine you're developing an application that needs to work with a browser fingerprint.

Without a reusable abstraction, you might end up implementing the following concerns in individual components:

Collecting the required browser signals
Handling asynchronous initialization, where applicable
Managing the resulting value
Integrating browser-specific logic with React's component lifecycle
Handling environments where browser APIs are unavailable

Repeating this logic across components increases maintenance costs and makes it harder to keep implementations consistent.

React custom hooks offer a better way to organize reusable stateful behavior.

Instead of coupling browser-related logic to a particular component, you encapsulate it behind a reusable function.

That is where useFingerprint comes in.

Introducing `useFingerprint` from useThisHook

useFingerprint is a browser-focused custom hook in useThisHook, a reusable React hooks library.

The library follows a straightforward philosophy:

Stop rewriting the same React hooks in every project.

Rather than rebuilding common behavior for every application, developers can install the library and import the hooks they need.

The useFingerprint hook provides an abstraction for working with a client-side visitor identifier derived from browser signals.

You can explore its interactive documentation here:

Try useFingerprint

Installation

If you haven't installed useThisHook yet, add it to your React project.

Using npm:

npm install usethishook

Using pnpm:

pnpm add usethishook

Using Yarn:

yarn add usethishook

Using `useFingerprint` in a React Component

Once the package is installed, import the hook from the library.

import { useFingerprint } from 'usethishook';

function FingerprintExample() {
  const fingerprint = useFingerprint();

  return (
    <section>
      <h2>Browser Fingerprint</h2>
      <pre>{String(fingerprint ?? '')}</pre>
    </section>
  );
}

export default FingerprintExample;

This example illustrates the intended integration pattern: call the hook inside a React component and render the resulting value.

Important: Verify the hook's exact return type and initialization behavior against the official useFingerprint documentation before using this snippet. The example assumes that the hook returns a directly renderable value; if its documented API returns an object or exposes a loading state, adapt the component accordingly.

The key idea is to keep browser fingerprinting behavior separate from the UI that consumes it.

Where Could You Use Browser Fingerprinting?

Browser fingerprinting can be relevant to several application scenarios, depending on the implementation and applicable privacy requirements.

1. Analytics and visitor analysis

Applications may use browser-derived signals as one input when analyzing repeat visits or understanding browsing patterns.

A fingerprint should not be treated as a definitive count of unique people because one person may use multiple browser environments, and multiple people may share one environment.

2. Fraud prevention

Browser signals can contribute to a broader fraud-detection system.

For example, a backend service might consider browser-derived signals alongside account activity, transaction patterns, authentication events, and other risk indicators.

A fingerprint alone should never be treated as proof of identity or sufficient evidence to block a legitimate user.

3. Session risk assessment

Applications may incorporate browser characteristics into risk assessments for sensitive workflows.

For instance, a financial application might evaluate changes in browser signals alongside authentication and session information.

For security-sensitive applications, keep the following principle in mind:

Browser fingerprints are supporting signals, not authentication credentials.

Use server-side authorization, secure session management, and appropriate authentication controls to protect sensitive operations.

Is Browser Fingerprinting Reliable?

Not completely. Understanding its limitations is essential before integrating it into a production application.

Fingerprints can change

A browser update, operating system change, or altered browser configuration may affect the collected signals.

Different users may share similar signals

Fingerprint collisions are possible. A fingerprint should not be assumed to be globally unique.

Privacy-focused browsers may reduce fingerprintability

Some browsers and extensions intentionally restrict or standardize exposed characteristics to make tracking more difficult.

Fingerprinting has privacy implications

Browser fingerprinting can contribute to tracking users without traditional cookies. Depending on the purpose, implementation, and jurisdiction, collecting or using fingerprint data may trigger transparency, consent, or other legal requirements.

If your application serves users in the European Union, assess your implementation against the applicable GDPR and ePrivacy requirements. Do not assume that browser-derived identifiers are exempt from privacy obligations simply because they are not stored in cookies.

Collect only what you need, explain the purpose clearly, and obtain consent where required.

Best Practices When Using `useFingerprint`

Before using browser fingerprinting in a production application, keep these practices in mind:

Define the purpose first. Avoid collecting browser signals without a clear product or security requirement.
Do not use fingerprints as authentication. A fingerprint does not prove who a user is.
Plan for changes. Your application should handle fingerprint changes and missing values gracefully.
Consider server-side rendering. Browser-specific APIs are unavailable during server rendering. Verify that the hook handles server environments safely.
Test privacy protections. Check how your application behaves when browser signals are restricted or unavailable.
Review privacy requirements. Document the data collected, retention policy, and intended use.

Why I Built useThisHook

As React developers, we repeatedly solve similar problems across projects.

Sometimes the repeated logic is simple, such as managing a boolean. Other times, it involves browser APIs, asynchronous behavior, state management, or interactions that require more careful lifecycle handling.

I built useThisHook to make reusable React behavior easier to discover, understand, and integrate.

The library brings together practical hooks with documentation and interactive examples, allowing developers to focus more on application requirements and less on repeatedly rebuilding common functionality.

useFingerprint is one example of the browser-focused utilities available in the collection.

Try It Yourself

Explore the hook, review its documented API, and experiment with the interactive example.

Live demo: https://usethishook.mentorbridge.in/useFingerprint
Library: https://usethishook.mentorbridge.in/
GitHub repository: https://github.com/senthilkumar979/useThisHook
npm package: https://www.npmjs.com/package/usethishook

If you find a useful improvement, encounter an edge case, or want to contribute another reusable hook, contributions and feedback are welcome.

Final Thoughts

Reusable hooks are valuable when they encapsulate behavior that would otherwise be duplicated across components.

Browser fingerprinting is one example where a focused abstraction can make browser-related logic easier to integrate into a React application.

But good engineering involves more than reducing boilerplate. It also means understanding the limitations, privacy implications, and security boundaries of the underlying technology.

Build reusable behavior. Keep the UI focused. Use browser signals responsibly.

That is the philosophy behind useThisHook.

Happy coding!

— Senthil Kumar

Building practical tools for React developers through useThisHook.

Building Better Overlays in React: Why I Built `useOverlay`

Senthil Kumar — Wed, 30 Sep 2026 13:01:03 +0000

Modals. Drawers. Popovers. Bottom sheets. Confirmation dialogs. Dropdown panels.

They all look simple from the outside.

But once you start building them in a real React application, the logic around them becomes surprisingly complicated.

You need to think about:

When the overlay should open
How it should close
Clicking outside
Pressing Escape
Preventing accidental dismissal
Rendering above the application
Managing focus
Returning focus to the trigger
Supporting nested overlays
Keeping the implementation reusable
Avoiding duplicated state and event-handling logic
Making the UI work consistently across different screens

And if every feature implements its own version of this logic, your application eventually ends up with several slightly different modal and drawer implementations.

That is the problem I wanted to solve with useOverlay, one of the hooks in useThisHook.

A reusable React hook should remove repetitive engineering work without forcing your application into a particular UI design.

This article explains the problem, the design thinking behind useOverlay, practical usage patterns, and where a reusable overlay abstraction fits into a React application.

What exactly is an overlay?

An overlay is UI that appears above the normal application content.

Common examples include:

Modal dialogs
Confirmation dialogs
Drawers
Side panels
Bottom sheets
Popovers
Contextual menus
Full-screen overlays
Command palettes

For example:

┌──────────────────────────────────────────────┐
│ Application                                  │
│                                              │
│     ┌──────────────────────────────┐         │
│     │                              │         │
│     │       Confirmation            │         │
│     │                              │         │
│     │   Cancel          Continue   │         │
│     │                              │         │
│     └──────────────────────────────┘         │
│                                              │
└──────────────────────────────────────────────┘

The visual design is usually not the difficult part.

The difficult part is the behavior.

The hidden complexity behind a simple modal

A first implementation might look like this:

const [isOpen, setIsOpen] = useState(false);

return (
  <>
    <button onClick={() => setIsOpen(true)}>
      Open
    </button>

    {isOpen && (
      <div className="modal">
        <h2>Delete account?</h2>

        <button onClick={() => setIsOpen(false)}>
          Cancel
        </button>
      </div>
    )}
  </>
);

Nothing wrong with this.

For a simple application, this might be completely sufficient.

The problem starts when you build several different overlays.

You may eventually have:

UserProfile
 └── EditProfileModal

Orders
 └── OrderDetailsDrawer

Checkout
 └── PaymentConfirmationModal

Notifications
 └── NotificationPopover

Settings
 └── DeleteAccountModal

And suddenly each component has its own:

useState(...)

plus:

onClick(...)

plus:

onKeyDown(...)

plus:

useEffect(...)

plus:

createPortal(...)

plus:

document.addEventListener(...)

The UI is different.

But much of the behavior is the same.

That's where a hook becomes useful.

The idea behind `useOverlay`

The core idea is simple:

Separate overlay behavior from overlay presentation.

Your application should decide what the overlay looks like.

The hook should help manage the behavior required to control it.

Conceptually:

                 ┌──────────────────┐
                 │    Application   │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │   useOverlay     │
                 │                  │
                 │  open            │
                 │  close           │
                 │  toggle          │
                 │  state           │
                 │  behavior        │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │ Overlay UI       │
                 │                  │
                 │ Modal            │
                 │ Drawer           │
                 │ Popover          │
                 │ Bottom Sheet     │
                 └──────────────────┘

This distinction is important.

useOverlay should not dictate whether your application uses:

Tailwind
CSS Modules
styled-components
plain CSS
a design system
a component library

It should provide behavior that your UI can consume.

This is also a common design direction in existing React overlay systems. For example, React Aria's useOverlay focuses on overlay behavior such as outside interaction and Escape-key dismissal, while Primer's implementation also handles behaviors such as focus management. The APIs differ, but the underlying architectural idea is similar: separate behavior from presentation.

A simple `useOverlay` workflow

A typical application flow looks like this:

User clicks button
       │
       ▼
open overlay
       │
       ▼
overlay becomes visible
       │
       ├───────────────┐
       │               │
       ▼               ▼
User interacts      User dismisses
       │               │
       │               ├── Escape
       │               ├── Outside click
       │               └── Close button
       │
       ▼
Application continues

The important part is that the consuming component does not need to rebuild the same overlay-control mechanism every time.

Example: A confirmation dialog

Imagine an account deletion flow.

Without an overlay abstraction, you might write:

const [showDeleteDialog, setShowDeleteDialog] = useState(false);

const openDeleteDialog = () => {
  setShowDeleteDialog(true);
};

const closeDeleteDialog = () => {
  setShowDeleteDialog(false);
};

Then the component handles the dialog.

With useOverlay, the component can instead work with an overlay controller.

Conceptually:

const overlay = useOverlay();

const handleDelete = () => {
  overlay.open();
};

And:

<button onClick={handleDelete}>
  Delete account
</button>

The important improvement isn't that useOverlay magically makes a modal shorter.

The improvement is that overlay behavior can become a reusable primitive.

Overlay state should be predictable

One of the most important things when designing a reusable hook is predictable state.

An overlay generally has two primary states:

CLOSED
  │
  │ open()
  ▼
OPEN
  │
  │ close()
  ▼
CLOSED

And a toggle operation can be represented as:

CLOSED ── toggle() ──> OPEN

OPEN ── toggle() ──> CLOSED

This sounds trivial.

But centralizing that state transition makes the behavior consistent across components.

Instead of every feature inventing its own rules, the hook becomes the common interface.

`open`, `close`, and `toggle`

A useful overlay abstraction normally needs three basic operations.

`open()`

Open the overlay.

overlay.open();

Useful for:

Opening a modal
Opening a drawer
Showing a panel
Displaying a contextual UI

`close()`

Close the overlay.

overlay.close();

Useful for:

Cancel buttons
Save completion
Escape-key handling
Navigation events

`toggle()`

Switch between the two states.

overlay.toggle();

Useful for:

Menus
Expandable panels
Popovers
Toggle-based UI

The exact API exposed by a hook should remain small.

A reusable hook becomes harder to understand when it tries to become an entire UI framework.

The important distinction: behavior vs presentation

This is one of the reasons I prefer hooks for reusable UI infrastructure.

Consider a drawer.

One application might want:

┌───────────────────────┐
│                       │
│       Drawer          │
│                       │
└───────────────────────┘

Another might want:

┌──────────────────────────────┐
│                        ┌─────┤
│                        │     │
│                        │Drawer
│                        │     │
│                        └─────┤
└──────────────────────────────┘

Another might use a bottom sheet:

┌──────────────────────────────┐
│                              │
│                              │
│                              │
├──────────────────────────────┤
│         Bottom Sheet         │
└──────────────────────────────┘

The presentation is completely different.

The behavioral requirements are largely the same.

That's the abstraction boundary.

Where `useOverlay` becomes useful

There are several scenarios where a reusable overlay hook starts paying for itself.

1. Building a design system

If you're building an internal component library, you don't want every consuming application to reinvent overlay state management.

A shared hook can become the behavioral foundation for components such as:

Modal
Drawer
Popover
BottomSheet
ConfirmationDialog
ContextMenu

The components can then provide their own visual APIs.

2. Building a reusable component library

Suppose you are building:

<Modal />

<Drawer />

<Popover />

All three components need overlay behavior.

Instead of implementing it independently:

Modal
 └── custom overlay logic

Drawer
 └── custom overlay logic

Popover
 └── custom overlay logic

you can structure the system as:

              useOverlay
             /     |      \
            /      |       \
         Modal   Drawer   Popover

Now the behavior has a single conceptual home.

3. Large enterprise applications

Enterprise applications often have dozens of screens.

Imagine a banking application containing:

Customer details
Account management
Payments
Loans
Documents
Notifications
Support
Settings

Each area may need multiple overlays.

Without shared primitives, overlay behavior tends to drift.

One modal closes when the user clicks outside.

Another doesn't.

One responds to Escape.

Another doesn't.

One restores focus.

Another doesn't.

These differences are easy to introduce accidentally.

A shared abstraction creates a consistent baseline.

Accessibility is not optional

This is where overlay implementations become significantly more serious.

A production overlay isn't simply:

position: fixed;
z-index: 9999;

There are behavioral concerns around:

Keyboard navigation
Focus management
Escape-key handling
Dismissal behavior
Screen readers
Focus restoration
ARIA semantics
Background interaction
Nested overlays

Established React accessibility libraries explicitly treat these as part of overlay behavior. React Aria's overlay hook, for example, supports dismissal on outside interaction and Escape, while Primer's implementation includes focus-related behavior such as focus restoration.

This is why I would strongly recommend treating useOverlay as a behavioral primitive, not simply a convenient useState wrapper.

Don't confuse an overlay hook with a modal component

This distinction is worth emphasizing.

A component:

<Modal />

is responsible for presentation.

A hook:

useOverlay()

can provide behavior and state.

This gives you a composition model:

useOverlay
     │
     ├── Modal
     ├── Drawer
     ├── BottomSheet
     ├── Popover
     └── CustomOverlay

This makes the hook useful even when you don't use a predefined modal component.

Building a custom overlay

One of the strongest use cases for a generic hook is when your product has a custom interaction.

For example:

┌───────────────────────────────────────┐
│                                       │
│           Application                 │
│                                       │
│                ┌──────────────┐       │
│                │              │       │
│                │ Custom Panel │       │
│                │              │       │
│                └──────────────┘       │
│                                       │
└───────────────────────────────────────┘

You might not want to introduce an entire UI component library just to implement that panel.

You can keep your own markup and styling while reusing the overlay behavior.

That's where a headless approach becomes valuable.

Headless UI: why it matters

A headless primitive generally provides behavior without forcing a visual design.

For example:

const overlay = useOverlay();

Your application remains responsible for:

<div className="my-custom-overlay">
  ...
</div>

You decide:

Colors
Spacing
Typography
Borders
Shadows
Animations
Responsive behavior

The hook should not care.

This makes the primitive much easier to integrate into existing design systems.

A common mistake: putting everything into the hook

There is another side to abstraction.

It's very easy to over-engineer a hook.

For example:

useOverlay
 ├── state
 ├── portal
 ├── animation
 ├── positioning
 ├── styling
 ├── focus
 ├── keyboard navigation
 ├── responsive behavior
 ├── routing
 ├── analytics
 └── business logic

At that point, the hook isn't really a reusable primitive anymore.

It's becoming a framework.

That's not what I want useOverlay to become.

A good reusable hook should have a clear responsibility.

When should you NOT use `useOverlay`?

This is just as important.

If your application has one simple modal:

const [open, setOpen] = useState(false);

that's perfectly fine.

You don't need a library for everything.

I would consider introducing a reusable overlay abstraction when:

Multiple components need overlay behavior
You are building reusable UI components
Your application has complex overlay interactions
You want consistent behavior
You are building a design system
You want to centralize overlay-related logic

Abstraction has a cost.

Don't abstract code merely because you can.

Abstract when the repeated behavior has become a meaningful concept.

`useOverlay` vs `useState`

This isn't really:

useOverlay > useState

It's about different levels of abstraction.

`useState`

Use when you need simple local state:

const [isOpen, setIsOpen] = useState(false);

`useOverlay`

Use when the concept you're managing is specifically an overlay and you want reusable overlay behavior.

Think:

useState
   ↓
primitive state management

useOverlay
   ↓
overlay-specific behavior

The latter is valuable when overlay behavior becomes repeated infrastructure.

`useOverlay` vs a complete modal library

These solve different problems too.

A modal library may provide:

Modal
Dialog
Animation
Backdrop
Focus trap
ARIA
Styling
Theme

A hook can instead provide a smaller behavioral primitive.

That makes it attractive when:

You already have a design system
You already have your own modal component
You don't want another styling system
You need a custom UI
You want a smaller abstraction

There are also established libraries with sophisticated overlay implementations. React Aria, for example, provides overlay behavior specifically around accessibility and dismissal, while other projects combine positioning and animation into a broader floating-element abstraction.

So the goal of useThisHook isn't to claim that every application needs another overlay library.

The goal is to provide small, composable React primitives that solve common problems without forcing an entire UI architecture.

A useful mental model

When deciding whether to create or use a hook, ask:

"What repeated behavior exists independently of the UI?"

For overlays:

UI
│
├── Modal
├── Drawer
├── Bottom Sheet
├── Popover
└── Custom Panel

But underneath:

Behavior
│
├── Open
├── Close
├── Toggle
├── Dismiss
├── Focus
└── Interaction

That's the layer where a hook can provide value.

Testing overlay behavior

Reusable infrastructure deserves tests.

At minimum, test the important state transitions.

Opening

closed → open

Closing

open → closed

Toggling

closed → open
open → closed

Repeated operations

open()
open()
close()
close()

The hook should behave predictably.

If the overlay also manages interaction behavior, test:

Escape
Outside interaction
Focus behavior
Cleanup
Multiple overlays
Unmounting

The exact test suite depends on the responsibilities of the implementation.

Why I built `useThisHook`

useThisHook started from a simple observation:

React applications repeatedly solve the same small problems.

Sometimes the problem is:

"How do I debounce this?"

Sometimes:

"How do I detect an outside click?"

Sometimes:

"How do I manage an overlay?"

Sometimes:

"How do I keep this input behavior consistent?"

None of these problems necessarily deserves an entire application-level abstraction.

But they can be excellent candidates for small, reusable hooks.

That's the philosophy behind useThisHook.

The goal isn't to hide React.

It's to remove repetitive implementation work while keeping the underlying behavior understandable.

Explore `useOverlay`

You can try the interactive useOverlay documentation and examples here:

https://usethishook.mentorbridge.in/useOverlay

The important part of a hook library isn't the README.

It's being able to understand what the hook does, interact with it, and quickly determine whether it solves your problem.

That's why useThisHook focuses on interactive examples alongside the API documentation.

What I'd look for before adding an overlay abstraction

Before adding any reusable hook to a project, I ask five questions:

1. Is the problem repeated?

If it happens once, don't abstract it.

2. Does the behavior have a clear boundary?

If you can't describe what the hook owns in one sentence, the abstraction may be too broad.

3. Can the hook remain UI-agnostic?

The more presentation the hook owns, the less reusable it becomes.

4. Can developers understand it quickly?

A reusable abstraction should reduce cognitive load, not increase it.

5. Can it be tested independently?

If the behavior can't be isolated and tested, the abstraction probably needs another look.

Final thoughts

Overlay UI looks like a visual problem.

In a production React application, it is primarily a behavioral problem.

The modal itself is usually easy.

The difficult part is everything around it.

That's why a small abstraction such as useOverlay can be useful when an application starts building multiple overlay-based interactions.

The key is keeping the abstraction focused:

Application
     │
     ▼
useOverlay
     │
     ├── Modal
     ├── Drawer
     ├── Popover
     ├── Bottom Sheet
     └── Custom Overlay

The application owns the design.

The hook owns reusable behavior.

And React remains the composition layer connecting the two.

If you're building reusable React components, design systems, or simply tired of rewriting overlay state and interaction logic across different features, take a look at useOverlay:

👉 https://usethishook.mentorbridge.in/useOverlay

And if you find an edge case, a missing capability, or a better way to design the API, that's exactly the kind of feedback that makes an open-source hook library better.

About useThisHook

useThisHook is an open-source collection of reusable React hooks designed around practical problems developers encounter while building real applications.

The goal is simple:

Stop rewriting the same React hooks.

Explore the collection:

https://usethishook.mentorbridge.in/

Source code and contributions:

https://github.com/senthilkumar979/useThisHook

DEV Community: Senthil Kumar

Stop Rewriting Browser Fingerprinting Logic in React: Meet "useFingerprint"

What Is Browser Fingerprinting?

Why Use a Custom React Hook?

Introducing useFingerprint from useThisHook

Installation

Using useFingerprint in a React Component

Where Could You Use Browser Fingerprinting?

1. Analytics and visitor analysis

2. Fraud prevention

3. Session risk assessment

Is Browser Fingerprinting Reliable?

Fingerprints can change

Different users may share similar signals

Privacy-focused browsers may reduce fingerprintability

Fingerprinting has privacy implications

Best Practices When Using useFingerprint

Why I Built useThisHook

Try It Yourself

Final Thoughts

Building Better Overlays in React: Why I Built `useOverlay`

What exactly is an overlay?

The hidden complexity behind a simple modal

The idea behind useOverlay

A simple useOverlay workflow

Example: A confirmation dialog

Overlay state should be predictable

open, close, and toggle

open()

close()

toggle()

The important distinction: behavior vs presentation

Where useOverlay becomes useful

1. Building a design system

2. Building a reusable component library

3. Large enterprise applications

Accessibility is not optional

Don't confuse an overlay hook with a modal component

Building a custom overlay

Headless UI: why it matters

A common mistake: putting everything into the hook

When should you NOT use useOverlay?

useOverlay vs useState

useState

useOverlay

useOverlay vs a complete modal library

A useful mental model

Testing overlay behavior

Opening

Closing

Toggling

Repeated operations

Why I built useThisHook

Explore useOverlay

What I'd look for before adding an overlay abstraction

1. Is the problem repeated?

2. Does the behavior have a clear boundary?

3. Can the hook remain UI-agnostic?

4. Can developers understand it quickly?

5. Can it be tested independently?

Final thoughts

About useThisHook

Tags

Introducing `useFingerprint` from useThisHook

Using `useFingerprint` in a React Component

Best Practices When Using `useFingerprint`

The idea behind `useOverlay`

A simple `useOverlay` workflow

`open`, `close`, and `toggle`

`open()`

`close()`

`toggle()`

Where `useOverlay` becomes useful

When should you NOT use `useOverlay`?

`useOverlay` vs `useState`

`useState`

`useOverlay`

`useOverlay` vs a complete modal library

Why I built `useThisHook`

Explore `useOverlay`