Pnp-modern-search: Scroll issue with large set(s) of refiners

Created on 16 Jan 2020  路  11Comments  路  Source: microsoft-search/pnp-modern-search

Version used
Sharepoint Online

Describe the bug
When scrolling down, modern page becomes wacky (see attached GIF).
This happens when the Search Refiner Webpart is larger than the Search Result Webpart

To Reproduce
For a Modern Page with 1 section containing 2 webparts:
Left-most webpart:
Search Refiners Webpart
Contains 10+ refiners, of which a handful of the refiner types have 10+ values (ie in total a long list of refiner values)
Right-most webpart:
Search Results Webpart
Returns 50 items (by configuration) of 30k items

Expected behavior
No jumping up and down (ie wacky behavior)

Screenshots
map_bug_1

Desktop (please complete the following information):
Chrome

Additional context
Add any other context about the problem here.

Most helpful comment

Hi @tcskauge . This should be resolved by #73 . I've integrated @salascz suggestions. Feel free to test it out before release. I can't really test in my environment.

All 11 comments

@tcskauge Thank you for submitting this issue. Unfortunately, I can't really reproduce this behavior since I don't have this amount of data in my tenant ;). However, what I suggest is to add a new 'Show more/less' feature to each filter to limit the height when there are too many values. Probably not included in the January release but on the next.

@FranckyC I can reproduce in my tenant. If you have a long list of refinement values you get the jumping behaviour as you scroll down the werid thing is there are no additional network calls as you scroll it just seems to force a re-render which causes the screen to jump. A show more / less sounds like a good idea. Perhaps you could control this with a slider from the property pane?

@mag210 Yes I'm thinking about an option per filter with a limit of values to show. The current issue is probably due to a third party React control present in the solution. I will probably remove it since it seems to be not maintained anymore.

Thanks, @FranckyC and @mag210.
Limiting the filter will prevent the behavior from occurring when the page is loaded, but when the user wants to set a hidden filter value the unwanted behavior will occur. Hoping that MS will fix this bug, so we don't have to implement custom code as a workaround

@FranckyC sounds good to me. Happy to test against the data in my tenant when you think you're getting to a solution. Be interesting to see if it has the same behaviour when the filters are in a panel view as well

Hi guys,
we had the same issue in our company with our forked version of pnp-react-search-refiners (v3.6.3)

It looks like the issue is caused by multiple size recalculations of the same parent element (caused by Office fabric components).

I have solved it with defining new "scrollable" parent. (closer to filters)

I do not have time to make a PR on the latest modern search solution, but I would like to share my changes in Vertical.tsx file.

  1. I have added a scrollable attribute to the "verticalLayout__filterPanel__body" element. It is a key change - Fabric will not register the onScroll event to higher elements.

<div className={styles.verticalLayout__filterPanel__body} style={style} data-is-scrollable={true}>

  1. I have disabled virtualization as it creates some unnecessary space (this might not be required step for this issue)

const renderAvailableFilters = (this.props.refinementResults.length > 0) ? <GroupedList ref='groupedList' items={this.state.items} componentRef={ (g) => { this._groupedList = g; }} onRenderCell={this._onRenderCell} className={styles.verticalLayout__filterPanel__body__group} **onShouldVirtualize={() => false}** // virtualized pages creates unnecessary spaces and disables some refinements groupProps={ { onRenderHeader: this._onRenderHeader, } } **listProps={ { onShouldVirtualize: () => false } }** groups={this.state.groups} /> : noResultsElement;

Hope it could help...

Hi @tcskauge . This should be resolved by #73 . I've integrated @salascz suggestions. Feel free to test it out before release. I can't really test in my environment.

@salascz thanks for this, I just made the two changes on my forked version and it does indeed correct the jumping scroll issue as described by @tcskauge. If you add the scrollable attribute to the div you do need to turn visualization on the list off otherwise you will get some inconsistent results when you expand / collapse the filters. This seems like a nice work around, @FranckyC be interested to hear your thoughts, are there any potential issues caused by turning off virtualisation on the render for example? If not, suggest this could be a quick fix to an issue that a lot of people with large filters will be seeing

@FranckyC I typed the above before your update! Yes the solutions from @salascz do work, I'm no longer seeing the jumping behavior on my environment even with hundreds of filter values set :)

Greatly appreciated, contributors!

When is the next release, by the way?

@tcskauge Soon, maybe today or tomorrow. I have to wrap up all updates for the changelog. Stay tuned

Was this page helpful?
0 / 5 - 0 ratings