React-instantsearch: Scrolling Top for Pagination is also Scrolling Top when a refinement is triggered

[mthuret]

What's happening:

When using <ScrollTo> to listen to a pagination change (default behaviour with scrollOn being "page"), it also scroll to if a refinement is made on any other widget if pagination was never used or if pagination is >=2.

What should happen:

When clicking on another widget than pagination no scroll should occur.

Causes:

Every time a refinement is made, the pagination is reset to 1. Therefore, <ScrollTo/> is detecting a change.

Proposal:

We could compute a boolean that compares if the state has changed (removing page and configure keys). If so, then it means that a refinement was made other than the pagination one, and therefore, no <ScrollTo/> should happen.

What do you think @vvo, @marielaures, @Haroenv ?

See: https://discourse.algolia.com/t/want-to-be-able-to-only-scroll-to-top-for-pagination-refinement/1963/2

[vvo]

Yes, I think we had the discussion some time ago, it's disturbing that it does it on every widgets. nice find

[vvo]

Do you think we went too far at the beginning? Maybe we should just have coded the scrollTo inside the pagination element with a DOM selector (dirty but that's the only usecase today :D)

[mthuret]

Maybe, I don't know if people uses it in another way

[Haroenv]

solved in #202 (for future reference)

[timkelty]

@Haroenv I'm still experiencing this issue and don't see how #202 has solved it…can you elaborate?

[Haroenv]

I'm not completely sure about the context of this issue, could you make a new issue with a sandbox to explain what your problem is @timkelty ?

[timkelty]

could you make a new issue with a sandbox to explain what your problem is

I'm working on a project with @kylewayneluck @kswedberg, hoping they can provide more context.

But from what I've seen:

• we have a <ScrollTo> component wrapping our <Hits> and <Pagination>.
• works as expected when you click a pagination link
• _The problem_: When you click a refinement (e.g. from RefinementList), it also jumps position, when it should not. Presumably this is because the ScrollTo component is configured to respond to changes in state.page, and whenever you refine, the page is automatically reset to 1.

Example:

• Go here: https://kindel.fusionarydev.com/furniture
• Click the "Designer Artist Series" refinement in the sidebar.
• You will be jumped down to the results (or where <ScrollTo> is wrapping) 👎

[timkelty]

@Haroenv Need anything more from me?

[vivek12345]

This problem is still happening. Even after updating to "react-instantsearch": "^5.3.2".
Any one with a solution for this?

[samouss]

@vivek12345 could you provide us an example of the issue? It will help a lot to better understand the context. Here is a template to avoid the boilerplate part. Thanks!

[erhankaradeniz]

What's the status of this? Because it's still happening.
@samouss here is the sandbox with the issue: Adjusted template. if you scroll a bit down on the preview and after that click on a filter, you will see that the scrollTo is triggered.

[samouss]

@erhankaradeniz Actually the issue is not tied to the ScrollTo widget. With the example even without the widget, the behavior remains the same. I've tested in multiple browsers (on a Mac) and I only have the issue with Chrome. It's linked to how Chrome deals with the focus state. It seems that it always keep the currently focused element inside the viewport.

With the RefinementList by default, the refined items go to the top of the list. Since it's the last element clicked the focus is on it. If the element is outside the viewport, Chrome scroll to it. You can see the difference with a different sort on the items. Here is an example that don't move the refined items at the top of the list. The scroll does not move anymore.

[erhankaradeniz]

@samouss thanks for the info regarding how the focus works in Chrome as I only tested this in Chrome on OSX and it is exactly as you described. Your example was also very helpful. I'm going to see what I can do with that.