How to Format Your Framer Modules
Basic guidelines for clean, consistent development.
For the sake of our own Framer module development, we authored this style guide as a reference for ourselves. We offer it here as a talking point for the Framer community at large. Most of these guidelines may seem like common sense, though it’s helpful to have them in writing. Perhaps one or two points will be new to you. Please feel free to provide feedback, either here or on the GitHub Gist Version.
If you’re just beginning to write your own Framer modules, check out our article on Developing a Framer Module instead. You can concern yourself with module style after you have a couple under your belt.
Capitalization
Framer employs lowerCamelCase
for almost everything: functions, variables properties, etc. Classes, however, use TitleCase
. Events are a bit of a special case, as explained under Events.
Constructors
Users are accustomed to instantiating objects with constructor syntax, so try to follow this approach when building your own classes.
Properties
Instance properties should be written as adjectives or nouns. myClass.hidden
or myClass.titleFontWeight
.
Functions
Represent functions as meaningful verb phrases: updateLayout()
.
Prototype Functions
For purposes of memory optimization, try to design class functions as prototype functions, so they are not recreated for each instance.
Prototype functions are included in the class
definition but not in the constructor, and use a colon in place of an equals sign.
Other Functions
Utility functions you intend to expose to the user outside of a class will tend to live on the exports
object but should follow the same capitalization and wording guidelines.
Named Parameters
If your function takes more than two parameters, or if the user is likely to confuse their order, consider using named parameters.
Events
When an operation begins or ends, it can be helpful to emit an event so the user can chain other operations to it. Generally, only layers emit events. The emit
statement is very simple:
Event names are lowercase
, but TitleCase
when referenced as properties of the global Events
variable (scroll.on Events.ScrollStart
). Event shortcuts (scroll.onScrollStart
) use lowerCamelCase
.
If you want to support all these methods, you might extend Layer
and Events
like so:
However, this is potentially risky; you might overwrite an existing Event property. It is sufficient to provide the emitter, in lowercase
.
Events are present tense verbs. Supply start
and end
event points as a pair or don't include start
in the event name.
Layers
If your module generates layers, make sure each layer has a name to display in the Framer Studio sidebar. Arrange layers in a sensible hierarchy.
For any layer you’d like the user to be able to reference directly, provide a means to do this via dot syntax.
Within the module, this is done by storing layers as properties of their parents.
Readme
Readmes can vary, but we try to make sure every module’s readme includes the following:
- License, contributing, and maintenance shields
- Module name
- Brief description
- Installation (npm, manual, via Framer Modules app)
- Adding it to your project (the
require
statement) - API/How to Use
- Example project
- Known issues, if applicable
- Footer (Web, GitHub, Twitter, Medium)
Self-Documentation
It’s also good to include the following in the module’s header comment:
- Adding it to your project (the
require
statement) - API/How to Use
- Known issues, if applicable
Again, your feedback on these guidelines is welcome. If you’d like a starting point that can set you on the right track, check out our Framer module boilerplate.
Black Pixel is a creative digital products agency. Subscribe to BPXL Craft and follow us on Twitter.