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

[Lens] Manual Annotations #126456

Merged
merged 54 commits into from
Mar 23, 2022
Merged

Conversation

mbondyra
Copy link
Contributor

@mbondyra mbondyra commented Feb 28, 2022

Summary

Introduces new type of the layer for xy chart: annotations.
Only targets manual, 'point in time' annotations.

The icon set is covering most cases for tsvb (to be able to migrate in the future) and all we use for reference lines
Ranges will be added soon (in separate pr).
Drag and drop will be added soon (in separate pr).
Tooltip collect the info for all the annotations from the interval.

Default look:
Screenshot 2022-03-23 at 09 47 50
Grouping and custom annotations:
Screenshot 2022-03-23 at 09 49 27
Screenshot 2022-03-23 at 09 46 57
Screenshot 2022-03-23 at 09 47 05

Event annotations service

At the moment the service only contains the expressions.

@mbondyra mbondyra force-pushed the lens/annotation_service branch 2 times, most recently from 1f7c9a1 to 021117c Compare March 10, 2022 13:31
@mbondyra
Copy link
Contributor Author

@elasticmachine merge upstream

@mbondyra mbondyra force-pushed the lens/annotation_service branch from e1906c0 to 526cad1 Compare March 14, 2022 10:01
@elastic elastic deleted a comment from kibana-ci Mar 14, 2022
@mbondyra mbondyra force-pushed the lens/annotation_service branch 17 times, most recently from 9d2f6fc to d624222 Compare March 17, 2022 20:08
@Kuznietsov Kuznietsov mentioned this pull request Mar 18, 2022
2 tasks
@mbondyra mbondyra force-pushed the lens/annotation_service branch 3 times, most recently from 430816b to 63f804e Compare March 18, 2022 16:46
* Side Public License, v 1.
*/
import { euiLightVars } from '@kbn/ui-theme';
export const defaultAnnotationColor = euiLightVars.euiColorAccent;
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: I probably recommended not to fix the value at the time of import. Maybe geDefaultAnnotationColor = () => euiLightVars.euiColorAccent;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why does it matter? 🤔

Copy link
Member

@markov00 markov00 Mar 23, 2022

Choose a reason for hiding this comment

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

@mbondyra not related to alex suggestion, but to the color: the euiColorAccent differs if you are in dark mode or light mode. in the light theme the color is #F04E98 but is #F68FBE in dark mode.
@MichaelMarcialis ideas?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@markov00 does it matter? Why is it concerning?

Copy link
Contributor

@flash1293 flash1293 Mar 23, 2022

Choose a reason for hiding this comment

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

On switching to dark mode the annotations will still have the light theme color because it's putting the hex value into the saved object. I think that is OK for this PR, it's the same for all of the place where we allow the users to pick a color (series, reference lines and so on). When we discussed this the last time we said we would tackle this problem separately in a general way and apply the same solution to all the places which allow this kind of thing right now.

Copy link
Contributor

Choose a reason for hiding this comment

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

@mbondyra not related to alex suggestion, but to the color: the euiColorAccent differs if you are in dark mode or light mode. in the light theme the color is #F04E98 but is #F68FBE in dark mode.
@MichaelMarcialis ideas?

