feat: check if changes have been made before publishing a new flow

[sarahscott]

The Problem

Currently, we flatten and publish flows every time a user clicks the Publish button. While this accomplishes our goal of allowing content to be manipulated and refined before it goes out to the public, it means we might be saving a lot of unnecessary data. Ideally, we can work toward something resembling version control.

Approaches

1. Client-side diffing
   • Pros
     • Adds ability to disable Publish button when there aren't any new changes
     • Allows for more user feedback in the editor to indicate which changes have been made (i.e. similar to how we have a green border to track the steps of a flow in the preview browser, we could highlight changed nodes)
   • Cons
     • Potentially expensive for client browsers (only affects editors though; not general public)
     • Would need to make sure we avoid inconsistencies between our database and what is happening client-side
2. Server-side diffing
   • Pros
     • Already implemented here 😄 (needs tests)
     • Easy
     • Heavier computation happens in the cloud instead of on our (& our colleagues') computers
     • Can diff server-side and send result back to client
   • Cons
     • Not as many interesting UX options for the editor
     • Moves us slightly away from the "programming language" model wherein PlanX is mostly contained client-side

Scope of this PR

• Implement jsondiffpatch server-side
• Add mocked JWT to jest tests
• Tests

Future

• Actually do something UI-side with altered nodes (e.g. highlight)

[netlify]

✔️ Storybook

🔨 Explore the source changes: 1399125

🔍 Inspect the deploy log: https://app.netlify.com/sites/planx-storybook/deploys/6116ae760e321e0007f9751d

😎 Browse the preview: https://deploy-preview-574--planx-storybook.netlify.app

[github-actions]

🚀 Deployed on https://6116af020825562a5fce8ff8--planx-new.netlify.app

[gunar]

The question from today's call was: does this take into account portals? and if then, the published portals or the in-progress ones?

[sarahscott]

Re: portals - I haven't changed anything about how the /publish endpoint deals with them -- they should be taken into account because the diff happens on "flattened" flows.

[johnrees]

Looks good to me!! I ran it locally and everything worked great. I haven't tested it against of the huge flows yet but we can try that out in staging. Thanks!

[jessicamcinchak]

this looks good!! appreciate the description with pros & cons you were thinking through and TESTS 🙌

[johnrees]

Do not publish flows when there are no changes