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

[bug] Fixing search item in menu #6027

Merged
merged 4 commits into from
Mar 13, 2019
Merged

[bug] Fixing search item in menu #6027

merged 4 commits into from
Mar 13, 2019

Conversation

Phoenixton
Copy link
Contributor

Issue: #5772

What I did

Quickfix of issue #5772 , the search item in the menu bar is now working. Added an API function in lib/ui/src/core/layout.js that focuses on an element with the given id, if that element is focusable. There's room for an API that would handle focus (and probably other UI features) of more elements than what's right now available. Also, quick refactor via the created function.

@tmeasday
Copy link
Member

tmeasday commented Mar 11, 2019

@Phoenixton do you think maybe it would make sense to add an extra layer here? I don't love the fact that we ended up encoding the id of the search field in two different places.

Maybe

  • In layout.js - api.focusOnUIElement(..) + api.focusSearch() (which calls the former)
  • In shortcuts.js - search key handler that calls api.focusSearch in a setTimeout (to avoid event ordering problems).

PS -- should the code that toggles fullscreen / nav also be in the api.focusSearch() API? I guess it is not possible for the menu to be open unless we are in the right state already, but it feels like that doesn't really belong in the keyboard shortcut

@tmeasday tmeasday added bug ui patch:yes Bugfix & documentation PR that need to be picked to main branch labels Mar 11, 2019
@tmeasday tmeasday added this to the 5.0.x milestone Mar 11, 2019
@Phoenixton
Copy link
Contributor Author

@tmeasday Thanks for the comment! Hmmm I agree that a better abstraction is needed, especially regarding the id, yeah. However, if I understand you correctly, your proposal means that if tomorrow we were to add another search bar (that wouldn't browse the stories but for example the addons, just for argument's sake), we would need another function in layout.js named for example api.focusSearchAddon() which would call focusOnUIElement(...) with the appropriate id. I'm not sure it's strictly better, although I hear you that hardcoding the ID twice is bad practice.

For your PS, I completely agree. I ended up thinking the same thing "anyway, if we're in the menu, we can't have fullScreen == true", but like you, I believe it's not in the best place it could be.

@tmeasday
Copy link
Member

🤷‍♂️ We could also export a list of focus-able element ids somewhere?

@Phoenixton
Copy link
Contributor Author

Yep, was my next suggestion. Sure seems like a nice and tidy way of handling it and maintaining the ids. And that way you keep a single neat function and .focus() checks for you if the element is focusable anyway, so no worries on that side. I like it, but I'm unsure of where it would be most appropriate to put that id list if we end up going that way. If we do, though, I can work on the ID refactoring at the same time.

@tmeasday
Copy link
Member

tmeasday commented Mar 11, 2019

There's probably a typescripty way to do it but i would probably just add api.focusableUIElements = {storySearch: '...'} in layout.js. What do you think?

@Phoenixton
Copy link
Contributor Author

I need to check out Typescript so no idea on that part either, but yeah, either a focusableUIElements list in layout.js or an external file handling them, both are completely fine. To be honest, I was even going for a UIElements list, no extra need for the focusable part (as I said, .focus() handles the verification). I like having as little as possible hardcoded strings in my code, though, so that's me. We can try it first with the focusable list as you suggested!

@tmeasday
Copy link
Member

Whatever you think is best is OK by me!

@Phoenixton
Copy link
Contributor Author

On it 👍

@codecov
Copy link

codecov bot commented Mar 12, 2019

Codecov Report

Merging #6027 into next will increase coverage by <.01%.
The diff coverage is 10%.

Impacted file tree graph

@@            Coverage Diff             @@
##             next    #6027      +/-   ##
==========================================
+ Coverage   34.92%   34.93%   +<.01%     
==========================================
  Files         648      648              
  Lines        9518     9519       +1     
  Branches     1352     1351       -1     
==========================================
+ Hits         3324     3325       +1     
- Misses       5577     5578       +1     
+ Partials      617      616       -1
Impacted Files Coverage Δ
lib/ui/src/core/shortcuts.js 20% <0%> (+1.18%) ⬆️
lib/ui/src/containers/nav.js 11.76% <0%> (-0.74%) ⬇️
lib/ui/src/core/layout.js 16.66% <16.66%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 26a822a...bdfb720. Read the comment docs.

@Phoenixton
Copy link
Contributor Author

Phoenixton commented Mar 12, 2019

@tmeasday If you wanna take a look, I added a temporary focusableUIElements array in layout.js

I'm not entirely sure that this should be here, tbh, but this was the best I could do off the top of my head to reduce the back and forth of variables. I'll take a closer look tomorrow but do tell me if you agree on principle.

I used the focusOnUIElement(...) function a bit more, too, which is reflected in the fact that you have a couple more ids in the list.

Edit: On a side note, we could attach a bit more info to the elements in the array. For example, in shortcuts.js, you've got

case 'focusIframe'

where instead of focusing the element you retrieve via the id, you focus on element.contentWindow
This could be added to the array via some kind of struct if we wanna abstract it further and handle everything via id.

Copy link
Member

@tmeasday tmeasday left a comment

Choose a reason for hiding this comment

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

Great stuff. LGTM!

I'm not really sure about the existing code; I didn't write it, I just moved it around! I think it is up for any kind of refactoring that makes sense.

@Phoenixton
Copy link
Contributor Author

Nice, thanks a lot. I'll take a closer look tomorrow and open another PR if refactoring ends up being needed. Thanks again for your time :)

Copy link
Member

@wuweiweiwu wuweiweiwu left a comment

Choose a reason for hiding this comment

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

Little changes. But LGTM

@@ -149,6 +156,17 @@ export default function({ store }) {
});
},

focusOnUIElement(elementId) {
const focusableElementId = focusableUIElements[elementId];
if (focusableElementId == null) {
Copy link
Member

Choose a reason for hiding this comment

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

nit: even if undefined == null can we change this check to be !focusableElements

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, it's what it was before, I was unsure of JS' best practices for that. Thanks!

if (element) {
element.focus();
}
fullApi.focusOnUIElement('storyListMenu');
Copy link
Member

Choose a reason for hiding this comment

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

can you pull these constants out to be shared between modules?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure thing, on it. 👍

Copy link
Member

@ndelangen ndelangen Mar 12, 2019

Choose a reason for hiding this comment

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

Yes, we'll change it to an enum later 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmmm then do you want me to just export them for now?

@Phoenixton
Copy link
Contributor Author

@wuweiweiwu If you wanna take a look. Exporting the variables lets up refactor the test, I like it a bit better that way but if that wasn't what you had in mind, hit me up. 👍

@wuweiweiwu
Copy link
Member

@Phoenixton looks awesome!

@wuweiweiwu wuweiweiwu merged commit 01a9f24 into storybookjs:next Mar 13, 2019
@shilman
Copy link
Member

shilman commented Mar 13, 2019

Awesome possum 💯 looks great 👏

@shilman shilman mentioned this pull request Mar 14, 2019
@shilman shilman added the patch:done Patch/release PRs already cherry-picked to main/release branch label Mar 15, 2019
shilman pushed a commit that referenced this pull request Mar 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug patch:done Patch/release PRs already cherry-picked to main/release branch patch:yes Bugfix & documentation PR that need to be picked to main branch ui
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants