DEV Community

Cover image for Stop Using Alerts Wrong: How to Actually Use the Alert Component in ScreenUI
Navneet Singh Rajput
Navneet Singh Rajput

Posted on

Stop Using Alerts Wrong: How to Actually Use the Alert Component in ScreenUI

#react #opensource #webcomponents #nextjs

Most developers treat alerts like an afterthought.
They throw in a red box, dump some text, and move on.
That’s not just lazy it’s bad UX.
If you’re using ScreenUI, you already have a better system available. You just need to use it the right way.

First, install it properly
ScreenUI isn’t built around copy-paste components. You install what you need using the CLI:

npx screenui-cli@latest add alert --lang ts --path src/components

This pulls the Alert component directly into your project so you can modify it, extend it, and actually own the code.

The mistake most people make
If your instinct is to use it like this:

<Alert message="Something went wrong" />

You’re thinking in the wrong direction.
ScreenUI doesn’t work like typical prop-heavy components.

How the Alert component is actually designed
ScreenUI uses a composable pattern.
That means the Alert is made up of smaller parts:

import {
  Alert,
  AlertTitle,
  AlertDescription,
} from "@/components/ui/alert";
Enter fullscreen mode Exit fullscreen mode

And you build it like this:

<Alert>
  <AlertTitle>Error</AlertTitle>
  <AlertDescription>
    Something went wrong while processing your request.
  </AlertDescription>
</Alert>
Enter fullscreen mode Exit fullscreen mode

This isn’t just a stylistic choice it’s about control.
Why this approach is better
Instead of being locked into a rigid API, you get flexibility.
You can:

  • Add icons
  • Reorder content
  • Inject buttons or actions
  • Control layout completely

Example:

<Alert variant="destructive">
  <AlertTitle>Login failed</AlertTitle>
  <AlertDescription>
    Invalid email or password.
  </AlertDescription>
</Alert>
Enter fullscreen mode Exit fullscreen mode

Now the message is:

  • structured
  • readable
  • instantly clear

That’s what good UI should do.

Use variants to communicate meaning
An alert without context is useless.
ScreenUI supports variants like:

  1. default
  2. destructive (for errors)

Example:

<Alert variant="destructive">
  <AlertTitle>Error</AlertTitle>
  <AlertDescription>
    Unable to complete the action.
  </AlertDescription>
</Alert>
Enter fullscreen mode Exit fullscreen mode

Users shouldn’t have to read everything to understand what happened the UI should tell them instantly.

Real-world usage (where this actually matters)
Alerts are most useful when tied to real logic.

{error && (
  <Alert variant="destructive">
    <AlertTitle>Submission failed</AlertTitle>
    <AlertDescription>
      {error}
    </AlertDescription>
  </Alert>
)}
Enter fullscreen mode Exit fullscreen mode

This keeps your UI clean while still handling real scenarios like API failures.

Final thoughts
At the end of the day, alerts aren’t just visual elements they’re part of how your application communicates with users.
If your alerts are vague, unstructured, or overused, users either get confused or start ignoring them completely. And once that happens, even important messages lose their impact.
On the other hand, when alerts are clear, structured, and used intentionally, they quietly improve the entire experience. Users understand what’s happening without thinking twice.
ScreenUI already gives you the building blocks to do this right.
What matters is whether you treat alerts as a real part of your UI system or just another box with text in it.

If you want to explore all available variants and implementation details, you can check the official documentation here:
ScreenUI Alert Component

Top comments (0)