Contrib.social

[META] Robust component instance error handling

Open on Drupal.org →
Created on 8 April 2025, 11 days ago

Functional Requirements

  1. Provide clear, user-friendly error messages
  2. Display actionable resolution steps for each error
  3. Offer retry and undo action to resolve the error when possible
  4. Provide component-level error handling so one component error doesn't break the entire page
  5. Log errors for developers to troubleshoot, for client side and PHP logic errors.

Non-Functional Requirements or Constraints

  1. Must avoid leaking sensitive internal error information to non-developers.
  2. If a component instance with a slot fails to render (due to logic error or invalid input), it’s possible that the slots won’t render either, hence obscuring a subset of the component tree. These should remain visible in the “Layers” view.

Out of Scope

Acceptance Criteria

  1. A (whose ) used as a component instance in an XB component tree does NOT make the rest of the component tree unusable.
  2. An (whose

Proposed resolution

(Numbered lists must happen one after the other, bulleted lists can happen in parallel.)

  1. Fallback markup for server side-rendered components (SDC + block plugins), plus tests, plus logging, plus structured information about all component instances that failed to render and why: Assigned to: larowlan 📌 Improve server-side error handling Active
    👆 This implements an (ugly) catch-all to at least avoid the hard, fatal failures → . It unblocks the next stage.
  2. Render the structured information in the XB HTTP API response on the client using Radix UI Toasts. Must include test that verifies it works for 10 "broken" component instances.
  3. Designs
    1. in-preview affordances: what does the fallback look like inside the preview? Does it look different when we know it causes slots (and their contents) to not render?
    2. on-top-of-preview affordances: How do we inform the user on top of the preview, while editing? Because there could be MANY errors.
      Using a so-called “toast” UI component was suggested by @lauriii , but what should those look like? XB uses Radix UI, so is the Radix UI Toast sufficient?
    3. live site affordances: what should the fallback look like outside the preview, i.e. on the live site?
      (This can occur if everything was valid at the time of saving, but the component logic changed during a deployment.)
    4. Retry: what does retry functionality look like for the first two? Does it appear on both, or on either? Why?
  4. Implement designs.
    1. Refine the messages in the structured information
    2. … designs will determine what needs to change compared to the naïve situation above
    3. Fallback markup for client side-rendered components (code components), which we can then do "right" the first time. (We used the server side ones in phase 1 to help ground the designers.)
  6. Docs
    • Docs added to docs/components.md, one per component source: each should get a new subsection titled .
    • Docs added to docs/data.model, section 3.3 Data Model: rendering a stored `component tree`.

User interface changes

🌱 Plan
Status

Active

Version

0.0

Component

Page builder

Created by

🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

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