Conversation
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
crob611
left a comment
There was a problem hiding this comment.
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 @@ | |||
| /* | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
I have had a couple of arguments in my head before implementing it:
ColorPickerat Canvas is totally our implementation. I believe, it has been created to hide the problems withreactDom.renderon args update. Now we've got rid of such a problem.- Also, if I know correctly, Kibana is moving in the direction of relying on the
euicomponents, to be able to change the UI very quickly. So, using the component, provided by theeuilib 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 |
There was a problem hiding this comment.
Remove double license header
| assets, | ||
| }; | ||
|
|
||
| // console.log(argumentProps); |
| key={`${opt.arg.name}-add`} | ||
| displayName={opt.arg.displayName ?? ''} | ||
| help={opt.arg.help ?? ''} | ||
| key={`${opt.name}-add`} |
There was a problem hiding this comment.
Question: What changed that led this to be the OptionArg?
There was a problem hiding this comment.
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 })); |
There was a problem hiding this comment.
Should probably change the name of this action since it no longer uses the index
|
|
||
| type Props = ArgTemplateFormProps['argumentProps']; | ||
|
|
||
| export const withDebounceArg = |
| const DatacolumnArgInput = ({ | ||
| onValueChange, | ||
| columns, | ||
| resolved: { columns }, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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:
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 (
) you can see, that I've localized the object, produced byresolve 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.
|
@elasticmachine merge upstream |
|
@stratoula, when you'll review the current PR again, please, tell me if you agree with these changes: d0383a6. Thanks ) |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
@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. |
dej611
left a comment
There was a problem hiding this comment.
Checked vis-editors changes and LGTM 👍
|
@stratoula, @dej611, @crob611, thanks for your reviews ) |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @Kunzetsov |
crob611
left a comment
There was a problem hiding this comment.
Looks great. Excited to have this in Canvas


Summary
Heatmap charthas been integrated toCanvas.Introduced changes:
heatmapexpression function.color_pickerwith interactive palette toCanvas.heatmapview,heatmap_gridandheatmap_legendmodels.Canvas sidebar panel.Canvas sidebar panel.withDebounceArgHoC, which is making inputs more usable for users atCanvas sidebar panel.number,string,range,percentagefor supporting better UX without lagging and moving the cursor to the end of the line.Argcomponent, which affected the performance of the Canvas positively.Screenshots
Support of expression functions as arguments: