The design team wants you to use FramerX, now what? The missing guide for developers

Michael Katz
Jan 3, 2019 · 10 min read


I was recently asked to develop several prototyping tools for our design team, based on the new and promising FramerX platform, which enables designers to not only design a flow, but to also interact with the underlying ReactJS code which FramerX generates and consumes.

In this article, I’ll assume the reader has some understanding of Typescript, React and basic understanding of the flux architecture, concepts such as state and mutability/immutability and the problems such concepts and approaches solve.

If some of the terminology seems to be unfamiliar, I recommend going over the following resources:

Exploring ES6 Is a great reference for all that’s new with JS.

A quick overview of Typescript

An official React tutorial for beginners

A really good introduction to flux/state management

FramerXs Page linking feature


So what’s FramerX anyway?
FramerX is first and foremost a design tool made for prototyping websites and applications.

Built with a modern Front-end stack, including Yarn, React and Typescript — Framer X brings a powerful promise to address the various caveats of the design→development process.

Interactive components in FramerX are all React-based, which means you can build upon your existing React work instead of replicating it in production. Want even more control? Create custom UI for the properties panel or use our powerful library to animate with React.

If it seems like a big promise — it is.

During the past years, attempts at intertwining design with code - have been made.
Products like Microsoft’s FrontPage, Adobe Dreamweaver, Processing, Webflow and Invision Studio have all either tried or trying to solve similar problems to no avail.

Does FramerX delivers?

(concerns raised in this article pertain to FramerX v.13)

TL;DR There’s no simple answer to that.

Although it provides powerful design tools, FramerX’s approach towards the engineering aspect of the workflow lack in certain points:


Platforms like WordPress, jQuery, Sketch and Firefox have evolved and fostered thriving communities around them by introducing a powerful plugin architecture that allow interaction with different aspects of the platform.

Firefox’s Add-Ons, WordPress’s hooks and jQuery’s/Sketch’s plugin/extension architectures allowed people to change, extend and add missing features practically on demand. This created a huge traction of both early adopters and community leaders, developers and freelancers that promoted the popularity of these platforms and created new markets, jobs and professionals.

Unfortunately that is currently not the case with FramerX.

Framer’s developer approach is based on developing a React Component ecosystem and making various assumptions that fit a very small use case.
This approach uses Typescript, styled components and, Yarn without giving developers the ability to interfere with the exported code.

FramerX’s own components are completely shut off and the way the suggest to interact with then is fairly limited and based on additional assumptions (more about it in the override section).


The lack of documentation is also a major obstacle, and even though I’ve seen a fair share of examples by early adopters, they mostly stay in the scope of interaction POCs, are limited to work with and are often created by novice developers, which has its own implication on the code’s quality and readability.
This is of course a generalisation and there are exceptions.


The product is extremely CPU intensive and we’ve witnessed numerous crashes and freezes especially when you’re not using a top-of-the-line brand new MBP.


Framer’s team does its best to provide support, however their engineering resources are limited and since there’s no wide community adoption a lot of things are “brute-forced” in which is rather frustrating.

Many concerns we’ve raised with our Framer contacts have been met with a blanket “we’re working on it” response.
While we’re familiar and can sympathize with the “release quick — release often” ethos, this level of product maturity and the unclarity of its roadmap- makes it very difficult for us to rely on it in our own demanding design and development process.

IMO, By introducing an extensibility/override mechanism to their product, FramerX will be able to better elevate the power of the dev community and create an amazing tool that will be widely adopted.

If you’ve been reading this far, then it means you’ve hopped on the FramerX boat like we have, welcome — and best of luck!

I’m a developer, what’s my role in this?

Since it’s a relatively new tool, developers are needed for various integrations that require coding.
Framer’s team does their best in order to mitigate the gaps between code and design — yet the current product’s maturity level will require some technical assistance, especially when using its code importing/exporting features.

As a developer, you’ll find some of your responsibilities to be:

  • Creating FramerX controls which affect the component and override its props.
  • Building communication bridges between components.
  • Creating “logical” components that allow designers to create interactions, use libraries and extend Framers’ abilities.
  • Integrate exported code into your production app.
  • Import production code into Framer to create a truly continuous design/development process (the big promise we’re all waiting).

After covering the background, let’s shift our perspective into ‘engineering mode’ and dive right in.

Working with FramerX

This is my flow of working with FramerX as a developer. It stems from my own experience creating various FramerX components, including this one.

The two types of components

Design components
This type translates graphic elements created on the FramerX canvas to React components.
its source code is hidden inside a descriptor file called design/document.json.

Code components
This type is created from code by going to component->create from code or by pressing cmd/ctrl+shift+k.
When creating a new code component, its code will automatically open in VSCode- an open sourced code editor/IDE from Microsoft.
In case you don’t have VSCode, FramerX might prompt you to install it. You should.

Once you’ve entered your new component’s name, vscode will open with something looking like:

Framer’s code component template

This is our component’s initial template.
Inside, we can see some familiar React code, along with a static propertyControl object.

Property Controls

Property controls are standard react props, which value will be controlled via FramerX itself.

An example of a property control

As you can see, we have a text property that updates our component from FramerX, how cool is that?

Each property control is an object containing a description of its type, default values and in some cases additional properties such as min/max values for numeric inputs, allowed types for images etc.

