-
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
palette context type alignment #70943
Comments
Pinging @elastic/kibana-app-arch (Team:AppArch) |
Pinging @elastic/kibana-canvas (Team:Canvas) |
how
in the future we could extend this with |
Some initial feedback:
|
Honestly, replace |
I agree we'll get to the changing palette type should not be a breaking change for canvas due to the changing the function implementation could be, so maybe we should leave the old the lets keep this a palette discussion and try to align on this one. We can start the theme discussion at the same time, but my preference would be to take a look at aligning on |
Just a side note - when we implement the theme mode (override the chosen palette based on execution context), we should provide a flag to opt out of that. There are cases where you want to color everything in the same way except for some specific (parts of) visualizations. Example: A "traffic light" kind of visualization which only makes sense when the "status" palette is used (even if the rest of the workpad / dashboard is using something else) |
@flash1293 agreed, but lets discuss that here: #71064 |
@ppisljar We really, really should start with 1/ someone creates a workpad in 7.8, then imports it in 7.10, we have to migrate the workpad every time it's uploaded. I'm fine with adding, but removing becomes a major hurdle we haven't had to tackle yet because we avoid it. If we know we want to get to I mean, what is the difference we're talking about here? Adding
|
If we define theme as @ppisljar I can include this in my initial PR setting up palettes in the charts plugin. |
Synced with @clintandrewhall and @poffdeluxe and we would like to start with this: Using a unified infrastructure for palettes makes sense and we should definitely do this as it opens up lots of options in the long-term. However overloading the Both of these functions are generating the same context: interface Palette {
type: 'palette',
name: 'name-of-palette',
params: { // additional palette params }
} The {
type: 'palette',
name: 'custom',
params: {
colors: ['red', 'green', 'blue']
}
} Everything else works like defined in the original description, the actual logic for picking colors is provided by the |
cc @ppisljar see the above addition to the proposal. If you are fine with this, I think I can get started on it. |
I want to try to rename the issue title to be more "outside in". Would this be accurate: "Add support for Canvas Themes in Lens Embeddables"? Should this issue be owned by KibanaApp, with Canvas as the requester? ( |
@flash1293 sounds good to me |
Great, I am going to implement this soon. |
Closed by #75309 |
Various teams writing expression functions and renderers come across requirement to work with color palletes. This is an effort to align on palette context type and a set of functions around it that can serve the needs of all teams and will allow us to integrate better.
some related issues:
#61977
#69349
canvas current state:
currently canvas has a
pallete
function, which accepts array of colors and some aditional parameters (gradient, reverse) and outputs thepallete
context type, with the following interface:lens current state:
lens is still working on color palette support, but they plan to use EUI color palettes http://eui.elastic.co/#/utilities/color-palettes
for that reason they are planing on providing a set of expression functions to work with them #69800
proposal:
palette
context type andpalette
function and move them over to expressions pluginpalette
type to have the following form:getPallete(palette: Pallete): PalleteHANDLER
utility function which would return a set of functions to help with color generationpallete
context type would define a converter from array of strings to thepallete
context type. this way we don't need to migrate any existing canvas expressions as an array of colors (what canvas currently has) would get migrated towe would extend
palette
expression function to optionally take in a palette name and in this case lookup the palette with EUI palettes. Of course we will also change it to output correct newpalette
context typeextend
palette
function withtheme
support, to support theming in canvas (and in lens/visualize/dashboard in the future)extend
palette
function withglobal overrides
support, allowing you to override the color for specific series in all the charts in specific workpad/dashboardextend
palette
function withuser overrides
support, allowing setting themes/colors on user level (uiSettings)provide functions for specific palettes as a wrapper around main
palette
function (for easier consumption)example usage:
The text was updated successfully, but these errors were encountered: