What can a UI library do for your app?
A UI library gives you reusable parts such as buttons, menus, forms and dialogs. First decide what someone needs to do on the screen. A confirmation needs a clear choice and reliable keyboard controls. Once those work, you can change how the dialog looks without rebuilding the action.
Which part of the screen do you need help with?
Start with the action someone should be able to finish. A menu needs to open and let people choose. A button that already works may only need a clearer label or a more visible focus outline.
| What you need | Where to start | What you still decide |
|---|---|---|
| A button or field that looks consistent with the rest of the app | A styled library or the controls already in your project. | The label, what happens on click or submit and how to show a mistake. |
| A dialog or menu with a custom design | A headless primitive, a building block that supplies interaction behavior and leaves the appearance to you. | The visible design, wording and how the action fits your screen. |
| One component you expect to change often | A source recipe you can copy into the app and edit. | Which packages it needs and how you will merge later fixes. |
| A particular treatment for an existing control | A component gallery or a visual effect. | Whether the preview works with your project and how it behaves without hover or motion. |
On a small screen, scroll the table sideways to read every column.
How can you test a dialog before adding a library?
Try one confirmation in a local file. The example resets a made-up display choice from Large text to Standard text. It only changes the words on that page and returns to the starting state when you reload.
<!doctype html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Display choice test</title>
<p>Display choice: <output id="choice">Large text</output></p>
<button type="button" id="opener">Reset display choice</button>
<dialog id="confirm" aria-labelledby="dialog-title">
<h2 id="dialog-title">Reset display choice?</h2>
<p>Return this sample to standard text.</p>
<form method="dialog">
<button value="cancel" autofocus>Cancel</button>
<button value="reset">Reset</button>
</form>
</dialog>
<script>
const dialog = document.querySelector("#confirm");
const opener = document.querySelector("#opener");
const choice = document.querySelector("#choice");
opener.addEventListener("click", () => {
dialog.returnValue = "";
dialog.showModal();
});
dialog.addEventListener("close", () => {
if (dialog.returnValue === "reset") {
choice.textContent = "Standard text";
}
opener.focus();
});
</script>
</html>- Open the local sampleSave the code as display-test.html and open the file in your browser. You can keep this test offline. Tab to Reset display choice and press Enter. Check that the question is visible and Cancel receives focus.
- Check how someone backs outPress Tab and Shift+Tab to reach both choices. The control behind the dialog should stay inactive while it is open. Press Escape and check that Large text remains and focus returns to Reset display choice. Open it again and choose Cancel to verify the same result.
- Confirm the one intended changeReopen it and choose Reset. Look for Standard text and check that focus returns to the opener. Reload before a second run to get the starting choice back.
- Keep the same checks when changing the designIn an isolated copy, change the appearance while keeping the controls and the behavior. Try a narrow window and touch if available. If you add motion, repeat the check with your device set to reduce motion. Both choices should remain clear and reachable.
Compare tools
Scroll the table sideways to read every column.
| Tool | What you getAn installed control, copied source, a gallery or an effect. | What your project needsThe framework, styles and packages an example expects. | What you still testLabels, keyboard access and motion in your actual screen. | What you maintainWhere you make changes and how you bring in fixes. |
|---|---|---|---|---|
| 21st.dev | A gallery of components by different authors, such as a styled button or a larger page section. | Check the exact item. A React and Tailwind example can also depend on a local styling helper. | The original Sheen Pill example uses a native button and has a keyboard focus outline. Other items need their own checks. | Follow the item's source and license. Keep changes in your copy and compare any upstream update before applying it. |
| Aceternity UI | React components and animated effects for screens and page sections. | Check the item's Tailwind setup and dependencies. Animated Modal uses Motion. | The Animated Modal source handles pointer dismissal. It leaves Escape, focus handling and accessible naming to your integration. | Edit copied code in your project. Check whether the chosen block is public or part of the paid collection. |
| Fancy Components | Effects such as animated lettering that you can add to an existing control. | Use the React and Tailwind setup and the item's dependencies. Letter Swap uses Motion. | Letter Swap provides styled text. Let a native button handle clicking and keyboard activation. | Edit the copied effect and keep the MIT notices. Compare any upstream change with your edits. |
| Material UI | A package of styled React controls, including dialog and button components. | Check React compatibility and the styling setup. The standard installation uses Emotion. | Dialog uses Modal's focus handling. Supply the dialog title and connect opening, closing and confirmation in your app. | Change styles through the shared theme. Review package upgrades and keep the app's own labels and actions. |
| Motion Primitives | Copied React controls with motion. Dialog is an example that includes interaction behavior. | Set up Tailwind, Motion and the helpers required by the selected item. | The Dialog source opens a native modal and handles Escape. Verify focus return and reduced motion in your version. | Own the local changes to copied source. Update Motion and other installed packages separately. |
| shadcn/ui | Styled source you can add and edit, with Alert Dialog recipes for different behavior packages. | Match the recipe to your existing React project and its styles. The add command can bring in packages. | Start from the selected Alert Dialog recipe, then check the actual labels, focus and confirmation in your app. | Change shared colors through the theme and edit the local files when behavior differs. Preview upstream updates before merging. |
What should you check before adding a component?
Find out what your project already uses and compare it with the item’s instructions. A React component needs an app that can run React. Some examples also assume Tailwind for styles and a package such as Motion for animation.
A dependency is code your project needs from another package. Ask for the list of files and dependencies an item would add, plus any change it would make to shared colors or styles. Preview the changes if the tool supports it, especially if your project already has a button or dialog by the same name.
For an ordinary button, try the control you already have before changing the project setup. For a date picker, form or chart, try the hard part of the real job, such as an invalid date, a missing required answer or the need to read a value without pointing at the graph.
Who keeps the component working after you change it?
With an installed package, you keep your settings and upgrade the package when you want its fixes. With copied source, you edit the file in your project and decide which changes from the original author to bring back.
Keep the smallest useful change. A shared theme can set colors and spacing for several controls. Edit one component file when the change belongs only to that component. After a package upgrade or source merge, run the same check for focus and confirmation.
Look up the license for the exact item. Permission to modify code can require keeping a notice. Photos, icons or other assets used in a demo can have separate terms.