@markov00: That's a good point; something we hadn't considered in our discussion yesterday. Ideally, we would have a single color value that works well for both light and dark modes. Otherwise, the default color is not a purely static value, but a partially dynamic one that changes depending on the theme mode selected when the visualization was created. This could be unexpected or undesirable to users (especially after changing an existing space's theme mode, when sharing/copying visualization across spaces, and in the future when users can set their own theme modes). This is part of the reason why we chose a gray color for the default reference line color, because it works in both theme modes.

In this case, the difference in the color value between light and dark mode presents a similar problem to the one we discussed yesterday if we were to choose black (which would require switching to white in dark mode). That said, because the contrast gap between accent colors in light and dark mode is far lower than the contrast gap between black and white, perhaps we can live with it for now until a more general solution for handling color selection between light/dark themes is addressed, as @flash1293 stated above.

For the sake of the immediate present, I'd say let's either stick with the EUI accent color (regardless of the fact that it will change on visualization creation depending on theme mode), or switch to same gray we use for reference lines as the default.

public setup(core: CoreSetup, dependencies: SetupDependencies): EventAnnotationPluginSetup {
dependencies.expressions.registerFunction(manualEventAnnotation);
dependencies.expressions.registerFunction(eventAnnotationGroup);
return this.eventAnnotationService;
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: I see only one method in that service, not sure that it's a legal to execute this one during setup phase. I prefer to return {} or cleanup API

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But at some point I'll add extra functionality here. I will not correct it in this PR but revisit later to make sure if it doesn't break any rules.

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

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

It seems like there are still a few references to explicit icon placement in the helpers, do we still need those?

Pick<YConfig, 'axisMode' | 'icon' | 'iconPosition' | 'textVisibility'> | undefined

In general I really like this change, one thing we can also split out - what if on creating a new annotation it would copy over the styling from the last one in the list? That would make it easy to create lots of annotations which are similarly styled (set the styling on the first one and it will be pre-set for the rest)

@mbondyra
Copy link
Contributor Author

@flash1293 about the references to icon position, it happens because the helpers are shared between reference lines and annotations so for reference lines it's still needed.

Copying styles from the last one in the list/ last one edited - what do you think about it @gvnmagni @MichaelMarcialis? Nevertheless, I'd address it in a separate PR.

@gvnmagni
Copy link

@flash1293 about the references to icon position, it happens because the helpers are shared between reference lines and annotations so for reference lines it's still needed.

Copying styles from the last one in the list/ last one edited - what do you think about it @gvnmagni @MichaelMarcialis? Nevertheless, I'd address it in a separate PR.

The concept itself is really interesting, the only concern I have is that we have to find a proper way to explain what's happening to the user and I'm not sure there is a simple way to do that, I'll hear what Michael has to say

@mbondyra mbondyra force-pushed the lens/annotation_service branch from 19dcb3d to 0771829 Compare March 23, 2022 15:41
Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

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

LGTM, talked through a few small things offline and this is a great first version

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.

maps changes LGTM
code review, tested in chrome

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.

Changes LGTM, sorry for the delay Marta. I tested everything and it works fine. Great PR, great enhancement ❤️

@MichaelMarcialis
Copy link
Contributor

@flash1293 about the references to icon position, it happens because the helpers are shared between reference lines and annotations so for reference lines it's still needed.
Copying styles from the last one in the list/ last one edited - what do you think about it @gvnmagni @MichaelMarcialis? Nevertheless, I'd address it in a separate PR.

The concept itself is really interesting, the only concern I have is that we have to find a proper way to explain what's happening to the user and I'm not sure there is a simple way to do that, I'll hear what Michael has to say

Yeah, my first instinct here is to agree with @gvnmagni. The concept is interesting, but I worry that the implementation would be non-obvious and potentially frustrating if that is not the desired behavior. I think some exploration can and should be done separately in terms of 1) users being able to establish style defaults for various aspects of Lens (including annotations) and 2) possibly consider the possibility of being able to bulk style/edit certain dimension items. Thoughts?

@flash1293
Copy link
Contributor

Yeah, no worries, definitely something to look into later, I just kind of expected this to happen that’s why I wanted to share.

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
eventAnnotation - 11 +11
lens 758 784 +26
total +37

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
eventAnnotation - 49 +49
lens 356 363 +7
total +56

Async chunks

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

id before after diff
eventAnnotation - 661.0B +661.0B
lens 1.1MB 1.1MB +19.3KB
total +20.0KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id before after diff
eventAnnotation - 3 +3
lens 43 44 +1
total +4

Page load bundle

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

id before after diff
eventAnnotation - 5.6KB +5.6KB
lens 44.2KB 44.9KB +713.0B
total +6.3KB
Unknown metric groups

API count

id before after diff
eventAnnotation - 49 +49
lens 429 438 +9
total +58

async chunk count

id before after diff
eventAnnotation - 1 +1

ESLint disabled in files

id before after diff
eventAnnotation - 1 +1

Total ESLint disabled count

id before after diff
eventAnnotation - 1 +1

History

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

@mbondyra mbondyra merged commit 2f9e6ee into elastic:main Mar 23, 2022
@mbondyra mbondyra added backport:skip This commit does not require backporting and removed ci:deploy-cloud labels Mar 23, 2022
@mbondyra mbondyra deleted the lens/annotation_service branch April 4, 2022 12:01
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 Feature:Lens release_note:feature Makes this part of the condensed release notes Team:Visualizations Visualization editors, elastic-charts and infrastructure v8.2.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.