Native, code component or override: building in Framer

When I build something in Framer, I follow one order. First native canvas features: stacks, variants, breakpoints, effects and interactions. Then a clean, typed code component with property controls, when the canvas can’t express the behaviour. Code overrides come last. Native work stays editable by anyone who opens the project, code components package logic behind controls a designer can use, and overrides hide behaviour in places people don’t look. The rest of this post explains how I decide, with examples of when each is the right call.

Should you use native Framer features, a code component or an override?

Use native Framer features whenever the canvas can do the job, because they stay visible and editable. Use a code component when you need logic, data or rendering the canvas can’t express, and expose settings as property controls. Use a code override only for small behaviour on an existing layer that neither of the other two can reach.

Why build with native Framer features first?

Native work is what the next person expects to find. A client, a template buyer or a colleague opens the project, selects a layer and sees how it works in the panel on the right. Nothing is hidden in a file they didn’t know existed.

It also follows the project’s design system automatically. Native layers use the same color styles, text styles and breakpoints as the rest of the site, so a change to a style reaches them too. Code has to be told about those tokens, and often isn’t.

Native covers more than people assume. These are the tools I reach for first:

• Stacks and grids for layout that adapts to content and screen width.

• Breakpoints for changing layout, type size and visibility between desktop, tablet and phone.

• Variants for states such as hover, pressed, open and closed, with transitions between them.

• Interactions that switch variants on click, hover, scroll or when a layer enters the viewport.

• Effects for appear animations, scroll-linked movement and loops.

• Component variables that let a component instance change text, images, colors or visibility.

• CMS collections for anything that repeats, bound to lists and detail pages.

Examples where native is the right call

• A navigation bar that collapses into a menu on phones: a component with open and closed variants, switched by a tap interaction, with a separate layout per breakpoint.

• An FAQ accordion: one item component with two variants, repeated or bound to a CMS collection.

• A pricing toggle between monthly and yearly: two variants of the pricing section, switched by the toggle.

• Cards that lift slightly on hover: a hover variant with a short transition.

When is a code component the right choice in Framer?

A code component is right when the behaviour depends on logic, timing, measurement or data that variants can’t express. Variants are states you switch between. When you need a loop over a set of items, a physics-like drag, a timer that swaps content in sequence, or a calculation based on the screen, you’ve reached the edge of the canvas.

The key is to build it as a proper component, not a quick script. For me that means:

• Self-contained: one component that does one job and doesn’t depend on layers elsewhere on the page.

• Typed: written in TypeScript, so its props are clear and mistakes show up early.

• Property controls: every setting a designer might want, such as speed, spacing, colors, fonts and images, exposed in the properties panel instead of hardcoded.

• Accessible: keyboard support where it’s interactive, sensible ARIA roles, and respect for reduced-motion settings.

• Well-behaved: it renders on the canvas, pauses animation when it’s offscreen, and doesn’t break layout at any breakpoint.

Examples of code components I’ve built

CMS Slider Pro turns a Framer CMS collection into a draggable carousel with autoplay, keyboard navigation, several items in view and pagination options. Framer’s built-in slideshow covers many cases. Multi-item views bound to a CMS collection, with center focus and rubber-band dragging, go past what I could build reliably with variants.

Logo Blur Carousel keeps a fixed row of logo slots and swaps each logo in place from a larger pool, with a blur and roll-up transition staggered across the row. That needs a timer, a queue of logos and per-slot timing. Variants could fake a few swaps, but not a pool of dozens with separate desktop and mobile counts.

Both expose their settings as property controls, so the person using them never opens the code. You can browse more in my Framer components.

When should you use a code override in Framer?

Use an override as a last resort, for a small piece of behaviour attached to a layer you’ve already designed natively. An override is a function that changes a layer’s props or adds behaviour to it. It works, but it has real costs:

• It’s invisible on the canvas. Someone selecting the layer has to notice the override in the panel and then find the file to see what it does.

• It’s tied to a specific layer. Duplicate the section or rebuild the layer, and the behaviour can quietly disappear.

• It often only shows in preview or on the published site, which makes it easy to forget when designing.

• It tends to grow. A one-line tweak becomes shared state across the page, and nobody wants to touch it.

Examples where an override is acceptable

• Setting the current year in a footer copyright line.

• Reading a URL parameter to preselect an option in a form.

• Sending one analytics event when a specific button is clicked.

Each of these is small, stable and hard to express any other way. If an override starts needing its own settings, that’s a sign it should become a code component with property controls.

How do I decide in practice?

I ask three questions, in order:

1. Can I build this with stacks, variants, breakpoints, effects and interactions without fighting the tool? If yes, build it native.

2. Does it need logic, data or rendering the canvas can’t express, and could someone else reuse it? If yes, build a typed code component with property controls.

3. Is it a tiny behaviour on a layer that already exists? Only then write an override.

When I move down a step, I write one line in the project explaining why the step above wasn’t enough. It saves the next person from rebuilding it natively, only to hit the same limit.

FAQ

What is the difference between a code component and a code override in Framer?

A code component is a React component you insert on the canvas like any other element, with settings in the properties panel. An override is a function you attach to an existing layer to change its behaviour or props. Components are reusable and visible; overrides are attached and easy to miss.

Do code components slow down a Framer site?

A well-built one shouldn’t noticeably. Keep them focused, lazy-load images, and pause animation when offscreen. A heavy component with large dependencies can affect loading, so check the published page.

Can non-developers edit a code component?

Yes, through its property controls. That’s the reason to add them: the designer changes speed, spacing, colors or content in the panel without opening the code.

Can I use code components from the Framer Marketplace?

Yes. Marketplace components are inserted into your project and configured through property controls. Check that they respect reduced motion and work at every breakpoint you use.

The short version

Build on the canvas first, because that’s where people look. Reach for a clean code component when the canvas runs out, and keep overrides for the small things nothing else can do. Following that order keeps a Framer project understandable long after you hand it over.