[Resolved] Problems with AJAX Infinite scrolls and Masonry

[Author]

Posts

[Beda]

Can you explain to me how this shortcode works, and why it uses once "" and once not for it's attributes?
[formidable id=22 postid="[wpv-post-id]"]

This is not from Toolset, I removed it for my tests. However, it seems wrong to me. It should either use "" for attributes or similar.

I see the issue, and tried to minimize the impact of other code, so I changed the content of the View to a simple one, but I still can see the issue.

I honestly think, the approach chosen here is not proper.

I will now do this, and I apologize if this is not an immediate solution.

1. I will setup personally a website where I use Masonry.
2. I will take notes of what I do
3. If I succeed, we are all a step further and I will document this, first here, then in the Toolset Documentation center
4. If I fail, I will push for this to be possible.

For now, I have no immediate solution, and I think it is not worth to proceed in the debug of the particular approach which is in theory wrong since we do not properly enqueue and load a masonry grid.

I will be back here with proper news (which will solve this issue once and for all, for everyone)

I do apologize that most likely (I did not) no one ever fully tested this out on our end, and now it is time to do so.

BTW; I escalate this to 2nd Tier, but Since I work there as well I will proceed with you here.
I as well changed back your View to how it was.

[tianweiy]

Ok thank you Beda, let me know if you figured it out.

[Beda]

Hey, I apologize the delay here.

I have some news from my tests.

1. I took any Theme
2. Enqueued this:
hidden link
(I just created a masonry.js file, with same contents and stored in the theme)
3. Use a View and put something like this in the Loop:

<!-- wpv-loop-start -->
 
  <div class="grid">
    <wpv-loop>
      <div class="grid-sizer col-xs-4">
      </div>
      <div class="grid-item col-xs-4">
        <div class="grid-item-content">
          [wpv-post-title]<br>[wpv-post-body view_template="None"]
        </div>
      </div>
    </wpv-loop>
  </div>
 
<!-- wpv-loop-end -->

4. Fire Masonry JS in the JS section of your View:

 jQuery('.grid').masonry({
  itemSelector: '.grid-item', // use a separate class for itemSelector, other than .col-
  columnWidth: '.grid-sizer',
  percentPosition: true
});

5. Insert View to any page ==> seems to work fine

Now, AJAX pagination needs to rewire above JS in js_event_wpv_pagination_completed, not a problem:

jQuery( document ).on( 'js_event_wpv_pagination_completed', function( event, data ) {
	/**
	* data.view_unique_id (string) The View unique ID hash
	* data.effect (string) The View AJAX pagination effect
	* data.speed (integer) The View AJAX pagination speed in miliseconds
	* data.layout (object) The jQuery object for the View layout wrapper
	*/
	jQuery('.grid').masonry({
  itemSelector: '.grid-item', // use a separate class for itemSelector, other than .col-
  columnWidth: '.grid-sizer',
  percentPosition: true
});
});

This is no Problem either, unless in the AJAX pagination "Infinite Scroll".
==> If you use infinite scroll you can actually see the masonry taking effect but much delayed (it jumps)
==> Nothing can fix that, I think it’s a problem with our AJAX scroll effect in specific as it does NOT happen with other AJAX effects!

I have reported that to the developers.

[Beda]

I have some more news here, I do believe this will need a new feature in Toolset Views AJAX Front End Events filters.

See, for AJAX search, we do have filter hooks for when the search starts, collects and ends.
For pagination, we do have only a filter hook when it ends

That is the exact issue here.

Masonry is not required to replicate such an issue, not even infinite scroll, but just a simple addClass/removeClass, which fires again on the JS "end of pagination" hook.

If you do so, you'll notice that whatever you do, no matter how less the AJAX pagination Transition Effect duration is (the lower, the less obvious the issue, the longer, the b^more obvious it becomes), the addClass/removeClass fired on "Pagination complete" are actually firing... when pagination is complete. That is way too late, as we already see the results, the process is just not yet fully finalized.

Hence, we need at least one new hook there that acts similarly to "jQuery('#triggerid').click(function() {", where the code would be fired when we actually click the next-previous buttons of a pagination (hence, begin of pagination process).

That should then as well help to solve the masonry issue here, as the problem is the same:
masonry JS works, but it is called too late, when the results are there already. It should fire a bit earlier.

When using Infinite scroll we cannot listen to a button click to actually re-fire our code, which would help in a else how paginated (AJAX) View.

So, this probably will need a new feature to solve this.

I already prepared a small spec for the Developers so they can evaluate this.

[tianweiy]

Thank you very much for you help Beda, I look forward to this new feature updates.

[Beda]

Please consult the updated ticket resolution here:
https://toolset.com/forums/topic/how-to-make-post-display-like-essential-grid-layout/

Also, our Developer is adding a new JS hook at the moment a pagination starts.
This would be how you use that new hook (coming in the next release of Views)
- Create a View with the legacy editor.
- Head to the Filter editor, open the JS editor below it, and head to the Frontend events button: click it.
- Check the option for the "The AJAX pagination has started" and insert the callback.
- Add some code so you know that the event was triggered.
- Complete the View, use AJAX pagination and make sure you have at least 2 pages for it.
- Place the View in a page, trigger the pagination

Now, this will no help to solve the core issue you reported, see ticket summary. That part can simply not be resolved without any delay in the "building process" of the masonry layout.
But the above hook can help expedite it more, cutting down the wait time.