Loading tutorials…
Loading tutorials…
Framer's killer feature for power users: write real React, paste it in, and use it like any native component. But this is also where most Framer sites turn into maintenance nightmares. This walks the right way to set up code components.
Who this is forFramer site owners who need functionality beyond the native components — embedded pricing calculators, custom forms, interactive charts, API-driven content. Requires React knowledge or a developer on the team.
What you'll need
Step 1
Code Components are full React components. Overrides are functions that modify existing Framer components. Different use cases.
Code Component: a complete new component you build (pricing toggle, calculator, API-driven list). Imported into the canvas, draggable like native components.
Override: a function that intercepts an existing Framer component (e.g., a button) and adds logic — fetch data, conditional behavior, custom click handler.
Use Code Component when you need a NEW thing. Use Override when you need to add behavior to an EXISTING thing.
For most marketing-site use cases (forms with logic, calculators, custom embeds), Code Components are the right pick.
Step 2
Left sidebar → Components → '+' → Code. Framer opens a TypeScript file in the in-browser editor.
In the Framer project, open the Components panel (left sidebar). Click "+" → Code Component.
Name the component using PascalCase (e.g., "PricingToggle"). This becomes the component's file name and import path.
Framer scaffolds a starter TSX file with React + Framer imports already set up.
Write the component logic. Use standard React patterns — hooks, state, props. Tailwind-like className syntax doesn't work; use inline style or styled-components.
Add propertyControls at the bottom of the file. These expose props in Framer's right panel as configurable fields (text, number, color, image).
Step 3
addPropertyControls() exposes component props in Framer's right panel. Without them, the component is hard-coded.
At the bottom of your component file, add: addPropertyControls(MyComponent, { ... }).
For each prop you want editable: define type (text, number, boolean, color, image, enum), default value, and (for number) min/max range.
Example: title prop → { type: ControlType.String, defaultValue: "Default Title", title: "Heading" }.
Marketers can now edit the prop in the right panel without touching code.
Common pattern: every text/color/image in a component should be a property control. Marketing wants to A/B test copy without asking dev.
Step 4
Drag the component from the Components panel onto the canvas. Verify props render correctly at every breakpoint.
In the Components panel, your new component should appear under "Code Components."
Drag it onto a page. Resize the container — verify the component scales correctly.
In the right panel, change each property control value. Verify the component updates live.
Test on Tablet and Phone breakpoints. Code Components don't inherit Framer's breakpoint system automatically — you write responsive logic yourself.
For responsive logic: use CSS media queries inside the component (via style objects) OR use useEffect + window.innerWidth.
Step 5
For components that fetch data (CMS-like, dynamic pricing), use fetch() inside useEffect. Cache results to avoid rate limits.
Inside the component, use useState for the data, useEffect to fetch on mount.
Add a loading state — show a skeleton or spinner while fetching.
Handle errors — what happens if the API is down? Show fallback content, not a blank box.
Cache responses with localStorage or a simple in-memory cache, especially for components that render in 5+ places on the page.
CORS: if the API doesn't allow cross-origin requests from Framer's domain, route through a proxy (Cloudflare Workers, your own API gateway). Don't expose API secrets in the component code — they're visible to anyone who views source.
Step 6
Save the component. Republish the project. Test on the live site. Set up a quarterly maintenance check.
Save the component file (Framer auto-saves but explicit save = published version).
Publish the project. Code Components only go live after publish.
Open the live URL in incognito. Verify the component renders, props work, and any API calls complete.
Set a quarterly calendar reminder to test all Code Components. Framer updates its React version, browser APIs change, third-party APIs deprecate — components break silently.
Document each Code Component in a Notion doc or README: what it does, what props it takes, what APIs it calls. Future-you will thank you.
Common mistakes
No property controls
What goes wrong: Component is functional but hard-coded. Marketing has to file a dev ticket for every copy or color change. 2-week turnaround on changes that should take 2 minutes.
How to avoid: Add addPropertyControls() for every text, color, image, number that might change. Treat the component like a configurable widget.
API secrets in component code
What goes wrong: API key visible in browser source. Within weeks, scraped by bots and used to hit your account quota. Account suspended or surprise $5,000 bill.
How to avoid: Route all API calls through a backend proxy with env-var secrets. Cloudflare Workers free tier handles most marketing-site loads.
No loading or error states
What goes wrong: Component renders blank for 2-5 seconds while data loads. User sees a blank area, assumes site is broken, bounces. If API fails, blank forever.
How to avoid: useState for loading/error/data. Show skeleton or spinner during load. Show graceful fallback content on error.
Component breaks on a Framer update
What goes wrong: Framer ships an update to its React version or component API. Your code component breaks on the live site. You don't notice for 2-4 weeks until a customer reports it.
How to avoid: Quarterly check: open every page with a Code Component, verify it renders. Subscribe to Framer's changelog/release notes. Use TypeScript and react-types so breaking changes show as compile errors before they hit production.
Over-engineering — Code Component for what could be a native component
What goes wrong: Built a custom 'feature comparison table' Code Component. Marketing needs to change a row. Has to ask dev. Native Framer table with a CMS collection would have been editable by anyone.
How to avoid: Default to native Framer components. Only build Code Components when you genuinely need React capabilities (state, API, complex logic). Don't build a Code Component just because you like writing React.
Recap
Done — what's next
How to set up a Framer site end-to-end
Read the next tutorial
Hand it off
Code Components introduce real engineering surface area to your Framer site. A developer who maintains them, monitors for breakage, and ships new ones as needed typically runs $200-600/mo at $14-16/hr — far cheaper than a full-time React dev for a marketing site.
See developer rates
Yes. Framer Code Components are real React with TypeScript. If you don't know React, either learn the basics (2-3 weeks of focused practice) or hire a developer. Trying to copy-paste React from ChatGPT without understanding it is the fastest path to a broken site.
Yes. Framer supports importing from npm via ES module URLs (esm.sh, jsdelivr). Example: import { motion } from 'https://esm.sh/framer-motion'. Be cautious — each import adds KB to the page weight. Stick to small, well-maintained libraries.
Code Component = a complete new React component you build and add to the canvas. Code Override = a wrapper function that intercepts an existing Framer component and adds behavior (e.g., custom click handler on a button). Use Override when you need to add logic to a native component without rebuilding it.
Code Components render client-side (React hydration). The HTML on initial page load may not include the component's content. Google can render JavaScript, but it's slower and less reliable than server-rendered HTML. Don't put critical SEO content (headings, body copy, links) inside Code Components if you can avoid it.
Framer's Component Library feature lets you publish components to a shared library accessible across projects. Useful if you maintain 5+ Framer sites with shared patterns. Set up under Workspace settings → Component Libraries (Business plan and above).
Framer
Framer feels like Figma until you hit publish — then it suddenly behaves like a real CMS. This walks the path from empty project to a live custom domain, including the breakpoint and domain-connect steps that trip up most first-time builders.
Framer
Framer is famous for animations — and just as famous for the sites that go from 90 PageSpeed score to 30 after a marketing team gets enthusiastic with motion. This walks the animation patterns that look great AND keep your site fast.
Framer
Framer ships fast HTML out of the box. Then a marketing team adds images, animations, fonts, and pixels — and the mobile PageSpeed score collapses. This is the diagnostic sequence specialists run when a Framer site loses speed.
Framer
Framer is gorgeous and accessible — until you hit the wall where every change costs you a day. This is the honest framework: when the time cost of DIY exceeds the cost of hiring, and how to tell which side you're on.
Webflow
Webflow doesn't have a native GA4 field anymore — every install goes through Custom Code. Most DIY setups end up double-counting from the webflow.io staging subdomain or missing events from form submits. This walks the install + the filters that fix both.