Should also use Plasmic sync and not export; export is pretty experimental for now
Now I’m confused. We were already using Plasmic Sync.
So are you saying to simply use Plasmic Sync and are the plasmic dependencies the same as export?
Yes
Will do then - and look forward to Plasmic Export once its ready.
@chungwu can you say a little more about the vision for Plasmic Export and what dependencies will still remain?
I am of the opinion we should always use plasmic sync -p {YourProjectIdHere} or plasmic watch -p {YourProjectIdHere} , because these keeps the project in loop with the on going design changes you’ve made in Plasmic, i dont know where you guys dig out the plasmic export but based on the naming it suggest to me that it’s a one time export, which you cannot maintain futures updates to those components in any efficient way. plasmic sync and plasmic watch is great because it creates a parallel track that allowes 0 interferences between the design changes and the logic code added to your components.
Without this parallel tracking, every time you paste over from your newest export , your previous codes added to them are gone, gone and gone again.
I can see a scenario where I would always want my dev environment to be synced w/ Plasmic but never want my production environment to be synced w/ Plasmic
That’s right; the main difference with export is that it doesn’t have the wrapper-Plasmic* component structure so it is a one time export.
I expect it to always have some dependency on react-web because it is still using a lot of helper functions in there.
With codegen, nothing is ever dynamically synced with Plasmic. Even with Plasmic sync, you are generating code that is stable and unchanging when you use it in production. There’s no real difference with export for this use case.
This is a reference to what I imagine to have in the future; so i’m thinking that once the project gets to pre-production, then it’d get exported and if changes need to get made, they’d get made within the dev environment
sync just generates code, which you can manage with whatever git workflow you usually use for normal code in different deployment scenarios.
ya, I’m thinking the difference is that once it hits the integration/pre-production environment; there wouldn’t be any plasmic packages in my code
:rolling_on_the_floor_laughing: I’ve indeed seen super fastidious and plasmi-phobia dev teams, willing to go extra miles to remove something that doesn’t even make a difference to the user at all. Why don’t they invest the same amount of time and energy to improve the user experience and edge cases polishing instead of focusing on nitpicking npm packages, I never know, but that’s why good products are rare
@plasmicapp/react-web is essential and can’t be removed without erroring the h*ll out of your entire repo
oh ya; I think for 99% of projects, keeping the dependency in won’t be a problem I’m just curious if for the other 1% it’d be possible
is essential and can’t be removed without erroring the h*ll out of your entire repo
OK, that is good info! And totally understandable; just curious to understand the “why” behind it more
Yeah for example the customizable Select component uses code in react-web to drive its behavior
gotchya!
ok, and since you said using it as codegen its not dynamically synced; if you followed through on this methodology, it won’t make a huge difference
https://docs.plasmic.app/learn/todomvc-tutorial/#before-you-start
For us, we are taking little steps. This step is to handover of FE code to developers which currently has no logic code. Good to know that “plasmic sync and plasmic watch is great because it creates a parallel track that allows 0 interferences between the design changes and the logic code added to your components.” as this will most likely be our next step.