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.