Code component development workflow
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:
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 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.
Since these are non-destructive changes, these will immediately take effect in the project without further user interaction.
If you deleted a component, Plasmic Studio will prompt if you meant to remove all instances of the component.
When first setting up app hosting, you initially set your Plasmic project to use a host URL like
After deploying to production, you typically change this to a URL that anyone can access,
But what happens when you want to update/create new code components and test them out?
A simple workflow we recommend is:
- Make a temporary (throw-away) clone of your main Plasmic project, setting its host URL once again to
- Make your code component changes and test them out in this project.
- 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.