Next.js Tooltip Component with Drivn

Drivn installs through a small CLI that writes the component source straight into your repository — there is no runtime UI package to version-lock and no positioning library underneath. From the root of your Next.js 16 project run npx drivn add tooltip. The command writes a single tooltip.tsx under your UI directory; the CLI reference documents every flag, including targeting a custom path or adding several components at once. The Tooltip has no peer dependencies beyond React itself — it does not even pull a lucide-react icon, since the trigger is whatever children you pass. After install the file is yours: a future Drivn release will not overwrite your edits, and the whole component, from the styles object to the four position classes, is a short file you can read top to bottom. If this is your first Drivn component, the installation guide covers the Tailwind v4 and path-alias setup it assumes.

Here is where the Tooltip differs from most interactive components in a Next.js app: it needs no client boundary. Because the tip is shown with CSS group-hover and group-focus-within rather than React state, the source carries no 'use client' directive and no hooks — so you can render a Tooltip directly inside a Server Component, an async layout, or a statically generated page with nothing extra. Wrap any trigger — an icon button, a word, a badge — as the children and pass the label through the content prop. The tip is position="top" by default, sitting above the trigger. There is no provider to mount and no context to thread, unlike a tooltip built on a positioning engine; a single self-contained Tooltip is the whole API. See the Tooltip examples for more triggers and placements.

The position prop places the tip on any of four sides of the trigger — top, bottom, left, or right — and defaults to top. Each value maps to an entry in the styles.positions object that combines an absolute-position anchor with a small margin, so top sits the tip above the trigger with bottom-full and an mb-2 gap, while right uses left-full and ml-2. The prop is typed as keyof typeof styles.positions, so your editor autocompletes the four allowed values and rejects anything else — no magic strings. Choose the side by where the trigger sits in the layout: a tooltip on a left-rail icon reads best on the right, while one on a top toolbar button belongs on the bottom. Because the placement is plain CSS offset classes rather than a runtime measurement, there is no flip-on-collision logic — you pick the side that fits.

Every behaviour of the tooltip lives in one styles object, and it is worth reading because there is no JavaScript doing the work. The wrapper carries styles.base — relative inline-flex group — which makes it a Tailwind group and the positioning context for the absolutely placed tip. The tip itself is hidden at opacity-0 and revealed by two variants: group-hover:opacity-100 for the mouse and group-focus-within:opacity-100 for the keyboard, with transition-opacity easing between them. It is pointer-events-none so it never intercepts a click, and z-50 so it floats above surrounding content. The surface is bg-foreground text-background — an inverted chip that reads against any background — with rounded-lg, text-xs font-medium, and whitespace-nowrap. The block below is copied verbatim from tooltip.ts; because you own the file, restyling the tip is a direct edit to these classes, not a config override. See theming to align the tokens it references with your app.

A tooltip that only shows on hover is invisible to keyboard and touch users, so Drivn wires focus in from the start. The wrapper span sets tabIndex={0}, which puts the trigger in the tab order, and group-focus-within:opacity-100 reveals the tip whenever focus lands inside the wrapper — so tabbing to the element shows its label the same way hovering does. The base also sets outline-none on the wrapper, so pair the tooltip with a trigger that carries its own visible focus ring — a Button already does — rather than an unstyled span, so keyboard users can still see where they are. Keep the content short, since the tip is whitespace-nowrap and will not wrap; for a longer hint, a static description near the control reads better than a tooltip. Because the whole thing is a plain focusable span with CSS-driven visibility, it degrades gracefully and adds no client JavaScript to your Next.js bundle.