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)
Expected behavior
VIS should only attach new rows but shouldn't re-add the wrapper for each page.
Related / concrete issues:
- Flex layout: #2988043: infinite scroll disrupts flex layout
- HTML List: #3042195: Append new rows into HTML list (do not create new list for next page)
- Grid (this issue): #3098132: [MASTER] Handle style plugin specific wrappers around views rows properly
- Cubeprotfolio: #2924175: Infinite scroll support for cubeportfolio enabled views
- Table: #2899705: Headers in table format repeat on load more instead of adding rows
- Masonry: #2784155: Append new rows to Masonry container when using Masonry Format
ADDITIONALLY: Support grouping #2813145: Support views grouping which is corresponding.
We should also text and fix corresponding
- #2918352: After update to Drupal 8.4 VIC replace results instead of appending
- #3078961: Clearfix on wrapper could lead to unwanted sideeffects.
- #3068579: Add a jQuery event when new content is loaded
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
Sum up all dependent issues describing this problem for different styles.- Discuss which approach is possible and most bullet-proof
- Propose solution how to set the data-wrapper more dynamically and how to override default behaviour for special styles.
- Write failing tests against the current solution for all core views styles.
- Write patch solving these failing tests.
User interface changes
None
API changes
None?
Data model changes
None?
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | views-infinite-scroll views-view-grid wrapper.PNG | 6.44 KB | anybody |
Comments
Comment #2
anybodyComment #3
anybodyComment #4
anybodyComment #5
anybodyShould 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?
Comment #6
anybodyComment #7
anybodyComment #8
volegerI 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.
Comment #9
anybodyComment #10
thomas.frobieterSo 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.
Comment #11
ravi kant commented