-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
[bug] Fixing search item in menu #6027
Conversation
@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
PS -- should the code that toggles fullscreen / nav also be in the |
@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. |
🤷♂️ We could also export a list of focus-able element ids somewhere? |
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. |
There's probably a typescripty way to do it but i would probably just add |
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! |
Whatever you think is best is OK by me! |
On it 👍 |
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
@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
where instead of focusing the element you retrieve via the id, you focus on element.contentWindow |
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.
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.
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 :) |
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.
Little changes. But LGTM
lib/ui/src/core/layout.js
Outdated
@@ -149,6 +156,17 @@ export default function({ store }) { | |||
}); | |||
}, | |||
|
|||
focusOnUIElement(elementId) { | |||
const focusableElementId = focusableUIElements[elementId]; | |||
if (focusableElementId == 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.
nit: even if undefined == null
can we change this check to be !focusableElements
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.
Ah, it's what it was before, I was unsure of JS' best practices for that. Thanks!
lib/ui/src/core/shortcuts.js
Outdated
if (element) { | ||
element.focus(); | ||
} | ||
fullApi.focusOnUIElement('storyListMenu'); |
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.
can you pull these constants out to be shared between modules?
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.
Sure thing, on it. 👍
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'll change it to an enum later 👍
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.
Hmmm then do you want me to just export them for now?
@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. 👍 |
@Phoenixton looks awesome! |
Awesome possum 💯 looks great 👏 |
[bug] Fixing search item in menu
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.