Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Embeddable Rebuild] [Controls] Fix control state on edit #188784

Conversation

Heenawter
Copy link
Contributor

@Heenawter Heenawter commented Jul 19, 2024

Summary

This PR fixes control editing so that, when the control type is changed, extra state from the old type gets removed. Prior to this, controls were keeping unrelated state - for example, switching from a range slider to a search control would result in a search control with the "step" property.

Checklist

For maintainers

@Heenawter Heenawter added Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas loe:small Small Level of Effort release_note:skip Skip the PR/issue when compiling release notes impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. Project:Controls project:embeddableRebuild labels Jul 19, 2024
@Heenawter Heenawter self-assigned this Jul 19, 2024
@Heenawter
Copy link
Contributor Author

/ci

@Heenawter Heenawter marked this pull request as ready for review July 19, 2024 22:15
@Heenawter Heenawter requested a review from a team as a code owner July 19, 2024 22:15
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-presentation (Team:Presentation)

@nreese
Copy link
Contributor

nreese commented Jul 22, 2024

I don't think this issue is a bug or that that this issue needs to be resolved. The serializeState methods for the control types do not propagate keys from other control types. I think its ok for runtime state to maybe contain keys from other control types. A control type's buildControl method will just ignore unknown keys. Then on serialize, only state for the control type is persisted and clean-up is done in a single location. This has the added benefit of keeping all state around for the entire user session, so that users can change control types freely and never loose information.

@Heenawter
Copy link
Contributor Author

Heenawter commented Jul 22, 2024

@nreese Hmm... I am personally not a huge fan of having dirty state sticking around. This feels like a bigger risk of bugs to me than the current picking I am doing... For example, what if we have two control types that have some state that shares a name? It's also a change in behaviour from the way controls used to work - should they really remember state like this? But I understand that this is up for debate, so I guess I'm fine removing this.

I will have to keep the change in examples/controls_example/public/react_controls/data_controls/initialize_data_control.tsx (this was a legit bug because we are just sending in the initial control state with a new type, which causes an error to be thrown when switching from a search control to a range slider for example because the field renames a string type).

image

@Heenawter
Copy link
Contributor Author

Heenawter commented Jul 22, 2024

@nreese I removed the state cleaning in bb5cfb6 👍

@Heenawter Heenawter force-pushed the embeddableRebuild_controls_fix-editing_2024-07-19 branch from 49b0f18 to bb5cfb6 Compare July 22, 2024 18:52
@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Metrics [docs]

✅ unchanged

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @Heenawter

Copy link
Contributor

@nreese nreese left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
code review, tested in chrome

@Heenawter Heenawter merged commit 457f08b into elastic:main Jul 23, 2024
19 checks passed
@Heenawter Heenawter deleted the embeddableRebuild_controls_fix-editing_2024-07-19 branch July 23, 2024 14:05
@kibanamachine kibanamachine added v8.16.0 backport:skip This commit does not require backporting labels Jul 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. loe:small Small Level of Effort Project:Controls project:embeddableRebuild release_note:skip Skip the PR/issue when compiling release notes Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v8.16.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants