Web IDE: Post Release Cleanup

[shrunyan]

An assorted list of post release items to fix.

Inconsistent files response

Issue views is return all branches (dev & live) whereas stylesheets and scripts are only returning dev.

Solution These endpoints should only return files for one branch at a time, which must be specified on request

Missing Branch in URL

Issue The current app url structure is; /code/file/views/11-f2bcd4f7f4-3z1pd2 which translates into /APP/file/TYPE/ZUID. It does not account for branch information so in the future when we support branches we won't be able to load the branch for the requested ZUID

Solution Change url structure to /APP/BRANCH/TYPE/ZUID

Tracking published versions state

issue Currently we filter out the returned "live" branch files and derive that files version as the current published version. Which is a correct assumption. This is problematic due to the "Inconsistent files response" issue.

solution Change API to only returned files for requested branch. Update app Redux stores to track files by branch. This will allow resolving a ZUID out of the "live" branch store to determine it's current published version.

Stylesheet failed save loop

issue If more than one less or scss file has a compile issue you will get into failed save loop preventing any of them from being saved. This is due to the fact we run them through the compile process on save to ensure code syntax and variable references are correct.

solution Do not compile on save but only on publish. This will solve the save loop allowing users to correct invalid stylesheets which will allow them to self service on these syntax errors. While the publish compile will still confirm that correctness of the stylesheet syntax before sending the changes live.

Publishing site.css

issue Because we compile all stylesheets together into a "site.css" bundle the current action of "publishing" and individual creates an incorrect understanding. This misunderstanding is further amplified by the fact we have a "variables" feature which allows changing a styling variable in a separate area of the product which isn't reflected on the site unless a user goes to the Web IDE and publishes a stylesheet file

soution I think we need to rework this API. Instead of "publishing" a stylesheet file I think you should have to publish a bundle (e.g. site.css). There would then be these following flows.

a) User edits stylesheetA, user saves stylesheetA, user edits stylesheetB, user saves stylesheetB, user publishes bundle site.css b) User edits variableA, user saves variableA, user edits variableB, user saves variableB, user publishes bundle site.css

To support this the API https://instances-api.zesty.org/?version=latest#33c525b0-fcf3-440f-a587-c96fac5756e9 would be changed to /web/stylesheets/compile/site.css?purge_cache=true

[ardeay]

With style variables, on save, it would be ideal to trigger a re-transpile in both dev and live (with a purge). Alternatively, the UI can trigger a re-publish of an already published file? @shrunyan what are your thoughts?

[shrunyan]

With style variables, on save, it would be ideal to trigger a re-transpile in both dev and live (with a purge). Alternatively, the UI can trigger a re-publish of an already published file? @shrunyan what are your thoughts?

See the notes on "Publishing site.css"

What I'm imagining is that for variables and individual stylesheet files "publish" goes away. Instead you would "save" variables and stylesheets. Then explicitly "publish" the site.css bundle. We would add a button for publishing site.css to the variables interface to make that action possible there as well.

I think this will allow for the benefits of previewing changes along with customers being able to "publish" changes from both the /settings/variables and /code applications.

This type of flow would also align the experience to more accurately reflect what's a happening on the back-end.

[kakoga]

related issue in Monday - Less vars do not update live site on save: https://zestyio.monday.com/boards/107983738/pulses/158906441