-
Notifications
You must be signed in to change notification settings - Fork 185
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
Toolbar #791
Toolbar #791
Conversation
- toolbar configuration - zoom in/out icon - overflow menu - enable toolbar in zoom bar storybook
- remove toolbar options in zoom bar demo group
- simplify css - refactor toolbar button generation code
- allow button disabled state - check min/max zoom domain for zoom in/out button
packages/core/src/configuration.ts
Outdated
toolbar: { | ||
enabled: false, | ||
overflowMenuItems: { | ||
resetZoom: { | ||
enabled: false, | ||
text: "Reset zoom" | ||
} as ToolbarOverflowMenuItemOptions | ||
} as ToolbarOverflowMenuItems | ||
} as ToolbarOptions |
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.
So what's been discussed with Josh Kimmel and the rest of the dataviz guild would work a bit differently than specified here.
The user would need a way of defining how many icons to show and how many to move into the overflow.
This means that each item should have a name & icon, and the items can no longer be called overflow
items but more so just controls
in general.
That way the user can define a max number (e.g. 2) which means that the zoom in & zoom out buttons would show up as icons and everything else would go inside the overflow menu.
Additionally, the user needs to have a way of changing the order (e.g. define the order as zoom in
, zoom out
, reset zoom
, make fullscreen
, print
and choose the limit as 3 which'll mean they'll only see zoom in, zoom out & reset zoom as icons)
Not sure if this is the best route to go but it's what design is asking for. I'll tag @jeanservaas here for feedback
Yes I think this is what we agreed upon in the call... The user can basically arrange the controls they way they want, but we have some best practice suggestions The things we strongly encourage:
Things we definitely want to avoid: — Having only 1 item in an overflow menu |
# Conflicts: # packages/core/src/configuration.ts # packages/core/src/interfaces/components.ts # packages/core/src/services/zoom.ts
- create ToolbarControlTypes enum - change configuration and interfaces - decide how many controls are in button and in overflow menu - change svg icon from 16x16 to 32x32 viewBox
@theiliad @jeanservaas |
Hi, it seems like deploy previews aren't working and Travis is failing. Might be some errors that we'd need to fix in the code. You should be seeing some errors when running or building storybook locally. |
@theiliad |
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.
💯
We need the controls in the toolbar to be keyboard accessible (user should be able to tab through), and possibly proper aria labeling. Please see the legend items as an example in the demos
- make control focusable - specify roles in control
@theiliad Can Carbon Charts includes Carbon components as library ? |
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! Thanks for the update
# Conflicts: # packages/core/src/configuration.ts # packages/core/src/services/zoom.ts
} | ||
|
||
// show/hide overflow menu | ||
showOverflowMenu(show: boolean) { |
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.
so in the comments it says show/hide overflow menu
however the method name is showOverflowMenu
😄
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.
@theiliad
Yes, we use the boolean parameter to decide if we should show or hide the overflow menu.
I am not pretty sure what's your preference.
Do you like to have two separate functions (showOverflowMenu
and hideOverflowMenu
) ?
Or any other preferred function name ?
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.
My concern is the name of the function. Looking at the name showOverflowMenu
I'd assume that calling it would show
the overflow menu. Maybe we need to call it updateOverflowMenu
|
||
toggleOverflowMenu() { | ||
if (this.isOverflowMenuOpen()) { | ||
// hide overflow menu |
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.
// hide overflow menu
...... => this.showOverflowMenu(false);
😄
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.
Please refer to #791 (comment).
switch (control.type) { | ||
case ToolbarControlTypes.ZOOM_IN: | ||
if (isZoomBarEnabled) { | ||
controlConfig = this.getZoomInConfig(); |
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.
seems like we can have 1 method called getControlConfigs(control: ToolbarControlTypes)
which'll just give you the right config rather than implementing a switch
and having multiple config methods
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.
@theiliad
I don't get your point.
Even you have a getControlConfigs(control: ToolbarControlTypes)
method, you still need a switch
in the method to return respective config based on ToolbarControlTypes
.
Could you provide a pseudo code or example ?
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.
Hi, yes what I'm trying to avoid is a getZoomInConfig()
call for a small object return. This'll result in too many methods in the future.
If we just have a getControlConfigs()
that includes all the configs and returns the 1 we care about, then it's simpler
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.
Updated in bcee77b.
Please let me know if this is not what you expected, thanks.
.attr("opacity", 1); | ||
|
||
// clean children first | ||
container.html(null); |
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.
hmmmm... so the toolbar cleans everything everytime? Why not render more efficiently through d3?
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.
Yes, we need to clean buttons if data is loading, or update toolbar controls if configuration is changed.
We could use d3, but I don't think it could help to reduce the code complexity because the buttons and overflow menu items are more related to configurations instead of simple data, and for each configuration we need to create complex html component instead of SVG.
Pleasee let me know if you still think we should change to use d3.
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.
added comments above
@theiliad I have updated PR based on your comments. Please help to review again, thanks. |
switch (control.type) { | ||
case ToolbarControlTypes.ZOOM_IN: | ||
if (isZoomBarEnabled) { | ||
controlConfig = this.getZoomInConfig(); |
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.
Hi, yes what I'm trying to avoid is a getZoomInConfig()
call for a small object return. This'll result in too many methods in the future.
If we just have a getControlConfigs()
that includes all the configs and returns the 1 we care about, then it's simpler
@theiliad Any other comment on this PR? |
packages/core/demo/data/toolbar.ts
Outdated
}, | ||
{ | ||
type: "Reset zoom", | ||
text: "Reset zoom" |
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.
Maybe it'd better to just include a small tutorial story for the toolbar and describe this there. I wouldn't want the text in the demo code, that'll result in users copying that code over to their projects, and it'll show up in codesandbox
} | ||
|
||
// show/hide overflow menu | ||
showOverflowMenu(show: boolean) { |
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.
My concern is the name of the function. Looking at the name showOverflowMenu
I'd assume that calling it would show
the overflow menu. Maybe we need to call it updateOverflowMenu
- titlePostfix -> titleSuffix - showOverflowMenu -> updateOverflowMenu - VERTICAL_ALIGNMENT_Y -> Y_OFFSET
@theiliad Updated based on your comments. |
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.
Nice
💯 for documention too
…lbar * feat: create toolbar components - toolbar configuration - zoom in/out icon - overflow menu - enable toolbar in zoom bar storybook * refactor: use constants in configuration * feat: create toolbar storybook demo group - remove toolbar options in zoom bar demo group * refactor: toolbar button - simplify css - refactor toolbar button generation code * feat: disable toolbar button if it won't work - allow button disabled state - check min/max zoom domain for zoom in/out button * fix: title should use parent node to get max title width * feat: provide minZoomRatio option * feat allow overflow menu item to be disabled * feat: combine toolbar icon and overflow menu item to controls - create ToolbarControlTypes enum - change configuration and interfaces - decide how many controls are in button and in overflow menu - change svg icon from 16x16 to 32x32 viewBox * fix: not import src/ in demo folder to avoid build failure * feat: support keyboard event for toolbar button - make control focusable - specify roles in control * refactor: fix scss style * refactor: change configuration name - maxIcons => numberOfIcons - controlsInOrder => controls * refactor: remove default ToolbarControls in configuration * feat: allow to use keyboard to control overflow menu * fix: align toolbar to title component * refactor: refactor statements and fix typos * refactor: change ToolbarControl.text field to optional * refactor: use getControlConfigByType() to reduce methods count * refactor: minor changes per comments - titlePostfix -> titleSuffix - showOverflowMenu -> updateOverflowMenu - VERTICAL_ALIGNMENT_Y -> Y_OFFSET * refactor: remove toolbar control text in demo * refactor: use d3.select to replace document.getElementById Co-authored-by: Fei Z <[email protected]>
Updates
Demo screenshot or recording
Review checklist (for reviewers only)