(This question pertains to the react-virtualized library)
I have a component that uses <List> to display several categories of items. The resulting output looks something like:
Jump to: Planets, Nebulae
PLANETS
- Mercury
- Venus
- Jupiter
- ...
NEBULAE
- Horsehead
- Ant
- Boomerang
- ...
I'd like to use the "Jump to" links to scroll to the start of the corresponding section in the list. If I scroll around some I'd like subsequent clicks of the jump link to take me back to the section.
The first time I click the "Nebulae" link it works fine, but nothing happens on subsequent clicks. I assume this is because scrollToIndex is a prop and doesn't change after the first click. I've tried using forceUpdateGrid but it doesn't seem to reset the scroll position.
Is there a way to jump to the same index multiple times in a row?
Unfortunately, this is a limitation of the props approach. (react-virtualized only manually scrolls when it detects a new prop. Otherwise, users would be unable to scroll with their mouses once an initial prop was set.)
One way to work around this is to unset the scrollToIndex prop once you've set it (so that if you then reset it, it will still be a new value). Temporarily unsetting it (aka resetting it to undefined) will have no affect on the list either so you should be fine.
Related
I am trying to save the scroll position of a page, when we go from that page (a product list) to a product, and then back to the product list. The only scenario this scenario should occur is when going from prodlist to prod to prodlist (pressing back).
My first thought was to check the URL from history in javascript, but history.back is not read, it's only action.
you can use jquery and call Position method or. Offset method on the window.
And get x and y from top and left.
Then store the x, y into a localStorage.
Localstorage is for HTML5 very easy.
And when user back to old page, read x, y from. Localstorage
Example : localStorage. SetItem(name , value);
LocalStorage. GetItem(name );
Okay, we've found a solution. Apparently we already had an implementation of breadcrumb navigation, so I simply just pulled the middle element (we have 3), to check where the user was before the product. If the back button is pressed, we have our filters preserved.
Therefore, the only thing here was to query for products on the productlist equal to the middle href in the breadcrumb, and scrollTop to the product.offset().top, and bam.
Have a good day whomever reads this.
I have a row of slick items, and after loading them, I would like to go to a pre-selected section of items. There are 6 items per page and I would like to go to item 8, let's say.
I change the current-index attribute to 8.
This unfortunately works for a second...then it goes back to zero (I have it printed out). This also appears to break my next/prev arrow functionality, it always resets to zero.
I would have liked to use slickGoTo, but that method is not made available via angular-slick
So I have this issue with accessibility where we need a table's data to be focusable by row. To accomplish this, our first instinct was to set a tabindex on the <tr>. At first, this seemed to work just fine. Unfortunately, the data is loaded into the table via ajax and this causes issues since the data has no awareness of tabindexes already set on the page. So for instance, let's say that the page index look like this:
1 2 3 [ ??? live data ??? ] 4 5 6
Once the data for the table is loaded, the indexes end up looking like this:
1 2 3 [ 1 2 3 4 ] 4 5 6
So now, when the user tries to tab around, the first index is at the top of the page, the second index is inside the live region, then the third is at the top of the page, and the fourth is inside of the live region and so on. Essentially, it indexes all the 1s in order, then the 2s, etc.
How do ensure that the table data is tabbable in the correct order once it's loaded?
So far, my first idea was to write a script that basically grabs everything with a tabindex and then resets the order to include the new indexed elements. This sort of works, but only if the tab indexes are in alignment with the DOM order (default/natural).
Any ideas/solutions for this?
UPDATE:
I just tried setting all of the row indexes to 0, hoping that it would just make it focusable and insert it into the "natural flow" of the tabindexes. This feels kind of weird though. Is the right approach?
As a best practice, rely on the natural tab order and don't use tabindex in this manner. It will be a nightmare to attempt to set and manage the tab order manually - definitely an anti-pattern.
Screen readers already supply table navigation tools that allow users to navigate by row and by cell, so there is no need to make TR's focusable in this way.
Table nav commands for:
NVDA: http://community.nvda-project.org/documentation/userGuide.html#SystemCaret
JAWS: http://www.freedomscientific.com/Training/Surfs-up/Table_Reading_Commands.htm
VoiceOver: https://www.apple.com/voiceover/info/guide/_1133.html#mchlp2723
Looking for a way to keep track of clicks in JavaScript. I have a series of javascript controlled sides in separate div wrapppers. I'll need a counter that will keep track of the previous slide number that was clicked. This will be used to fade out the previous div when the new div loads. The HTML page will not reload so I don't think I can use the browser history function as an option. I really only need to know the previous slide number since the slide numbers can be clicked out order.
You can make a variable and update it everytime when there has been clicked on a new slide, but I think it's easier to just fade out all the slides, then fade in the slide that was clicked on.
This way you don't need to know which slide is currently shown.
Léon
If you expect the user to never reload the page, then what is keeping you from simply using a regular JavaScript variable?
var currentSlideIndex = 0;
function nextSlide() {
currentSlide = currentSlide + 1;
if (currentSlide >= slideCount) {
currentSlide = 0;
}
}
You'll find that many similar HTML5-slide packages, keep track of the current slide in the document fragment identifier of the browser. When you do that, the slideshow can survive an F5 and users can send links to the current slide by copy/pasting the address.
The best option is to use History.js, but it's a bit of overkill. The bonus is that it's semantic, and will keep the state on browser reload. Also the back button goes to the previous tab.
Other solutions depend on your setup, and your libraries that are available (jQuery, etc.). If you're using a standard plugin for something, they usually have callbacks for when the state changes. Check the API.
The basic algorithm is applying a click handler to each button. You can store a global variable containing the current state. Give a class like .slideButtons to the absolute buttons (page1, page2, page3, etc.) and a id of #nextSlide and #prevSlide to the next and previous buttons selectively. In the handler, check the class and id. If it's nextSlide, or prevSlide, add one, or subtract one, and then update. If it's one of the absolute ones, search in the parent node and count the matching classes until you find the one you're looking for. The number of your counter when you reach your pressed button is the new state. Set it, and update the slider.
I have some weird behavior with jQuery paginate plug-in (jPaginate). I need to have top and bottom pagination and I want to sync them - whenever one is clicked, the second one should be properly changed as well.
I have two divs with number_pagination class and they are initialized the same way:
$(".number_pagination").paginate(options);
Now, here where it gets weird. Whenever I click on the top div, everything works as supposed to, but if I click on the bottom one, it changes the bottom one and does the pagination, but the top one stays the same. I cannot figure out why that could be happening.
Here's the onChange function that is supposed to change both pagination divs. Note the jQuery.fn.draw function that is a part of jPaginate. This is where it applies classes and style.
var opts=jQuery.extend({},jQuery.fn.paginate.defaults,options);
var o=jQuery.meta?jQuery.extend({},opts,jQuery(this).data()):opts;
jQuery(".number_pagination").each(function(){
var obj=jQuery(this);
jQuery.fn.draw(o,obj,page);
});
Found another solution that works perfectly.
It may even work for other pagination plug-ins. It checks the class that has the currently selected page number and checks if the content matches the selected NOW page, and if it doesn't, it looks for siblings that have the correctly selected page and triggers the click event.
jQuery(".jPag-current").each(function(){
if(jQuery(this).html() != page){
jQuery(this).parent().siblings().children().each(function(){
if(jQuery(this).html() == page){
jQuery(this).trigger("click");
}
});
}
});
You should probably look at using the onChange event to redraw the other pager that didn't incur the change