Evolve the organically grown `::getClientSideInfo()` into something cohesive

return [ 'source' => (string) $this->getSourceLabel(), 'build' => $this->renderComponent([self::EXPLICIT_INPUT_NAME => $default_props_for_default_markup], $component->uuid(), FALSE), // Additional data only needed for SDCs. // @todo UI does not use any other metadata - should `slots` move to top level? 'metadata' => ['slots' => $this->getSlotDefinitions()], 'field_data' => $field_data, 'dynamic_prop_source_candidates' => $dynamic_prop_source_candidates, 'transforms' => $transforms, ];

Comments & Activities

Issue created by @wim leers
Comment 18 days ago →
🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
Comment 18 days ago →
🇬🇧United Kingdom longwave UK
Also I think we call this in one or two places and throw away most of the data it generates.. maybe consider splitting it up into methods for the individual parts if that seems viable.
Comment 17 days ago →
🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
#3++ — but here I'm trying to approach it from the other end: what information does the client actually need and what should it be shaped like?
Comment 12 days ago →
🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
BTW, now that 📌 Expand `::getClientSideInfo()` test to all ComponentSource plugins Active is in, writing test coverage for this has become zero effort — all we need to do is update the existing expectations 👍

(Also: 📌 [PP-1] Rename PropSourceComponent.field_data to propSources Postponed is already in! 👍)

Evolve the organically grown `::getClientSideInfo()` into something cohesive

Overview

Proposed resolution

User interface changes

Comments & Activities