This is an intricate surgery as you’d expect… I would do it this way (make sure to make a back up before you start!)
The current project will be called the “core” project
Make a duplicate copy of this project. This will be the… “pages” project (just an example; you can split it however you want).
Delete stuff from the “core” project that should belong in the “pages” project. should be the easy part! Publish once you’re done.
Let “pages” import from “core”
Now the hard part is, in the “pages” project, you want to “swap” local component references to referencing from the imported component from the “core” project. (For example, Button is in “core”, and you want to swap all Button in “pages” to use Button from “core”, and then delete the Button component from “core”).
a. From the Components tab on the left, you can right click a component, and select “Swap all instances with another component”. So you right-click on your local Button, and choose to swap all instances with the imported Button
b. The tricky part with this is to do it from the “lowest component” up. So you may have component A that uses component B that uses component C, and they should all belong in “core”. So you need to make sure you first swap out C, and then B, and then A. Figuring out this tree will be… a bit tricky
@chungwu Thanks for the detailed strategy for migration. The 5th point is really helpful considering the fact that we opt for duplicating the existing project.
We are aiming to create a separate project (dashboard) apart from core and move certain functionality to the dashboard project. Which means we will implement new features and rewrite some code from core to dashboard by importing design components from core project as you mentioned.
So, I assume the issue for local references won’t exists as it’s a completely new project and not the copy of the core.
@chungwu@yang@quarrelsome_wren@zonal_mammal We see different behaviors on Mac/PC, depending on the processor and the amount of RAM. We have a project where loading all custom arenas (full screen) on an Intel Lenovo Thinkpad (16GB of RAM) brings Chrome up to 8 GB. The same project will crash a MacBook M1 (8GB of RAM) as soon as Chrome hits 7GB. The same project will work correctly on an Intel-based Mac (40GB of RAM), though Chrome will continue to unload the least recent custom arenas and won’t allow Plasmic to use more than 4GB under any circumstance (which defeats the purpose of using a larger amount of RAM). Any idea whether these different behaviors are driven by Chrome (PC, Mac) or Plasmic? Thx for any thoughts!
Hmmmm…maybe a native desktop application? Kinda like figma? I’m assuming that most professionals using Plasmic won’t be using 8GB of ram. They will be in the 16+ camp. However, if Chrome tops Plasmic out at 4GB—then a large project on any machine will face the same problem, which I imagine would only get worse with collaboration in the future. My uneducated and unsophisticated assumption is that a native desktop application might bring some parity to all machines with a marginal boost in memory if you’re containing your own app and using memory directly from the hardware. This was just the first thing that popped into my head…but I will test a few things with Asim and friends and see if we can’t come up with an simpler solution/suggestion
@easy_jellyfish Can you please share an approx number for the arenas and components in your project?
Also, are you using any custom code components?
Our project consumed to 2.1GB at first having around 8 arenas with 6 to 7 Artboards per arena. I tried to split it by having 2 Artboards per arena and it drops the memory usage to 1.7GB. (~400MB reduction)
I downloaded Microsoft Edge for Mac, and the Studio only crashed one time today. With Chrome, it has become almost unusable, crashing every few minutes.
I’m sorry, I know it’s painful to work with large projects in Plasmic right now Chrome does seem to shut things down at around 4GB of RAM for v8, and there’s not much we can do about it except to cut down our memory usage, which is a large undertaking (and won’t be done in time to alleviate your pain here).
We’re still looking into quick ways to ease your pain here, but for now, my short-term recommendations are:
• We currently keep 6 “arenas” in memory, to try to preserve memory use; you can fiddle with this number by adding ?liveArenas=3 etc into the url.
• Firefox does allows more memory to be used, and you may have better luck there. We don’t test in Firefox at the moment though, so I’m not sure if the experience would be great.
• Use custom arenas instead of the page / component arenas if you have lots of screen sizes and variants. Those open up a lot of artboards, and each artboard takes up some amount of memory (each is an iframe containing its own full React tree etc). With custom arenas, you have more control over exactly which artboards you have open, and you can switch between different variants using the same artboard.
• Split up your project into smaller chunks. A large source of memory use comes from our instrumentation of data models so we know when they have been updated (to send incremental patch sets to be saved, and also to incrementally re-render the artboards). This instrumentation does not apply to imported components, so breaking a project up would help in the amount of instrumentation we have to do. I know this is a painful process though; let us know how we can help.
Do you mean an existing artboard from a component or page arena? No… you’ll have to create it from scratch for now From a custom arena, right-click on a component, and select “Edit in new artboard”.
