-
Notifications
You must be signed in to change notification settings - Fork 355
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
Component: confirmation menu #2723
base: dev
Are you sure you want to change the base?
Conversation
Thanks for getting this started, @crhallberg -- please let me know when you're ready for a review! Looks like there are some automated check things that need to get sorted out, so for now I'll let you work on those before I add to the to-do list. ;-) |
I'm hesitant about reimplementing the ARIA components from scratch but up until today I hadn't found a good non-React library. Today I found goodguyry's AriaComponents repository. I think these are a good step up from the Javascript W3C provides and they seem thoroughly tested and maintained. The only warning that I have is that the demo page is using the latest release, which is a year old. I manually tested the dev branch (updated very recently) and it so far fixes all of my issues with the demo (such as down-arrow events on the Tabs interface). I think this would be a good thing to adopt immediately, seeing as it doesn't require a build step, only modern JS importing. cc. @demiankatz @EreMaijala (please cc others) |
I've dug even deeper now and the results aren't as promising as expected. It seems that they deprecated |
@crhallberg, thanks for the research here! As we discussed last week, I'd be inclined to split this work into two parts: Part 1: refactor the existing yes/no drop-down functionality to a component template, so we can standardize and centralize the current behavior. Part 2: rewrite the refactored component template to use more modern behavior. Since the "part 2" seems like it still requires research, I'd favor getting part 1 done for release 9.0 and then finishing part 2 later as time permits. (And of course, maybe there's a "part 1.5" where we improve the accessibility of the existing behavior without a full rewrite of everything). |
EDIT: never mind -- the test failure I was seeing seems unrelated to this branch; investigating now, but I'll test this more thoroughly next week once whatever else is wrong gets resolved. EDIT 2: I restarted my test environment and everything is passing now. Just a passing glitch, apparently. |
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 again, @crhallberg. I've given this a closer look and found a few things to discuss. I haven't tried any hands-on testing yet, but I'll do that once we get through the more theoretical parts of the conversation. :-)
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 progress here, @crhallberg -- I think that all but one of my prior review comments are now addressed... so next steps are:
1.) Resolve conflicts (looks like just a "merge and recompile CSS" situation)
2.) Begin refactoring existing confirm menus to use this component
3.) Make sure tests pass
Let me know how I can help!
@crhallberg, I took a moment this morning to merge the latest dev into this branch to make sure styles are all good after recent changes (fortunately, they are). I also tried to start using the component to replace existing confirm menus, but I think several key features are currently missing. The first instance of a confirm menu that I could find is in the cart (cart/cart.phtml, which is also the subject of #2669 which started this whole process) for the delete buttons. I started by adding:
Above the existing delete code. The button doesn't open a menu (maybe it doesn't work inside a lightbox, or I missed some important attribute?) and it also lacks capabilities for including an icon inside the button, attaching an ID to the button, or attaching IDs to the contents of the drop-down menu. I assume that some or all of these things are required in order to refactor functionality like the cart to use this component. (But I apologize if I'm missing/misunderstanding something). |
@crhallberg, I've merged the latest dev into this PR to bring things up to date. There's still a lot of work to be done here; we'll discuss on next week's Community Call. |
I've done another round of merging and conflict resolution to bring this up to date, but several things seem to be broken at the moment. Here's the current test output:
|
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 currently running through all open PRs to prevent outdated PHP version 7 comments from bleeding back into the project. See comment below -- just flagging this so we fix it before merging.
module/VuFind/tests/integration-tests/src/VuFindTest/View/Helper/Root/ComponentTest.php
Outdated
Show resolved
Hide resolved
Thanks for the latest progress, @crhallberg. I resolved conflicts again and ran the test suite. Here's the current state of test failures:
|
Now that #3545 has been merged, there are some new conflicts to resolve here. Not sure if @crhallberg or @EreMaijala would be best positioned to do that, but either way, I'm happy to help if my help is needed... just let me know! I'll likely prioritize other tasks until somebody explicitly asks me to look at this one. :-) |
It appears to me that the |
@crhallberg, I believe that is correct. I didn't notice that the component had a different name in #3545 than it did here; sorry for failing to catch that! I believe the intent was to refactor the code in #3545 while leaving the underlying mechanics intact, and then use this PR to revise the component to use more modern methods. |
I'm pushing all theme-related PRs that were not finished in time for 10.0 to the 11.0 milestone; it will be easier to finish these if we only have to operate on one theme at a time. I think we should establish a dev-11.0 branch fairly early in the 10.1 development process so that this work can move forward as soon as possible. |
Are you sure you want to do this?