npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@gemeente-denhaag/modal

v3.0.3

Published

The Modal component

Readme

Modal

npm version

Modals are overlays that prevent users from interacting with the rest of the application until a specific action is taken.

When to use

Use a modal to request information that is preventing the system from continuing a user-initiated process. It can also be used to notify the user of urgent information concerning their current work. Modal dialogs are commonly used to report system errors or convey a consequence of a user’s action. Finally, it can be used to confirm user decisions. Clearly describe the action being confirmed and explain any potential consequences that it may cause. Both the title and the button should reflect the action that will occur.

Alternatives and related components

  • Use an accordion to present large amounts of additional information or actions that don’t require confirmation
  • Use a banner to communicate a change or condition that needs the users attention within the context of a page

Anatomy

The modal consists of:

  1. Title: gives users a quick overview of the modal.
  2. Close icon: closes the modal.
  3. Text: contains the information needed to complete the modal’s task. It can include message text and components.
  4. Buttons (optional): button that allows users to perform an action or close the modal.
  5. Overlay: screen overlay that obscures the on-page content.

(Interactive) states

None.

Design properties

Typography

  • Title: TheMix/xl/700
  • Text: TheSans/md/400

Colors

  • Title: text color Blue/3
  • Close icon: svg color Grey/4
  • Text: text color Grey/4
  • Overlay: background-color white

Button

The buttons text only, medium primary and secundary are used.

Structure

  • Title: padding-top and padding-left 32px, margin-bottom 16px
  • Close icon: height and width 24px, padding-right 32px
  • Text: padding-left and padding-right 32px, margin-bottom 48px
  • Buttons: padding-right and padding-bottom 32px, padding space between buttons 16px

Accessibility

[technical accessibility requirements]

Error alerts in forms

Error alerts

If users submit long or complex forms with errors, use an error alert to summarize what went wrong. Place the alert at the top of the form and move the focus to the banner when the form is submitted. This will allow all users to scroll through the form in a logical order to resolve the issues.

Inline errors

Always include inline error messages for specific form fields so that users know what to do in context while correcting their errors.

Content guidelines

Title

Modal titles should:

  • Use a clear {verb}+{noun} question or statement.

Body content

Body content should be:

  • Actionable: start sentences with imperative verbs when telling an user what actions are available to them (especially something new). Don’t use permissive language like "you can".

  • Structured for users success: always put the most critical information first.

  • Clear: use the verb “need” to help users understand when they’re required to do something.

Primary and secondary actions

Actions should be:

  • Clear and predictable: users should be able to anticipate what will happen when they click a button. Never deceive a user by mislabeling an action.
  • Action-led: actions should always lead with a strong verb that encourages action. To provide enough context to users use the {verb}+{noun} format on actions except in the case of common actions like Save, Close, Cancel, or OK.
  • Scannable: avoid unnecessary words and articles such as the, an, or a.

Best practices

Dos

Use modals when users must complete an action before they can continue with the main workflow. Avoid using modals to display complex forms or large amounts of information.

Modals should:

  • Require that users take an action.
  • Close when users press the X button, the Cancel button, or the ESC key, not when users click or tap the area outside the modal.
  • Be used very sparingly.
  • Be used for important warnings, as a way to prevent or correct critical errors.
  • Be used to request the user to enter information critical to continuing the current process.
  • Notify the user after the action that has been taken.

Don’ts

Modals should:

  • Not be used for nonessential information that is not related to the current user flow.
  • Not have more than two buttons (primary and secondary) at the bottom. This prevents unclear action hierarchy and crowding on mobile screens. Since modals are for focused tasks, they should have focused actions.
  • Not be closable when the users click or tap the area outside the modal.
  • Not include multiple steps.
  • Not cram in too much.
  • Not include important information.
  • Not open suddenly. A modal should always open upon the user doing (or did) something.

Javascript

Import the @gemeente-denhaag/modal/src/modal.js javascript file to you site to allow the modals to work.

See the example below:

import ModalScripts from "@gemeente-denhaag/modal/src/modal";
window.addEventListener("DOMContentLoaded", () => new ModalScripts());

References

Figma Design http://www.uxforthemasses.com/overlays/ https://www.nngroup.com/articles/modal-nonmodal-dialog/