Contrib.social

Replace the postPreview action with atomic equivalents

Open on Drupal.org →
Created on 5 December 2024, 4 months ago

Overview

In 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active we introduce a PreviewEnvelope controller result.
Returning this allows combining a preview render array with a JSON data object and still invoking the preview renderer to combine the render array and the rest of the page elements into a HTML property in a JSON response.

It also adds a slice to hold the current preview HTML and introduces a patchComponent action that fires when a component's props are updated. This calls a backend controller that update only the component being edited in the auto-save store. This means component edits work concurrently.

However, we still call postPreview for many other changes to the layout slice and these overwrite any other changes being made by a concurrent editor

Proposed resolution

After 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active and 📌 Include the preview HTML in the layout controller payload Active are in, we no longer need to call postPreview to get the initial preview HTML. So from this point we can move to atomic operations against the auto-save rather than a 'write the full layout and model every time' approach.

This allows us to:

Remove the postPreview api from the front-end
Introduce a patchModelAndLayout api method
Add a listener middleware to the store that listens for the following actions:

  • deleteNode
  • duplicateNode
  • moveNode
  • shiftNode
  • sortNode
  • insertNodes

For each of these:

  • dispatch the patchModelAndLayout api with the action's payload
  • Rewrite the preview controller in Drupal to respond to this payload and mirror that operation in the auto-save entry for the given entity.
  • Add a onQueryStarted method for patchModelAndLayout that unwraps the preview html and calls dispatch to set the new HTML

e.g. if a user duplicates a node in the UI the workflow should be

  1. duplicateNode reducer called
  2. listener middleware reacts to duplicateNode action and fires patchModelAndLayout
  3. Drupal controller receives PATCH request for duplicateNode and applies the same logic to its representation of the model/layout as the front end, writing just those changes to the autosave store
  4. Drupal controller response with HTML
  5. onQueryStarted method of patchModelAndLayout action stores the new HTML

User interface changes

📌 Task
Status

Active

Version

0.0

Component

Page builder

Created by

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024