-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
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
[JENKINS-62024] Add quick filter box for dropdown lists in hetero-list #4688
Conversation
Reviewer note: This change will not be reflected in the PR tester by default. |
I don't think modifying the YUI code is a good approach. It's library code that's been stable for 12+ years, so I'd be very wary when making the decision to touch it. The DragDrop widget also builds on the YUI code, but does so by decorating it: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/lib/form/dragdrop/dragdrop.js. This, if possible, is the approach I suggest. Otherwise I'd just build a new dropdown widget altogether. |
We've done it before 🤷 It's not like the library is pristine. |
Still, I'd suggest trying the other approach first. |
@fqueiruga I was looking for an example of decorations on YUI but failed. Thank you for providing the DragDrop example. I'll work on it. |
ea5506f
to
d2dc93b
Compare
Hi @fqueiruga, I pushed a new commit that wraps around |
d2dc93b
to
4d53f5f
Compare
@johnlinp I don't feel confident enough (with my UI knowledge) to approve, but it looks good. Maybe you could add some explanatory comments to the code and some screenshots where the functionality can be observed. @fqueiruga could you maybe have a look? The current status uses your preferred approach. |
4d53f5f
to
f85ca83
Compare
Hi @fqueiruga, Would you please review my PR? Thanks! |
I think the approach is good even though the styling is a bit rough, needs some paddings :D. Did you consoider only applying the filter when the number of options is over 5 or something? There are many hetero lists with only 2 options and that may be overkill. |
Hi @fqueiruga, Thank you for the review. Yes, I think it makes sense to only apply the filter when the number of options is at least 5. I'll push a new commit to implement this. |
ba67395
to
afa1d5d
Compare
@johnlinp is this still something we are attached to? do you have time to work on it or should we close this PR? |
@alecharp Yes, I would love to continue working on it. Let's see if the reviewers have any comments. Thanks. |
Works well 👍 UI is a touch rough but so is YUI in general. I want to update/replace the YUI menus eventually but that's no reason to delay this enhancement. Only thing I'd say is see if there's a way of disabling autocomplete/autocorrect on the filter field. |
Thanks @janfaracik! I'll try to disable autocomplete and autocorrect for this field. |
@johnlinp this is great. Could you work on the merged conflicts so we can move this PR forward. Thanks. |
afa1d5d
to
b572a67
Compare
@alecharp I've updated the branch to resolve the conflict. Thanks. @janfaracik I didn't see autocomplete or autocorrect on my end. Can you provide the reproduction steps to show autocomplete or autocorrect for the filter? Thank you! |
@janfaracik I saw in a PR that you are removing the YUI tooltip implementation. Is there an initiative to remove YUI completely from the core? The work here from @johnlinp seems to be good and could be integrated, no? WDYT @fqueiruga ? |
function _createFilter (menu) { | ||
var filterInput = document.createElement("input"); | ||
filterInput.style.width = '100%'; | ||
filterInput.setAttribute("placeholder", "Filter"); |
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 the spellcheck might just be a macOS/Safari issue.
filterInput.setAttribute("placeholder", "Filter"); | |
filterInput.setAttribute("placeholder", "Filter"); | |
filterInput.setAttribute("spellcheck", "false"); | |
filterInput.setAttribute("type", "search"); |
This fixed the spellcheck problem for me, also uses the correct input type so you get a nice little ⓧ button for clearing text 👍
Hoping to remove as much of the YUI stuff as possible eventually, might take a good while though just due to how much there is. This work is definitely good though and should be integrated 👍 |
@@ -0,0 +1,56 @@ | |||
function createFilterMenuButton (button, menu, menuAlignment, menuMinScrollHeight) { |
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.
If these functions are to be global I'd suggest maybe namespacing them. I can see createFilterMenuButton
being a name that could be easily overriden.
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's already quite a long name, I think it will be okay for now anyway. Unless you've got any specific suggestions?
My comments about holding off removing YUI are 2 years old and were of a time before @janfaracik 's amazing work. I'd say that, if possible, it may be beneficial to include this in YUI removal efforts. |
I am getting a generally positive assessment of this PR from reviewers, but on the other hand none of them have approved the PR, which makes me wonder why. Reviewers should consider providing an Apache-style vote (+1, 0, -1, and fractions) to make their assessment explicit. If the general consensus is strongly positive (e.g., explicit GitHub approvals or +1 votes), I will merge the PR. In contrast, if the general consensus is strongly negative (which I do not believe is the case for this PR!) I would close the PR. If, on the other hand, the general consensus is closer toward neutral, it would be helpful for reviewers to explicitly state which action items are needed in order to move the PR closer to the positive side of the voting number line. |
filterInput.setAttribute("spellcheck", "false"); | ||
filterInput.setAttribute("type", "search"); | ||
|
||
filterInput.addEventListener('input', (event) => _applyFilterKeyword(menu, event)); |
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.
changed to input
from keyup
so that the search clear event works
Pushed a commit to address my concerns. (also reformatted it to match editorconfig file) |
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.
Looks ok to me, this component (likely) needs to be revisited in Jan's anyway, to align it with the overhauled look of the project configuration view.
Though to note, various tests are failing.
I assume that was an issue with optional chaining and html unit =/ |
This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback. Thanks! |
Thank you @timja for reviewing my code and updating my branch! |
See JENKINS-62024.
Proposed changelog entries
Proposed upgrade guidelines
N/A
Submitter checklist
Proposed changelog entries
section only if there are breaking changes or other changes which may require extra steps from users during the upgradeDesired reviewers
@mention Oleg Nenashev
Maintainer checklist
Before the changes are marked as
ready-for-merge
:Proposed changelog entries
are correctupgrade-guide-needed
label is set and there is aProposed upgrade guidelines
section in the PR title. (example)lts-candidate
to be considered (see query).