Skip to content

[Canvas] HeatMap.#120239

Merged
Kuznietsov merged 55 commits intoelastic:mainfrom
Kuznietsov:canvas-heat-map
Jan 12, 2022
Merged

[Canvas] HeatMap.#120239
Kuznietsov merged 55 commits intoelastic:mainfrom
Kuznietsov:canvas-heat-map

Conversation

@Kuznietsov
Copy link
Contributor

@Kuznietsov Kuznietsov commented Dec 2, 2021

Summary

Heatmap chart has been integrated to Canvas.

Introduced changes:

  • Added default expressions to heatmap expression function.
  • Added color_picker with interactive palette to Canvas.
  • Added heatmap view, heatmap_grid and heatmap_legend models.
  • Added support of handling expression functions as arguments at Canvas sidebar panel.
  • Added support of adding models/views as arguments of the views/models at Canvas sidebar panel.
  • Added withDebounceArg HoC, which is making inputs more usable for users at Canvas sidebar panel.
  • Fixed number, string, range, percentage for supporting better UX without lagging and moving the cursor to the end of the line.
  • Reduced amount of arguments, passed to the Arg component, which affected the performance of the Canvas positively.

Screenshots

Support of expression functions as arguments:

Image 16 12 2021 at 17 28
Screenshot 2021-12-16 at 17 30 29

Screenshot 2021-12-16 at 17 31 36
Screenshot 2021-12-16 at 17 37 48

@Kuznietsov Kuznietsov self-assigned this Dec 2, 2021
@Kuznietsov Kuznietsov added the WIP Work in progress label Dec 2, 2021
@Kuznietsov Kuznietsov requested a review from flash1293 December 3, 2021 07:58
@Kuznietsov
Copy link
Contributor Author

@elasticmachine merge upstream

@Kuznietsov Kuznietsov linked an issue Dec 8, 2021 that may be closed by this pull request
@Kuznietsov
Copy link
Contributor Author

@elasticmachine merge upstream

@stratoula stratoula requested a review from dej611 December 22, 2021 12:55
Copy link
Contributor

@crob611 crob611 left a comment

Choose a reason for hiding this comment

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

Looks good. Left a couple of comments that should be cleaned up and a couple of questions I'm curious about, but overall, I think it's good.

@@ -0,0 +1,56 @@
/*
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason we need this new color picker vs the existing color argument type? Color is probably not reusable outside of canvas, but it would at least keep consistency in Canvas that we can figure out once we make all of that available elsewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have had a couple of arguments in my head before implementing it:

  1. ColorPicker at Canvas is totally our implementation. I believe, it has been created to hide the problems with reactDom.render on args update. Now we've got rid of such a problem.
  2. Also, if I know correctly, Kibana is moving in the direction of relying on the eui components, to be able to change the UI very quickly. So, using the component, provided by the eui lib and not relying on the colors from the workpad directly in all the cases is a good idea, it seems to me.

@crob611, what do you think?

* 2.0.
*/
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove double license header

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

assets,
};

// console.log(argumentProps);
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove comment

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

key={`${opt.arg.name}-add`}
displayName={opt.arg.displayName ?? ''}
help={opt.arg.help ?? ''}
key={`${opt.name}-add`}
Copy link
Contributor

Choose a reason for hiding this comment

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

Question: What changed that led this to be the OptionArg?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The unnecessarily huge complexity of the configuration of the element, which just needs to display an array of labels)
The additional props, passed to the element, are leading to useless computations.

value: argValue,
})
);
dispatch(addArgumentValueAtIndex({ element, pageId, argName, value: argValue, path }));
Copy link
Contributor

Choose a reason for hiding this comment

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

Should probably change the name of this action since it no longer uses the index

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.


type Props = ArgTemplateFormProps['argumentProps'];

export const withDebounceArg =
Copy link
Contributor

Choose a reason for hiding this comment

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

I really like this 👍

const DatacolumnArgInput = ({
onValueChange,
columns,
resolved: { columns },
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you explain the chain that led to some of these args having input come in via this resolved instead of directly as it previously was?

Copy link
Contributor Author

@Kuznietsov Kuznietsov Dec 23, 2021

Choose a reason for hiding this comment

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

Sure. Before, at the Arg class, we were creating templateProps and passing there everything, but required only a few of the props, which were passed. So, I've reduced the number of props, we're passing and the performance has raised.

But also, we have to control things, which are passed to the arguments.
At the previous version of this code you could see such logic:

const templateProps = { ...otherProps, ...resolved, onValueChange, typeInstance: this };

, where resolved are the props, which are produced by models/views/transforms resolve method. Example:

resolve({ context }: any): ResolvedColumns {

Such logic can cause some problems because it is impossible to track if some prop is rewritten. Also, it is difficult to document the types.

At this piece of code (

resolved: { ...resolved, ...resolvedProps },
) you can see, that I've localized the object, produced by resolve method and now it is easier to track and understand the way, how our code is really working, and which props are default, and which are specific for our view/model/etc.

@Kuznietsov
Copy link
Contributor Author

@elasticmachine merge upstream

@Kuznietsov
Copy link
Contributor Author

Kuznietsov commented Dec 24, 2021

@stratoula, when you'll review the current PR again, please, tell me if you agree with these changes: d0383a6. Thanks )

@Kuznietsov
Copy link
Contributor Author

@elasticmachine merge upstream

@stratoula
Copy link
Contributor

@elasticmachine merge upstream

@stratoula
Copy link
Contributor

@Kunzetsov I think that the only required dimension should be the valueAccessor.
In Lens the vertical axis is not required
image

and in vizualize editor only the value accessor is required
image

With that being said I think is better to not apply these changes

@Kuznietsov
Copy link
Contributor Author

@Kunzetsov I think that the only required dimension should be the valueAccessor. In Lens the vertical axis is not required image

and in vizualize editor only the value accessor is required image

With that being said I think is better to not apply these changes

@stratoula, I've played with these options before and they are causing troubles with required arguments. So, I've left it as it was before.

Copy link
Contributor

@stratoula stratoula left a comment

Choose a reason for hiding this comment

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

Vis editor changes LGTM! I haven' checked a lot the canvas addition but I made some tests on viz editor and lens heatmaps. They work as expected.

I just want from @dej611 to have a look too just to have another pair of 👁️

Copy link
Contributor

@dej611 dej611 left a comment

Choose a reason for hiding this comment

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

Checked vis-editors changes and LGTM 👍

@Kuznietsov
Copy link
Contributor Author

@stratoula, @dej611, @crob611, thanks for your reviews )

@Kuznietsov
Copy link
Contributor Author

@elasticmachine merge upstream

@Kuznietsov
Copy link
Contributor Author

@elasticmachine merge upstream

@Kuznietsov
Copy link
Contributor Author

@elasticmachine merge upstream

@kibana-ci
Copy link

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
canvas 1069 1078 +9

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
expressionHeatmap 111 95 -16

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
canvas 1011.1KB 1.0MB +16.5KB
expressionHeatmap 14.9KB 15.0KB +132.0B
lens 1021.1KB 1020.8KB -283.0B
total +16.3KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
expressionHeatmap 12.9KB 12.2KB -656.0B
Unknown metric groups

API count

id before after diff
expressionHeatmap 115 99 -16

History

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

cc @Kunzetsov

Copy link
Contributor

@crob611 crob611 left a comment

Choose a reason for hiding this comment

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

Looks great. Excited to have this in Canvas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport:skip This PR does not require backporting Feature:Canvas impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. release_note:feature Makes this part of the condensed release notes Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas t// v8.1.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Heatmap] Not used expression functions arguments.

7 participants