-
Notifications
You must be signed in to change notification settings - Fork 0
Define new helper for tab links, with aria #271
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
Changes from 3 commits
e69f1fd
2001287
f35d4ca
b261749
65fe71e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -22,6 +22,19 @@ def link_to_result(result) | |
| end | ||
| end | ||
|
|
||
| def link_to_tab(target) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Much cleaner in the view now and easier to test. ❤️ |
||
| if @active_tab == target.downcase | ||
| link_to target, results_path(params.permit(:q, :per_page, :booleanType, :tab).merge(tab: target.downcase)), | ||
| aria: { current: "page" }, | ||
| class: "active tab-link", | ||
| data: { turbo_frame: "search-results", turbo_action: "advance" } | ||
| else | ||
| link_to target, results_path(params.permit(:q, :per_page, :booleanType, :tab).merge(tab: target.downcase)), | ||
| class: "tab-link", | ||
| data: { turbo_frame: "search-results", turbo_action: "advance" } | ||
| end | ||
| end | ||
|
|
||
| def view_online(result) | ||
| return unless result[:source_link].present? | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,19 @@ | ||
| // Update the tab UI to reflect the newly-requested state. This function is called | ||
| // by a click event handler in the tab UI. It follows a two-step process: | ||
| function swapTabs(new_target) { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Great call consolidating this logic into a function |
||
| // 1. Reset all tabs to base condition | ||
| document.querySelectorAll('.tab-link').forEach((tab) => { | ||
| tab.classList.remove('active'); | ||
| tab.removeAttribute('aria-current'); | ||
| }); | ||
| // 2. Add "active" class and aria-current attribute to the newly-active tab link | ||
| const currentTabLink = document.querySelector(`.tab-link[href*="tab=${new_target}"]`); | ||
| if (currentTabLink) { | ||
| currentTabLink.classList.add('active'); | ||
| currentTabLink.setAttribute('aria-current', 'page'); | ||
| } | ||
| } | ||
|
|
||
| // Loading spinner behavior for pagination (Turbo Frame updates) | ||
| document.addEventListener('turbo:frame-render', function(event) { | ||
| if (window.pendingFocusAction === 'pagination') { | ||
|
|
@@ -23,16 +39,8 @@ document.addEventListener('turbo:frame-render', function(event) { | |
| // console.log(`Updated tab input value to: ${queryParam}`); | ||
| } | ||
|
|
||
| // update active tab styling | ||
| // remove active class from all tabs | ||
| document.querySelectorAll('.tab-link').forEach((tab) => { | ||
| tab.classList.remove('active'); | ||
| }); | ||
| // add active class to current tab | ||
| const currentTabLink = document.querySelector(`.tab-link[href*="tab=${queryParam}"]`); | ||
| if (currentTabLink) { | ||
| currentTabLink.classList.add('active'); | ||
| } | ||
| // Remove the spinner now that things are ready | ||
| document.getElementById('search-results').classList.remove('spinner'); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the manual addition/removal adds complexity without improving the outcome in a meaningful way. Would you mind either clarifying why this is better or changing it back?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let me test without this change - my thinking initially was the spinner wasn't appearing early enough - which seemed to be the case when I simulated low-bandwidth connections working locally. I'll re-check now that everything is in place.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, I've set up a comparison to show the behavior I was noticing. This applies to two review apps:
Both apps use the "simulate search latency" feature, but there's another component to this - simulating slow network connections via the browser. The test sequence is:
I've found that once I've noticed this stutter, I find that I can notice it even on faster connections - but the stutter is minimal / non-existent if we remove the spinner manually as in the other review app. I may be overthinking this - I like the approach of letting Turbo Frames control the spinner - but having seen that there are cases where the spinner doesn't get removed at the right moment, I worry about inducing confusion when a user starts to scroll after the spinner disappears, only to have a new batch of results appear after a moment. |
||
|
|
||
| // Clear the pending action | ||
| window.pendingFocusAction = null; | ||
|
|
@@ -51,7 +59,17 @@ document.addEventListener('click', function(event) { | |
|
|
||
| // Handle tab clicks | ||
| if (clickedElement.closest('.tab-navigation')) { | ||
| const clickedParams = new URLSearchParams(clickedElement.search); | ||
| const newTab = clickedParams.get('tab'); | ||
|
|
||
| // Throw the spinner on the search results immediately | ||
| document.getElementById('search-results').classList.add('spinner'); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the manual addition/removal adds complexity without improving the outcome in a meaningful way. Would you mind either clarifying why this is better or changing it back? |
||
|
|
||
| // Position the window at the top of the results | ||
| window.scrollTo({ top: 0, behavior: 'smooth' }); | ||
|
|
||
| swapTabs(newTab); | ||
|
|
||
| window.pendingFocusAction = 'tab'; | ||
| } | ||
| }); | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,14 +1,8 @@ | ||
| <!-- Tab Navigation --> | ||
| <nav id="tabs" class="tab-navigation" aria-label="Result type navigation"> | ||
| <ul> | ||
| <li> | ||
| <%= link_to "Primo", results_path(params.permit(:q, :per_page, :booleanType, :tab).merge(tab: 'primo')), | ||
| class: "tab-link #{'active' if @active_tab == 'primo'}", | ||
| data: { turbo_frame: "search-results", turbo_action: "advance" } %></li> | ||
| <li> | ||
| <%= link_to "TIMDEX", results_path(params.permit(:q, :per_page, :booleanType, :tab).merge(tab: 'timdex')), | ||
| class: "tab-link #{'active' if @active_tab == 'timdex'}", | ||
| data: { turbo_frame: "search-results", turbo_action: "advance" } %></li> | ||
| <li><%= link_to_tab("Primo") %></li> | ||
| <li><%= link_to_tab("TIMDEX") %></li> | ||
| </ul> | ||
| </nav> | ||
|
|
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 manual addition/removal adds complexity without improving the outcome in a meaningful way. Would you mind either clarifying why this is better or changing it back?