-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Lens] Manual Annotations #126456
Conversation
1f7c9a1
to
021117c
Compare
@elasticmachine merge upstream |
e1906c0
to
526cad1
Compare
9d2f6fc
to
d624222
Compare
430816b
to
63f804e
Compare
* Side Public License, v 1. | ||
*/ | ||
import { euiLightVars } from '@kbn/ui-theme'; | ||
export const defaultAnnotationColor = euiLightVars.euiColorAccent; |
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.
nit: I probably recommended not to fix the value at the time of import. Maybe geDefaultAnnotationColor = () => euiLightVars.euiColorAccent;
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.
Why does it matter? 🤔
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.
@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?
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.
@markov00 does it matter? Why is it concerning?
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.
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.
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.
@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; |
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.
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
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.
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.
x-pack/plugins/lens/public/xy_visualization/annotations/config_panel/index.tsx
Show resolved
Hide resolved
x-pack/plugins/lens/public/xy_visualization/annotations/helpers.tsx
Outdated
Show resolved
Hide resolved
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 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)
@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. |
x-pack/plugins/maps/public/lens/choropleth_chart/region_key_editor.tsx
Outdated
Show resolved
Hide resolved
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 |
19dcb3d
to
0771829
Compare
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.
LGTM, talked through a few small things offline and this is a great first version
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.
maps changes LGTM
code review, tested in chrome
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.
Changes LGTM, sorry for the delay Marta. I tested everything and it works fine. Great PR, great enhancement ❤️
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? |
Yeah, no worries, definitely something to look into later, I just kind of expected this to happen that’s why I wanted to share. |
💚 Build SucceededMetrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
async chunk count
ESLint disabled in files
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
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:
Grouping and custom annotations:
Event annotations service
At the moment the service only contains the expressions.