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

Toolbar #791

Merged
merged 31 commits into from
Oct 27, 2020
Merged

Toolbar #791

merged 31 commits into from
Oct 27, 2020

Conversation

hlyang397
Copy link
Contributor

@hlyang397 hlyang397 commented Sep 8, 2020

Updates

Demo screenshot or recording

image

Review checklist (for reviewers only)

  • Demos all features
  • Documented/annotated
  • Matches UI/UX specs
  • Meets the code style guide
  • Accessible
  • Mobile first (responsive)
  • RTL support (bidirectional text)
  • Performant (limited bloat)

- 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
@hlyang397 hlyang397 requested review from Donisius and removed request for a team September 8, 2020 06:39
Comment on lines 164 to 172
toolbar: {
enabled: false,
overflowMenuItems: {
resetZoom: {
enabled: false,
text: "Reset zoom"
} as ToolbarOverflowMenuItemOptions
} as ToolbarOverflowMenuItems
} as ToolbarOptions
Copy link
Member

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

@jeanservaas
Copy link

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:

  1. if you have two or three controls, they will appear as icons in the upper right corner, not in an overflow.
  2. If you have four or more controls, 2+ controls can appear in the overflow menu

Things we definitely want to avoid:

— Having only 1 item in an overflow menu
— Splitting up dependent controls like zoom up/zoom down (i.e. don't ever have a situation where one is in an overflow menu and one is not)

# 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
@hlyang397 hlyang397 requested a review from theiliad September 22, 2020 05:17
@hlyang397
Copy link
Contributor Author

@theiliad @jeanservaas
I have updated this PR based on the new spec you mentioned.
Please help to review it, thanks.

@theiliad
Copy link
Member

@theiliad @jeanservaas
I have updated this PR based on the new spec you mentioned.
Please help to review it, thanks.

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.

@hlyang397
Copy link
Contributor Author

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
Thanks for catching this.
The local storybook is good, but I import src folder in storybook demo folder, and that won't work in dist/.
I have fixed this in latest commit.
Please let me know if you find any other issue.

Copy link
Member

@theiliad theiliad left a 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
@hlyang397
Copy link
Contributor Author

💯
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

@theiliad Can Carbon Charts includes Carbon components as library ?
Toolbar controls (button, overflow menu) are highly related to carbon design system, and have dependency on carbon components. It makes no sense to reinvent the wheel.

jeanservaas
jeanservaas previously approved these changes Oct 6, 2020
Copy link

@jeanservaas jeanservaas left a 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
packages/core/src/services/zoom.ts Outdated Show resolved Hide resolved
packages/core/src/services/zoom.ts Outdated Show resolved Hide resolved
packages/core/src/interfaces/components.ts Outdated Show resolved Hide resolved
packages/core/src/interfaces/components.ts Outdated Show resolved Hide resolved
packages/core/demo/data/toolbar.ts Outdated Show resolved Hide resolved
}

// show/hide overflow menu
showOverflowMenu(show: boolean) {
Copy link
Member

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 😄

Copy link
Contributor Author

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 ?

Copy link
Member

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
Copy link
Member

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); 😄

Copy link
Contributor Author

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();
Copy link
Member

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

Copy link
Contributor Author

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 ?

Copy link
Member

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

Copy link
Contributor Author

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.

packages/core/src/components/axes/toolbar.ts Outdated Show resolved Hide resolved
.attr("opacity", 1);

// clean children first
container.html(null);
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

@theiliad theiliad left a comment

Choose a reason for hiding this comment

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

added comments above

@hlyang397
Copy link
Contributor Author

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();
Copy link
Member

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

@hlyang397 hlyang397 requested a review from theiliad October 15, 2020 04:36
@hlyang397
Copy link
Contributor Author

@theiliad Any other comment on this PR?

},
{
type: "Reset zoom",
text: "Reset zoom"
Copy link
Member

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

packages/core/demo/data/toolbar.ts Outdated Show resolved Hide resolved
packages/core/src/components/axes/toolbar.ts Outdated Show resolved Hide resolved
packages/core/src/components/axes/toolbar.ts Outdated Show resolved Hide resolved
}

// show/hide overflow menu
showOverflowMenu(show: boolean) {
Copy link
Member

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

packages/core/src/components/axes/toolbar.ts Outdated Show resolved Hide resolved
@hlyang397
Copy link
Contributor Author

@theiliad Updated based on your comments.
Please help to review again, thanks.

@hlyang397 hlyang397 requested a review from theiliad October 27, 2020 07:01
@theiliad theiliad requested review from jeanservaas and removed request for jeanservaas October 27, 2020 17:12
Copy link
Contributor

@natashadecoste natashadecoste left a 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

@theiliad theiliad merged commit de64e26 into carbon-design-system:master Oct 27, 2020
theiliad pushed a commit to theiliad/carbon-charts that referenced this pull request May 17, 2021
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants