-
Notifications
You must be signed in to change notification settings - Fork 121
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
feat(style): allow fill and stroke overrides #258
Conversation
This allows the computed series color to be overridden by the theme or the series specific style. BREAKING CHANGE: `LineStyle`, `AreaStyle` and `BarSeriesStyle` types differs on the optional values. `stroke` and `fill` on the theme or specific series style now override the computed series color.
Codecov Report
@@ Coverage Diff @@
## master #258 +/- ##
==========================================
+ Coverage 97.84% 97.99% +0.14%
==========================================
Files 36 36
Lines 2693 2840 +147
Branches 607 660 +53
==========================================
+ Hits 2635 2783 +148
Misses 51 51
+ Partials 7 6 -1
Continue to review full report at Codecov.
|
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.
tested locally on firefox and code LGTM just a small couple of questions
rect: RectStyle; | ||
rectBorder: RectBorderStyle; | ||
displayValue: DisplayValueStyle; | ||
} |
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.
For some of the properties above, we have defined interfaces for them already. Should we use them where possible? For example, we have an Opacity
interface that could be referenced instead of duplicating it manually within RectStyle
. (The same for FillStyle
, StrokeStyle
, Visible
and StrokeDashArray
.) If we aren't going to reuse those interfaces, should we delete them? Looks like Radius
was already deleted in favor of defining it inside the interface.
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.
@emmacunningham here my difficulty was the following: the StrokeStyle
is specified as
export interface StrokeStyle {
/** The stroke color in hex, rgba, hsl */
stroke: string;
/** The stroke width in pixel */
strokeWidth: number;
}
but I want to to have the stroke optional and the strokeWidth required. Is there a way to achieve that? I can change the StrokeStyle
type but we maybe need a different configuration in the future. Splitting the StrokeStyle
into two types is useless and we can just go removing all the Stroke/Opacity interfaces.
What do you think?
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.
I believe you can do something like this to extend StrokeStyle
such that stroke
becomes optional and strokeWidth
remains required.
First, we need a way to keep one property as required and make the rest optional:
export type RequireOneAndMakeRestOptional<T, K extends keyof T> = { [X in Exclude<keyof T, K>]?: T[X] } & { [P in K]-?: T[P] };
and then RectBorderStyle
for example could be:
export type RectBorderStyle = RequireOneAndMakeRestOptional<StrokeStyle, 'strokeWidth'> & Visible;
I'm not sure this is that much better since it requires other contributors to understand what RequireOneAndMakeRestOptional
is doing to understand the type annotations where it's being used. I think that the way you have it now is more easy to follow and read.
Having the interfaces for these common styling properties I think is useful because it makes it easier for other contributors to compose new interfaces that are consistent (so we don't accidentally type stroke
as a number
sometimes, for example). In particulary, I think StrokeDashArray
is especially useful because it is not obvious what this should be (in fact, we could probaably make this more explicit as [number, number]
) for someone not familiar with the API to create a dashed stroke.
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.
I will leave this as it is for the moment, and we can find a clear type later. You are completely right about the fact that a common styling type is required, I will like to open a PR with that in the next future #264
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.
Tested locally, LGTM. Only a few comments around mergeWithDefaultTheme
.
# [8.0.0](v7.2.1...v8.0.0) (2019-07-15) ### Code Refactoring * **legend:** remove visibility button ([#252](#252)) ([90a1ba7](90a1ba7)) ### Features * **style:** allow fill and stroke overrides ([#258](#258)) ([99c5e9f](99c5e9f)) ### BREAKING CHANGES * **style:** `LineStyle`, `AreaStyle` and `BarSeriesStyle` types differs on the optional values. `stroke` and `fill` on the theme or specific series style now override the computed series color. * fix: no unused locals error on theme * fix: avoid key prop override by spread operator * test: increase test coverage on PR changes * fix: fontSize is now always a number * test: increase coverage for rendendering * refactor(story): simplify theme merging on `with value label` story * refactor: removed mergeWithDefaultTheme * **legend:** the `onLegendItemClick` click handler is no longer applied when clicking on the title. Instead a simple visibility change is applied.
🎉 This PR is included in version 8.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
# [8.0.0](elastic/elastic-charts@v7.2.1...v8.0.0) (2019-07-15) ### Code Refactoring * **legend:** remove visibility button ([opensearch-project#252](elastic/elastic-charts#252)) ([efb3823](elastic/elastic-charts@efb3823)) ### Features * **style:** allow fill and stroke overrides ([opensearch-project#258](elastic/elastic-charts#258)) ([1648996](elastic/elastic-charts@1648996)) ### BREAKING CHANGES * **style:** `LineStyle`, `AreaStyle` and `BarSeriesStyle` types differs on the optional values. `stroke` and `fill` on the theme or specific series style now override the computed series color. * fix: no unused locals error on theme * fix: avoid key prop override by spread operator * test: increase test coverage on PR changes * fix: fontSize is now always a number * test: increase coverage for rendendering * refactor(story): simplify theme merging on `with value label` story * refactor: removed mergeWithDefaultTheme * **legend:** the `onLegendItemClick` click handler is no longer applied when clicking on the title. Instead a simple visibility change is applied.
Summary
This PR allows the computed series color to be overridden by the theme or the series specific style.
BREAKING CHANGE:
LineStyle
,AreaStyle
andBarSeriesStyle
types differs on the optional values.stroke
andfill
on the theme or specific series style now override the computed series color.The a style overrides with the following flows:
stroke
orfill
prop will override the computed series color for that specific style element). If not go to nextstroke
orfill
is present on the charttheme
prop for a Bar/Area/Line than it will use that color for the point (stroke or fill) line (stroke) bar(stroke, fill, borderStroke)stroke
orfill
is configured on theme or series specific style than we will use the one computed or assigned withcustomSeriesColors
propnotes
build...props
used to compute the props for rendering lines/areas/bars/points, cleaning a but the function semantics.bar
rendered geometry is currently increased, but I will find a better way to specify that for bars in the future.Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.src/index.ts
(and stories only import from../src
except for test data & storybook)