This is a good time to go over the following primer by Framer’s team

You should feel fairly comfortable with it, before going to our next section.

Code Overrides

In many cases, we’d like to override the existing property of a component, be it because it comes from an external library, it’s a ‘black-boxed’ FramerX component or because it’s one of the ways of sharing state between components.

Framer’s code overrides are functions that return an object, which in turn is being applied as props for our component.
consider the following demo:

Although we’re passing “dog” as text — we have an override function that changes it into “Cat”.
The reason it works is because we’re intercepting the original props, using React.cloneElement and changing it to the output of our override function.

Making it closer to the actual workings of FramerX, we get something like:

An override function that accepts the overwritten component’s props where the developer can use it in order to make decisions.
A working demo can be found here.

Framer’s overrides

Framer’s approach to overrides is relatively simple as shown in the following video:

  • Select your component and preview it
  • click on the ‘code’ section
  • select either the Examples.tsx file or any of your own
  • choose an override from the dropdown or select edit <filename> in order to add your own
  • don’t forget to export the function.

A lot of native FramerX components come with various default props. By inspecting their code, you’ll be able to tell which components have which properties. Currently, this is all not well documented so it’s mostly done by reverse engineering and reading their code from the debugger console (more on that later).

Overrides are also great for event binding as it accepts all of the event related props (i.e onClick, onMouseenter, onScroll etc..).

Framer’s data model

Framer’s data model enables us to share data between components.
It’s implemented in a way that every change to the original object will cause a re-render of our components with the newly provided values.

If you look carefully at the default Example.tsx file, you’ll see it contains the following line:
const data = Data({ toggle: true, scale: Animatable(1), opacity: Animatable(1), rotation: Animatable(0), rotationY: Animatable(0) , text: “poop"})

A data object is just a reference to framer’s Data function that accepts any type of object as a parameter.

We can then use it in order to share state via overrides, or by exporting and consuming it in other components.

Communication between two components

And here’s the source code for you to enjoy:

Framer inter-component communication code

We basically done several things here:

  • Create 2 FramerX components with similar property control (“color”).
  • Update the data objects in Examples.tsx with the color property, while also exporting it.
  • Consuming the data object and mutating it directly on ComponentA's componentDidUpdate() lifecycle method.
  • Overriding ComponentB with a function that returns the color from the data object.
  • Placing both components into the same frame, as they need to run together
  • Profit.

Note: you don’t have to use overrides on this one, however it will allow more flexibility by giving designers the ability to control it without getting their hands dirty with code.

Child Components

FramerX allows us to create components that contain other components.
By rendering this.props.children as your component’s content, you’ll be able to attach external components to it.

Make a component accept children

It’s a great feature to have in general, it serves a greater purpose for us.
Remember the data part? We can create “transparent” components to accept any kind of design. These transparent components will trigger the logic needed for the “child component” update.
This will allow us to separate our data from our design.

Consider the following demo:

In here we have 3 components:

  1. A button design component
  2. A transparent component that has a property control which enables us to pick a number
  3. A component that will display the updated number after we click on the button (the video misses out on the mouse part, but when the number changes, it’s due to a click).

The way it works is that one component updates the ‘data’ store while another consumes it via an override.

  • Note: You may want to attach the click event via overrides (I didn’t get the chance to get this part in before publishing)
    The smart way would be to create various overrides for onClick/onScroll/etc.. and just attach it upon need since a lot of different interactions often give the same output.

Here’s the source code for this one:

Note the the button itself is not present here as it’s a design component — feel free to experiment and create your own!

It should be the same with 3rd parties downloaded from the store, whether they contain design or code components.


One of Framer’s main features is the debugger console.
Since not a lot of things are documented, I’ve used it in order to debug and reverse-engineer some problems I had while working towards the solution required by us.
As stated before, Framer’s odd approach of limiting the access to their code is a true pain point as their assumptions about both workflows and feature incorporation is extremely limited.

We have 2 ways of accessing the console:

  1. cmd/ctrl+i when previewing a frame
  2. Clicking on the top right hamburger menu of the preview window and clicking inspect.
Open Framer’s debugger console
Framers debugger console.

FramerX and npm

In this section, I’d like to discuss some features which will enable you to obtain a greater control of the entire project.

When a FramerX file is being saved, its extension will be set to .framerx.
This is essentially a zip file with all of the project’s data and dependencies.
When you edit a file, it extracts it to a temporary location.
You can find this location by going to file-> Show Project Folder or use the shortcut that appears under this menu.

Show FramerXs extracted project folder

By starting a terminal in that location, you’ll have access to the entire directory structure, including the project’s package.json which will enable you to npm/yarn install any dependency you need, including your own production builds.

*Note: This needs to be done and re-done on every computer that uses this file, esp. if it’s a private NPM repository.
I’ve witnessed this behaviour to be inconsistent as at times - FramerX will take care of it on its own


Although FramerX is in an early stage and I find their approach towards extensibility and engineering extremely lacking, It’s a powerful tool.

As it will become more stable, we’ll be able to achieve much more and maybe it will even become an essential part of the designer→developer collaboration.


I would like to thank both mushon and Smadar Bar Yochai for taking the time to proof-read, add comments and give ton’s of feedback which helped cleaning out the errata.

Feel free to comment and add your own insights, should you have any.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade