Problem/Motivation

Views Infinite Scroll (8.x-1.6) doesn't handle views style plugin generated wrappers around rows properly.

Actual behaviour

VIS attaches the new views page rows INCLUDING their wrapper element with each new load into [data-drupal-views-infinite-scroll-content-wrapper].

In my example for grid style (loaded +1 time)
Grid style vis wrapper problems

Expected behavior

VIS should only attach new rows but shouldn't re-add the wrapper for each page.

Related / concrete issues:

ADDITIONALLY: Support grouping #2813145: Support views grouping which is corresponding.

We should also text and fix corresponding

in this context for the next release.

Proposed resolution

We definitely need a flexible solution, because it might happen that the wrapper needs an update / recalculation with each new content in edge cases. Typically this shouldn't be required for regular rows and it should be enough to append new rows into the existing wrapper.

There are several ways this could be fixed, e.g.
Allow to overwrite / add the wrapper data attribute on the "real wrapper": "[data-drupal-views-infinite-scroll-content-wrapper]", document and fix it for all core views style plugins. This way the wrapper could be the wrapper returned by the views style plugin and we'd move the VIS wrapper to the lower level.
Relying on class ".views-row" for all rows to be added within the wrapper D7: #1854100: Module will not work if the ".views-row" class isn't used. and only append rows, not wrappers on ajax load.
...

Remaining tasks

  1. Sum up all dependent issues describing this problem for different styles.
  2. Discuss which approach is possible and most bullet-proof
  3. Propose solution how to set the data-wrapper more dynamically and how to override default behaviour for special styles.
  4. Write failing tests against the current solution for all core views styles.
  5. Write patch solving these failing tests.

User interface changes

None

API changes

None?

Data model changes

None?

Comments

Anybody created an issue. See original summary.

anybody’s picture

Issue summary: View changes
StatusFileSize
new6.44 KB
anybody’s picture

Issue summary: View changes
anybody’s picture

Should we close all sub-issues for concrete (core or contrib) views style plugins implementations and focus on this one with tests?
Is there an active maintainer who could add his experience with the different possible approaches perhaps with Drupal 7 experiences what works well and what doesn't to draw the red line?

anybody’s picture

Issue summary: View changes
anybody’s picture

Issue summary: View changes
voleger’s picture

I like the idea to define such a structure based on the common cases.

The grouping issue is not possible to handle on the backend: views built results based on the templates and has no idea about appending the data.

Script on the frontend has to analyze received structure and based on the available VIS attributes handle such situations.

So the first step would be define and document such structures based on the chosen views display structure.

Then we would able to define common behaviors based on different cases.

anybody’s picture

Version: 8.x-1.x-dev » 2.0.x-dev
thomas.frobieter’s picture

So sad that infinite scrolling is kinda useseless due to this issue :/ especialy for all kinds of columnized views layouts.

Not that I have a great Idea to fix this.. but I think, however the solution will look like.. it will very likely require all views plugins to add support for this, by adding for eg. a data-attribute on the right wrapper for this specific plugin.

If this really is the case, we should see, if we could bring all infinite scrolling modules together. It doesn't make any sense to me, that we have 3 (?) infinite scrolling modules, but at least they should use the same data-attribute (or whatever it will be).

As a first step, for me as a themer, it would be fine to have a data-attribute, which I can set myself in a template override, to fix unsupported views plugins.

ravi kant’s picture

Issue summary: View changes