Framer code components: custom code your team can still edit

A Framer site usually starts out fully editable: the marketing team changes copy and publishes without waiting for a developer. Then a request arrives that the canvas can't handle, such as a savings calculator or live figures from another system. Custom code can cover it, but done carelessly it creates corners of the site only a developer can change. Here is how we decide when code is needed, and how we keep editors in control.

What can Framer do before you need code?

More than most teams expect, so we check the built-in tools first. Framer's developer docs say many jobs that once needed code overrides are now covered by Effects for animation, Components for interactions and Fetch for dynamic data.

• Components with variants give one element several appearances, and events let a nested item, such as a menu link, switch its parent's variant.
• Fetch loads values from a public API into text layers and component properties, without code.
• The Embed component takes a URL, an iframe or a third-party script.
• Custom Code in Project Settings adds scripts to the whole site or to selected pages.
• The CMS handles repeating content such as posts and team members.

What is the difference between a code component and an override?

A code component adds a new element, while an override changes the behaviour of a layer you have already designed. A code component is a React component that lives inside the project, created from the Code section of the Assets panel. It renders on the canvas, in preview and on the published site, so editors can place and resize it like any other element.

An override is a small function attached to an existing layer. The designer keeps control of how the layer looks, and the override adds logic, such as changing a value on click. Overrides only run in preview and on the published site, and they must pass through the layer's existing props: Framer warns that skipping them can break the layer's appearance or functionality.

How do property controls keep the site editable?

Property controls turn a component's settings into fields in Framer's properties panel, so editors change them on the canvas without opening the code. Developers add them with addPropertyControls and ControlType, which covers text, numbers, toggles, colours, option menus, images, links, files and dates.

import { addPropertyControls, ControlType } from "framer"

addPropertyControls(PricingToggle, {
  monthlyLabel: { type: ControlType.String, title: "Monthly label", defaultValue: "Monthly" },
  showBadge: { type: ControlType.Boolean, title: "Show saving badge", defaultValue: true },
})

Good controls use the editor's words. Each control can carry a short description shown above it, and controls that don't apply can be hidden with a hidden function. Anything that isn't a control is hard-coded, so we expose every piece of copy, price and colour a marketer might want to change.

Which jobs are good uses for custom code?

Jobs that need logic the canvas can't express, where the result still has to match the rest of the site:

• A calculator, such as a savings or quote estimate, with labels, defaults and rates in property controls.
• A pricing toggle that switches several price cards at once, with every price and label editable.
• A custom embed that wraps a booking or chat widget, so editors pick options instead of pasting code.
• API data Fetch can't handle, such as a list of open roles: Fetch doesn't support lists or large data collections, and its endpoints must be public.

Poor uses are just as easy to spot: rebuilding animations Framer already handles, hard-coding headlines marketing changes monthly, and putting repeating content in code instead of the CMS (our Framer CMS guide covers where it fits). Avoid code that reads CMS collections through Framer's internals too. Framer says this is no longer supported and calls those internals a private detail that may change at any time.

What should you watch for on speed and upkeep?

Keep each component small and test it on the published site, because that is where problems show. Framer pre-renders pages on the server, where browser-only objects such as window and document don't exist. Code that touches them during that pass triggers an optimization warning: Framer hides the component and retries in the browser, so visitors may see parts of the page missing while it loads. The fix is to use those objects inside a useEffect hook, which runs only in the browser.

Third-party scripts deserve the same care. web.dev recommends auditing them regularly, loading them with async or defer, and removing any that add no clear value. After every publish we:

1. Check the optimization status in Settings, under Domains or Versions.
2. Open the live page and watch the browser console for code errors.
3. Test each component on mobile and desktop with its longest real content.

Who owns the code once it ships?

A named person, with notes kept alongside the code. In a year nobody will remember why a calculator rounds the way it does, so for each component we record what it does, which controls it exposes, which APIs or scripts it calls and who maintains it. Framer requires React 18 compatible code, which is worth rechecking whenever a component changes.

Where to start

Write down the element you need, what it must do, who will change it and how often. If Framer's built-in tools can't cover it, our Framer development service builds code components with property controls your team can use, and documents each one. To talk through a specific request, get in touch.