Code component development workflow

Evolving code components over time

You can continue updating the code for your code components, and Plasmic will always use whatever is made available on the app host page.

However, occasionally, you want to evolve the metadata for your code components — its name and its props. To do so, you should make the updates to your registerComponent() call, deploy your update to your app host URL, and then reload the Plasmic project using that app host; Plasmic will then read the new metadata, and update accordingly.

There are a few caveats to be aware of as you make your updates:

Renaming components

When you change the name from A to B, the next time you open a project containing instances of A, Plasmic Studio will notice there’s no registration for component A, and will ask if you renamed it to another component — in which case, you should choose B. Plasmic will then fix up all instances accordingly.

Changing props

Changing the type of a prop will prompt you to confirm removing usages of the old prop. Note that this removes all existing arguments/values passed into that prop.

Changing the type or name of a prop in a way that carries over all old values passed in for that prop is not yet supported. Tell us if that’s something you’d like to see.

Adding new components and props

Since these are non-destructive changes, these will immediately take effect in the project without further user interaction.

Deleting components

If you deleted a component, Plasmic Studio will prompt if you meant to remove all instances of the component.

Workflow for production vs development

When first setting up app hosting, you initially set your Plasmic project to use a host URL like http://localhost:3000/plasmic-host.

After deploying to production, you typically change this to a URL that anyone can access, such as

But what happens when you want to update/create new code components and test them out?

A simple workflow we recommend is:

  1. Make a temporary (throw-away) clone of your main Plasmic project, setting its host URL once again to http://localhost:3000/plasmic-host.
  2. Make your code component changes and test them out in this project.
  3. Once you’re happy with your changes, deploy them to the production app host. The updates will then be available for use in the original Plasmic project.

(In the future, we may formalize this workflow in the UI, but it will largely be the same under the hood.)

For a more thorough deep-dive into what the workflow looks like across multiple environments (including localhost, production, and others such as staging), see our guide to managing multiple environments.

But can I merge my changes on the development copy of the project back into main copy?

This is a common question. However, we recommend approaching development of Plasmic code components with the same general software engineering practices and collaboration hygiene as you would with any other development project:

Do not do this.

To draw an analogy that isn’t related to Plasmic: say you are working on a database-backed application. Your own local development environment has its own copy of the database. As you are updating the codebase, you are also testing out these changes and making updates to the database.

In many environments, the local database is always completely disconnected from the prodcution database, and no syncing happens between them. In some environments, it is standard practice to clone the production database (or parts thereof, or an anonymized copy of the data) into your local database. However, you typically do not copy changes from your local development database back into the production database.

In the same vein, by making a temporary local development copy of your project, this is analogous to cloning a production database into your local database. This much is OK, but you generally should not attempt to copy or merge your local database back into the production database.

Was this page helpful?

Give feedback on this page