Feature: Preview API

[alaca]

Description

This PR introduces a new Preview API that is used to pass the state changes in design mode to the form inside the iframe. Preview API is a simple pub/sub system that hooks up in the form state which makes all changes in design mode show up instantly on the screen without reloading the form.

Affects

Form Builder
Donation form

Visuals

Testing Instructions

1. Create a new form
2. Enter design mode
3. Try every form customization option in the right-hand side panel
4. Verify that form settings are saved correctly by checking the form on the frontend

Pre-review Checklist

• Acceptance criteria satisfied and marked in related issue
• Relevant @unreleased tags included in DocBlocks
• Includes unit tests
• Reviewed by the designer (if follows a design)
• Self Review of code and UX completed

Plugin zip for QA: https://github.com/impress-org/givewp/suites/17790212597/artifacts/1019602715

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1205783384593885
  • https://app.asana.com/0/0/1205269709893095

[JasonTheAdams]

Just looking at the gif, @alaca, this looks amazing! Can we remove the debouncing on the text fields so the typing is instantaneous? 😃

[alaca]

@JasonTheAdams sure 😃

[jonwaldstein]

@alaca this is amazing! Just had some thoughts and suggestions. We'll also need to circle back and make sure all settings are accountable. One I noticed we still need to figure out is the custom css setting.

[jonwaldstein]

I'm so happy about this 😭, great job @alaca!

[JasonTheAdams]

@jonwaldstein @alaca What I believe is my last question: Why are we prop-drilling the form data instead of using a context?

[alaca]

@JasonTheAdams that's because the current state is divided and we use two state providers DonationFormSettingsProvider and DonationFormStateProvider, but we are not passing all the form data that comes from getWindowData to providers. The DonationFormStateProvider is a bit misleading because it doesn't include the entire form state, just gateway stuff, validation schema, etc., and DonationFormSettingsProvider does not include goal data and stats data required by the Header component. The Header component was using getWindowData before.

In other words, it was easier to do it this way 😅

[JasonTheAdams]

@alaca Hahah! Got it. I'm just a bit concerned that it's not easily available, especially for when we get into form design settings, that could apply anywhere in the node tree. Seems like we need to make sure, one way or the other, it's globally available without having to prop-drill.

Seem sensible to you, @jonwaldstein?

[jonwaldstein]

@JasonTheAdams i'm open to adding the form data object into context, but as @alaca pointed out - it's not that straight forward. This is also specific to the preview api as window data still works as expected for live rendering.

My preference would be to keep the prop drilling for now (since it's really just for the header) and update the context structure (as needed) when we actually introduce a form design api that requires it. At that time, I would explore breaking out that form data object into pieces that make more sense for the front-end application which could end up being separate context providers.

[JasonTheAdams]

I'm SO EXCITED for this!! 🤩

[rickalday]

Passed manual tests.