Overview

In #3489899: Add support for global regions we added this code

-      if (isset($hydrated[$component_instance_uuid]['props'])) {
-        $model[$component_instance_uuid] = $hydrated[$component_instance_uuid]['props'];
+      if (isset($hydrated[$component_instance_uuid])) {
+        $model[$component_instance_uuid] = $hydrated[$component_instance_uuid]['props'] ?? $hydrated[$component_instance_uuid]['settings'];

However that hard-codes knowledge of how a component source plugin maps its hydrated values to the client model

Proposed resolution

Add a new method to ComponentSourceInterface and move this logic into each of the respective plugins

User interface changes

None.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

larowlan created an issue. See original summary.

larowlan’s picture

Title: Allow source components to control how hydrated values are mapped into the clientside model » [PP-1] Allow source components to control how hydrated values are mapped into the clientside model
Status: Active » Postponed
Parent issue: » #3489899: Add support for global regions
wim leers’s picture

Title: [PP-1] Allow source components to control how hydrated values are mapped into the clientside model » [PP-1] Allow ComponentSource plugins to control how hydrated values are mapped into the UI data3467954 model
Related issues: +#3467954: META: Evolve XB UI's data model to allow non-SDC components' inputs, DynamicPropSource support, etc.

I'm sure this looks nitpicky … but I'm just trying to use consistent terms to make it easier to spot connections.

wim leers’s picture

Title: [PP-1] Allow ComponentSource plugins to control how hydrated values are mapped into the UI data3467954 model » [PP-1] Allow ComponentSource plugins to control how hydrated values are mapped into the UI data model
wim leers’s picture

Title: [PP-1] Allow ComponentSource plugins to control how hydrated values are mapped into the UI data model » Allow ComponentSource plugins to control how hydrated values are mapped into the UI data model
Status: Postponed » Active
wim leers’s picture

Issue tags: +stable blocker
wim leers’s picture

This essentially needs to be replaced with calls to ComponentSourceInterface:::hydrateComponent() … except that the wrapping self::EXPLICIT_INPUT_NAME key should be omitted.

wim leers’s picture

Title: Allow ComponentSource plugins to control how hydrated values are mapped into the UI data model » Add ::clientModelToInput() to ComponentSourceInterface, the inverse of ::inputToClientModel()
Issue summary: View changes
Priority: Normal » Major
Status: Active » Needs review
Issue tags: +blocker
Related issues: +#3493941: Maintain a per-component set of prop expressions/sources

I believe tackling this before #3493941: Maintain a per-component set of prop expressions/sources would allow that MR to remove the confusing bits in ComponentTreeHydrated.

longwave’s picture

Status: Needs review » Reviewed & tested by the community

Yep this makes sense, nice cleanup and decoupling, and I see why it's needed for the other issue.

  • wim leers committed d9b43a72 on 0.x
    Issue #3494684 by wim leers, larowlan, longwave: Add ::...
wim leers’s picture

Status: Reviewed & tested by the community » Fixed

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.