Save page data form values in application state with support for undo/redo

balintbrews → credited bnjmnm → .

I discussed next steps with @bnjmnm on a call last week. We agreed on the followings:

1. We will make use of FormStateContext implemented by @/components/form/components/Form to provide the information of what form is being rendered: currently this will mean the component props form or page data form.
2. InputBehaviors can make use of this information and return different higher-order components (or the same with different props) to adjust the behaviors according to the form's needs.
3. We will not change how the Twig to JSX mapping is done, so reverting my previous commits, twig-to-jsx-component-map.js will stay unchanged.
4. All mapped components will be split into two (or more) components, where a component with its name prefixed with Drupal will render another component (or components) which are purely presentational. The Drupal-prefixed component will wrap the component(s) it renders in InputBehaviors. This is what I already started in 1631cd12. The separation will help with our Storybook implementation, implementing designs in isolation etc.

Here is a high-level overview of what InputBehavior does today. Validation and store update are the two areas where we need to allow different logic for each form. They're currently implemented for component props.

Just flagging that this might also need to update the preview API rtk mutation to also include the form data, and then we'll need corresponding updates to the auto-save controller on the backend.
I did see somewhere that we were talking about setting props on the root to cover the entity form data, so that would bypass any FE changes to the preview API and only require BE changes.

Good callout! It's out of scope for this issue, but I'm definitely keeping an eye on 📌 Save metadata(page data) field with the entity revision Active to make saving easier — maybe quite soon.

@jessebaker wisely suggested that I consider extracting a piece of this work into a separate issue, and it made a lot of sense to do so for #4.4 ✨ Save page data form values in application state with support for undo/redo Active : 📌 Split form components into `Drupal`-prefixed behavioral wrappers and presentational components Needs work .

It's nice to wrap up that piece, and it will make the review of this issue much easier. 😌

Draft code is up showing the idea:

1. InputBehaviors wraps the input in one of InputBehaviorsComponentPropsForm or InputBehaviorsEntityForm. (We can also add a fallback later.)
2. These wrappers both wrap the input in InputBehaviorsCommon which essentially does what InputBehaviors did before, but using the following callbacks it receives as props:
   • commitFormState;
   • parseNewValue;
   • validateNewValue — with an optional setInputMessages argument.

This new approach already works and does everything it did before for the component props form.

Undo/redo isn't working yet for the page data form. I need a way to initially get the entire entity data, so I can put it in the Redux store all at once instead of saving each input one by one, which would pollute the history for undo/redo. I chatted about this with @larowlan, I'll return that data in the response of \Drupal\experience_builder\Controller\ApiLayoutController for now, and save it to the appropriate slice in onquerystarted.

@bnjmnm is kind enough to take over for the rest of this week as I'll be mostly on holiday until early January.

Here is what's left:

1. Reroll to incorporate changes from 📌 Move form state into the global store Active ;
2. Sending page data to backend;
3. Test coverage;
4. Code clean-up.

Follow-up issues opened:

• 📌 [PP-1] Handle media image fields on page data form Postponed ;
• 📌 [PP-1] Handle fields with multiple form control elements on the page data form Postponed .

larowlan → changed the visibility of the branch 3487484-page-data-form-redux-mid-merge to hidden.

I think this is ready for review now

It looks like this introduces some changes to Checkbox and Radio elements within the context forms. Are these purely behind-the-scenes changes that result in the same experience, or is there new or altered functionality? If it's the latter, there should probably be tests to ensure the functionality does not regress. Due to the size of this MR and its ability to make rebases painful, I think it would be fine to take care of those tests in other issues as long as those issues are properly prioritized.

Re: #13 ✨ Save page data form values in application state with support for undo/redo Active

Very good catch! Those are introducing new functionality — only used by the page data form for now. They are not covered in prop-types.cy.js, because no prop type is using those elements. I'll create the issue to write tests.

I approved this, but with the assumption that the thread with my final bit of feedback about moving shouldSkipJsonValidation is addressed.

effulgentsia → credited hooroomoo → .

This looks great. @hooroomoo also reviewed this MR, so crediting them.

I tried to merge this to 0.x, but looks like it needs manual conflict resolution with recent 0.x commits.

Thanks, everyone, for the great reviews, the collaboration, and the patience with this issue! 💫

FYI: Posthumous review of this MR posted, and summarized at #3495752-19: Send page data to Drupal for storage in auto-save store → .