In #3537595: AI should use only necessary history/comments for each task, it is observed that that the fix to alter the default values before the component is added propSource.default_values.resolved = value; is not an optimal solution - it can have issues with things like undo and preview behavior and needs to have custom logic for every possible prop shape despite that logic already existing in ourcodebase.
See- https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...
Create a means of doing the following in a non-convoluted manner
addNewComponentToLayout will now accept an optional withValues in the payload so the newly added component will add it with those values. It will also be aware of the current selection and use that to determine where the component is placed. Internal uses of addNewComponentToLayout are changed to use _addNewComponentToLayout which adds a component based on the "drop" positionupdateExistingComponentValues action that will update the values of a given component in redux and ensure the form updates as well.
Show commandsStart 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:
changes
Comments
Comment #2
wim leersI believe you meant to use this issue queue component?
Comment #3
narendrar100% @wim leers, Thanks. 🙏
Comment #4
tim.plunkett@wim leers That's my fault, thanks for fixing it!
Comment #8
bnjmnmComment #9
bnjmnmMR 3538576-stage-1-split-input-behaviors makes no functionality changes - it's just splitting inputBehaviors so the form-specific parts are in dedicated files. It should make the next step easier to review, so perhaps that can get in quickly and we'll focus on the next functionality-impacting MR.
Comment #11
bnjmnmGot a +1 from @hooroomoo to merge the
3538576-stage-1-split-input-behaviorsbranch. With that in, the MR that actually implements the requested functionality should be easier to review. (it will definitely be easier to implement)Comment #15
bnjmnmaddNewComponentToLayoutwas updated to address the use case that led to this issue being filed. This makes it relatively easy to programatically add new components with custom values.This still needs a way to update the values of existing components - which is on the way...
Comment #16
wim leersQuestion: this sounds like it's the start of a formal API, so we probably also want explicit docs, rather than the docs-by-example approach originally taken in #3485692: Create extendibility proof of concept that also serves as documentation-by-example (extensions)?
Comment #17
bnjmnmComment #18
bnjmnmI've updated the issue summary to make it clear this is more of a feature request.
Re #16 The term Formalize in the issue title is misleading. There's a need to support the specific functionality mentioned in the IS asap, but we agreed at standup (@balintbrews in particular) that this should not be mistaken for formalization, which is something that should be tackled far more holistically. There was a preference that this remain informal.
Comment #21
hooroomooComment #22
wim leersPer @bnjmnm, this needs review.
Comment #23
hooroomooComment #25
hooroomoo