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.

As with all API changes, you should minimize these changes and try to maintain backward compatibility as much as possible!

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.

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 https://my-app.com/plasmic-host.

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 production database, and no syncing happens between them. In some environments, it is a 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.

Similarly, by making a temporary local development copy of your project data, 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.

Is there a quick and dirty way I can temporarily override the host URL on a project?

Warning: you may irrevocably mess up your production project, and have those changes to go to production without warning if someone publishes at the same time.

If you are sure that your code component changes will not be disruptive to the other collaborators who are editing your production project (i.e. the schema is not changing), you can temporarily override the host URL by appending the hostUrl flag to your project URL, like so:

Copy
https://studio.plasmic.app/projects/XXX?...&hostUrl=http://localhost:3003/plasmic-host
Was this page helpful?

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