-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
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
[SpeedDial] Rework part of the logic #17301
[SpeedDial] Rework part of the logic #17301
Conversation
@material-ui/lab: parsed: +0.78% , gzip: +0.34% Details of bundle changes.Comparing: 0ddd56f...81a92f8
|
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.
Thanks for the effort.
packages/material-ui-lab/src/SpeedDialAction/SpeedDialAction.js
Outdated
Show resolved
Hide resolved
packages/material-ui-lab/src/SpeedDialAction/SpeedDialAction.js
Outdated
Show resolved
Hide resolved
59b8e6d
to
c8c5e62
Compare
2523221
to
ee1e6a0
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.
Alright, it should be ready for review. I have done a few aggressive changes, I hope it's fine.
A couple of observations from playing with it (with no reference to the code): When you tab onto the Fab the speed-dial opens, and you can then use the cursor keys to navigate the items. If the SpeeDial is closed (escape or space keys) key or by triggering an item (enter or space keys on an item), the cursor keys still navigate the items, but with incorrect focus appearance: (sorry about the big image, retina macbook scaling issue) In the case of preessing escape when an item is focussed, focus doesn't return to the Fab, and the behaviour is as above. Also, when the speed-dial is horizontal, should the up-down arrow keys still work? (How does a blind keyboard user know the orientation of a pop-up?) |
015f714
to
36e54c0
Compare
@mbrookes Thanks for the functionnal review, I have tried to solve all the concerns. However, I have no idea how to solve the incorrect tooltip focus display. |
Let's leave it for now then. That's still a huge number of issues resolved. Nice work guys! |
open={open} | ||
> | ||
{actions.map(action => ( | ||
<SpeedDialAction | ||
key={action.name} | ||
icon={action.icon} | ||
tooltipTitle={action.name} | ||
onClick={handleClick} | ||
onClick={handleClose} |
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.
Might it be more helpful to have a click handler that shows how to identify which action has been clicked, before it calls onClose?
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 could help, it would make the demo a bit more verbose, but could teach people a valuable pattern.
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.
From (past) personal experience, it's the kind of thing React beginners struggle with. I think it might be worth a little verbosity.
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, I think that people can leverage index based handler when displaying data from the server, for instance, in the case of inbox (R.I.P.), the most frequent contacts. Or in the case of Google Calendar, I would expect each action to have a named custom handler.
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'm not sure how to action this comment. I would expect most people to have a fixed set of options (not using an array). However, our demo is using an array for the sake of minimizing the demo length. I believe these two objectives contradict themselves.
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 think the point is that the click handler does not handle each action differently which should be the most common use case. Otherwise why have a speed dial if every action does the same (which only closes at the moment). I would expect that you want to dispatch some action. It would be nice if this demo would handle that case.
At least this is how I understood @mbrookes
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.
Ok thanks, this sounds good 👍
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.
@eps1lon Yeah, that's the crux of it. I took it from @oliviertassinari's comment that in real usage you wouldn't use a mapped array, but would compose each action component. If each then calls a different click handler, the issue goes away.
I had pictured a common handler that dispatches a different event according to the calling action.
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.
Just use an inline handler that captures the action. A mapped array is the first iteration you would do. The rest is premature optimization.
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'm going to merge, I think that we can apply the handler changes in another pull request :).
36e54c0
to
ba11e84
Compare
ba11e84
to
81a92f8
Compare
Thank you for your work, everyone! SpeedDial is very helpful to us. |
Is there now a way to disable open/close on hover? |
@lsnch Right now, you can use the first event argument and look at |
It seems there's something async going on, maybe the callback gets delayed for the sake of animation. |
@lsnch Oh, thanks for reporting it. Yes, there is an async logic to debounce events. In this case, I would propose the following:
A proposal to double-check with @mbrookes. If we agree, would you be intersted in submitting a pull request? :) |
Sounds good. |
Yeah, absolutely, I'll give it a go. |
@lsnch Will you have some time in the next few days? :) |
Yeah, sorry I took so long, didn't realize it was such a minor change. |
Thanks for all of this work. I'd stopped using SpeedDial a while ago due to it not working right on touch-screen desktops. Gave it a try today and it is working wonderfully. |
@acroyear We are happy to hear it :D. |
Reimplementing #12870 with the updated material-ui.
This updates persistent tooltip styles to match the material design guide (https://material.io/components/buttons-floating-action-button/#types-of-transitions).
For people updating their code from @material-ui/lab@4.0.0-alpha.26 to alpha.27, the following diff should be enough: