Best practices for shared libraries and app hosts

You can share a common app host and a common set of imported Plasmic project across multiple Plasmic projects, both inside and outside your organization. This is especially useful if you want to provide a common set of building blocks for content creators to use.

There are a few best practices and considerations to be aware of to make most effective use of this capability in teams that are deploying such shared dependencies at scale.

First, it’s important to distinguish between shared/imported Plasmic projects and application hosts. When creating your own curated set of components, most of what you’ll create is code components, since this is what allows you to have very fine control over props that behave dynamically, are conditionally hidden, etc. Components created in Plasmic do not have these capabilities (yet!).

Hence, you will often want to also have a common application host. When creating a new Plasmic project, the only thing to do here is to set its app host URL to the same value. From that point on, updates to code components that you deploy to the application host will be immediately visible to the consuming projects.

You should always keep your components as backward compatible as possible—this applies to both Plasmic components as well as code components. For instance, renaming props, deleting props, changing types, etc is something that you should try to avoid. Treat your published code components as you would any internal code library in your organization. Downstream projects will receive prompts that they should accept new prop changes, or to delete all instances of a component that got deleted. If you need to release breaking changes, consider creating a new separate component that contains your second version, and making the first one deprecated.

In addition to the application host, you may also want to share a central Plasmic project containing components, images / icons, style tokens, and more, which were authored in Plasmic. When you make changes to this central set of components, downstream projects will receive prompts to update to the latest versions, which they can do on their own schedule—this is different to how app hosts work (which are always immediately visible as soon as you load the project).

One advantage to creating components in Plasmic is that your content creators have the option to fork and customize these components.

Some related notes for content creator mode—see also the full docs:

• By default it disables all style controls, but you can override this and enable certain style controls, such as letting content creators set sizing and spacing.
• You can mark certain components as editable. (By default, nothing is editable.)
• You can mark certain components as not-insertable. (By default, everything is insertable.)

Have feedback on this page? Let us know on our forum.