-
Notifications
You must be signed in to change notification settings - Fork 8.6k
[lens] Allow updater function to be used for updating state #43373
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
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -63,6 +63,8 @@ export interface DatasourceMetaData { | |
| filterableIndexPatterns: Array<{ id: string; title: string }>; | ||
| } | ||
|
|
||
| export type StateSetter<T> = (newState: T | ((prevState: T) => T)) => void; | ||
|
|
||
| /** | ||
| * Interface for the datasource registry | ||
| */ | ||
|
|
@@ -88,7 +90,7 @@ export interface Datasource<T = unknown, P = unknown> { | |
| getDatasourceSuggestionsForField: (state: T, field: unknown) => Array<DatasourceSuggestion<T>>; | ||
| getDatasourceSuggestionsFromCurrentState: (state: T) => Array<DatasourceSuggestion<T>>; | ||
|
|
||
| getPublicAPI: (state: T, setState: (newState: T) => void, layerId: string) => DatasourcePublicAPI; | ||
| getPublicAPI: (state: T, setState: StateSetter<T>, layerId: string) => DatasourcePublicAPI; | ||
| } | ||
|
|
||
| /** | ||
|
|
@@ -118,7 +120,7 @@ export type TableSpec = TableSpecColumn[]; | |
| export interface DatasourceDataPanelProps<T = unknown> { | ||
| state: T; | ||
| dragDropContext: DragContextState; | ||
| setState: (newState: T) => void; | ||
| setState: StateSetter<T>; | ||
| } | ||
|
|
||
| // The only way a visualization has to restrict the query building | ||
|
|
@@ -171,7 +173,7 @@ export interface VisualizationProps<T = unknown> { | |
| dragDropContext: DragContextState; | ||
| frame: FramePublicAPI; | ||
| state: T; | ||
| setState: (newState: T) => void; | ||
| setState: StateSetter<T>; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Visualizations are also getting the new
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You're right, I was not intending to make any change to visualizations in this PR |
||
| } | ||
|
|
||
| export interface SuggestionRequest<T = unknown> { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem right. Actions are supposed to be serializable / deserializable. It's one of the benefits of using an action / reducer pattern.
I'm not sure what we should do here, but I'd like to think it through a bit more. If we ever end up using a reducer-based undo / redo system, it would be really nice to keep actions data-only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might be right in the world of redux, but I'm not sure that pattern applies in the build-in dispatcher.
Also, this concept is already something we merged for updating layers: https://github.com/elastic/kibana/blob/feature/lens/x-pack/legacy/plugins/lens/public/editor_frame_plugin/editor_frame/state_management.ts#L44
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also not a strict rule in redux itself (https://redux.js.org/faq/actions#why-should-type-be-a-string-or-at-least-serializable-why-should-my-action-types-be-constants), but you are right, we should be aware of the trade-offs. I thought about this and discussed with @streamich when doing this change to the layer state management and I think it's the right thing to do this here.
For the undo / redo system the easiest way to is to buffer the sequence of states in a separate property (like this: https://redux.js.org/recipes/implementing-undo-history) to be able to re-apply them. The actions don't have to be serializable for this to work because they are still only applied once. Another way out of this would be to keep the actions as they are for the
dispatchcalls and call the updater functions in a middleware instead of the actual reducer to keep it serializable (just like thunk and saga works). But I would only do that once we get to the point we actually need it. We should take the easiest way that doesn't paint us in a corner here IMHO.