Framer variants and hover states as React code

In a Framer site converted to React, each component's variants become values of a variant prop with the names the designer gave them, such as "Primary" or "Dark / Small". Hover and press states become gesture states named after their variant ("Primary-hover"), switched on per variant in an enabledGestures table. The visual differences between states live in the component's CSS module and in per-variant overrides in the component, and motion animates between them with the transition the designer set. To change a state, edit its class or its override; to add a variant, follow the same pattern.

This post reads a converted component piece by piece. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer, and it converts only sites you own or have permission to convert. The code below is simplified to show the shape; your components will be longer and named after your design.

What is a variant in Framer, and what does it become?

In Framer, a component can have several variants: a button might have Primary and Secondary, each with a hover state. A page can also behave like a component with breakpoint variants: Desktop, Tablet, Phone. Designers switch variants with a property on the instance, interactions or breakpoints.

In the converted project:

Framer itself refers to variants by internal IDs in published code. The conversion replaces those IDs with the names from the design, so variant === "Desktop" reads as it should. Framer's internal attribute names are also neutralised, for example data-framer-name becomes data-name.

Reading a converted component

A component with variants is built around a small state hook from the kit in src/lib/deframer. Simplified, the top of a button component looks like this:

const cycleOrder = ["Primary", "Secondary"];

const enabledGestures = {
  Primary: { hover: true, pressed: true },
  Secondary: { hover: true },
};

const transition1 = { damping: 60, delay: 0, mass: 1, stiffness: 400, type: "spring" } as const;

• cycleOrder lists the component's variants by name. It's also the set of valid values for the variant prop: any other value falls back to the default variant.
• enabledGestures says which variants react to hover or press. Here, Secondary has no pressed state.
• transition1 is a transition from the design, written out with its spring values.

Inside the component, the kit's useVariantState hook works out what to show:

• baseVariant is the variant in effect: the variant prop if it's valid, otherwise the default, or whatever setVariant last set.
• gestureVariant is "<baseVariant>-hover", "-pressed" and so on while a gesture is active, with error and loading states taking priority over press, and press over hover.
• setVariant changes the base variant, which is how a "change to variant" interaction from Framer works in code.

The root element is a motion element, such as <motion.button> or <motion.div>, which receives the variant as its animation label, so motion animates between states with the component's transition.

Where the visual differences live

There are two places, and it's worth knowing both before editing.

1. The CSS module. Each component has a .module.css beside it with classes named after its layers and variants. The kit puts the current variant's class and the active gesture's name on the root, so many differences between states are plain CSS:

/* button.module.css, simplified */
.root { background: var(--token-brand); }
.secondary { background: transparent; }
.root.hover { background: var(--token-brand-dark); }

You can inspect these in the browser's developer tools like any CSS. Colours refer to the design tokens in src/styles/tokens.ts.

2. Per-variant overrides in the component. Some differences aren't CSS: different text, a different icon, a layer that only exists in one variant, or a different motion value. These are written as overrides keyed by variant name, applied on top of the default:

{...addPropertyOverrides(
  {
    Secondary: { "data-border": true },
    "Primary-hover": { animate: { scale: 1.02 } },
  },
  baseVariant,
  gestureVariant,
)}

When both the base variant and a gesture state have an override, both apply, gesture last.

How do I change a hover state?

1. Open the component's file and find its gesture in enabledGestures to confirm the variant has a hover state.
2. Check the CSS module for a class combining the variant and hover. If the change is a colour, border, shadow or opacity, edit it there.
3. If the hover changes text, an icon or a motion value, find the "<Variant>-hover" key in the component's overrides and edit it there.
4. Check the transition. If the hover should feel faster or softer, change the transition's spring values, or its duration for a tween. How to edit a spring explains the values.

To remove a hover state entirely, set that variant's hover to false in enabledGestures, or remove the key.

How do I add a variant?

Say the button needs an "Outline" variant:

1. Add "Outline" to cycleOrder.
2. Add a class for it in the CSS module, using tokens for colours.
3. Add any non-CSS differences as an Outline key in the overrides.
4. If it needs hover, add Outline: { hover: true } to enabledGestures and a hover class or override.
5. Add "Outline" to the variant prop's type if the component's props list variants as a union.
6. Use it: <Button variant="Outline" />.

Then check every place the component is used still looks right; variants share the default's structure.

Breakpoint variants on pages

Pages and some components switch variants by viewport width: Desktop, Tablet, Phone. In the converted project these are separate layouts selected by CSS media queries, with hidden classes for layers that exist only at some widths, so the right layout shows before any JavaScript runs. That's why an edit to one breakpoint's layout often needs repeating in the others. How Framer breakpoints become responsive layouts covers this in detail.

Code components with their own variants

Components written in code in Framer, rather than drawn, keep their own logic. They land in src/code as the site's source, with whatever props and state the author wrote. The conventions above apply to drawn components; code components follow their author's. See Framer code components and overrides.

Can I simplify this into plain React state?

You can. For a small component, rewriting useVariantState into a useState and a few CSS classes is reasonable, and the result may be shorter. Do it component by component with visual regression tests in place, and keep the kit for components you don't rewrite. The kit is part of your project, so you may also read and change useVariantState itself; just remember every component with variants uses it.