Overview
Unlike for the block component source plugin (see #3524399: `BlockComponent::validateComponentInput()` allows garbage to pile up), no garbage values are AFAICT allowed for the sdc and js component sources.
This is thanks to GeneratedFieldExplicitInputUxComponentSourceBase::validateComponentInput() calling
$this->componentValidator->validateProps($resolvedInputValues, $this->getSdcPlugin());
which would complain about unused props.
… or so I think 😅 Nope: see @akhil babu's research in #5.
Proposed resolution
Add test coverage to prove that the SDC + JS component sources are unaffected. → disproven by @akhil babu in #5.
- Test coverage: a new
GeneratedFieldExplicitInputUxComponentSourceBase::testValidateComponentInput(), that tests garbage values being set for thesdc.xb_test_sdc.props-slotsSDC. - Fix
GeneratedFieldExplicitInputUxComponentSourceBase::validateComponentInput().
User interface changes
None.
Issue fork canvas-3524401
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:
Issue fork experience_builder-3524401
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
Comment #2
wim leersComment #3
akhil babuCould you please give an example for 'garbage value'?
Comment #4
wim leersAn SDC with the following in its
*.component.yml:… yet the explicit input it receives is not
but
IOW: some key-value pairs that are not expected by the SDC!
Comment #5
akhil babuThanks @wim leers🙏. I just tested this using the 'Heading' SDC, by adding an extra property 'textUnwanted' when making a curl request to the endpoint
/xb/api/v0/layout/xb_page/5and the changes were successfully saved. There were no validation errors regarding the unexpected propJust to confirm, does this mean
validateComponentInput()currently allows unexpected properties (i.e., garbage values) for SDCs?Comment #6
wim leersIndeed it does 😭
Matching the title of #3524399: `BlockComponent::validateComponentInput()` allows garbage to pile up then. 😭
Updated issue summary with an adjusted proposed resolution.
Credited you for the valuable research you've already done here, @akhil babu! 🙏
Comment #8
akhil babuThanks @wim leers. I have updated
GeneratedFieldExplicitInputUxComponentSourceBase::validateComponentInput()and added a check for unexpected props.However, no exception was thrown for the curl request mentioned in #5, and the heading component was still added to the canvas. The expected error only appeared when publishing the page
Shouldn't the error have been thrown at the time of the request?
I also tried to validate 'missing' props but that resulted in many test failures as some props are not always part of user input (Like 'attribute' prop in sdc.experience_builder.my-hero component)
Comment #9
wim leersComment #10
lauriiiComment #15
larowlanUpdated the MR based on my review - but I'm wondering if we should just do GC on those properties in
\Drupal\canvas\ComponentSource\ComponentSourceInterface::clientModelToInputinstead rather than raise an Exception?Comment #16
wim leersNice progress!
!424 looks great, but incomplete?
!1039 can be closed as a duplicate of !424?
Comment #17
penyaskitoAdded suggestions for expanding missing test coverage.
Comment #18
attilatilman commentedComment #20
penyaskitoLooks good to me. The missing test coverage was already there ¿? Guess I overlooked it.
Fixed some logic for this to be reused by any other component source extending
GeneratedFieldExplicitInputUxComponentSourceBase, even in contrib.Comment #23
mglamanComment #25
wim leersNice to see this in! 👏
Next: the same for its sibling issue for the other component source that Canvas ships with: #3524399: `BlockComponent::validateComponentInput()` allows garbage to pile up.
Comment #26
wim leers