Motivation/background:
When navigating out of a views infinite scroll enabled page to some target that was linked from inside ajax-loaded content, and then using the browser's back button, the site visitor will not find the same state on that last page as he might expect, since there is no standardized/general instructions to the browser (although some browsers figure smartly).
This is where jQuery bbq comes into play, just like with Drupal's overlay. Since overlay is a core component, bbq ships with Drupal core, too, and could probably be exploited by this module to solve the described problem.

I did not find evidence for this in a Google search, so: Has something in this direction already been considered or does a similar solution already exist? If not, I would invest some time into figuring a useful extension.

Comments

doitDave created an issue.

Sam152’s picture

https://www.drupal.org/node/2667516

Is that what is being proposed in the above issue? I'd be interested in knowing existing solutions. The plugin sounds interesting, I'll check it out.

doitDave’s picture

Exactly, I did not find that one. Consider it duplicate/related. I going to have to solve this *somehow* anyway the next days. However, that would primarily address D7. But porting around should not be the major task.

Sam152’s picture

Yeah, if you need this feature, I think the key part will be triggering views to load N pages of content efficiently and in one go, to restore the state. Simply clicking back could load the previous page from cache, in it's initial state, meaning you'll have 1 page of results, with N - 1 pages left to load from the server. Some JavaScript to trigger a load from the server, with some extra metadata about how many more results are needed and some alterations to the paging query could probably do this.

This is all off the cuff, untested thinking but it would be how I'd approach the problem. Not sure if there are any other approaches to keeping the state entirely on the client (maybe local storage)? I would likely be investigating how other frameworks and plugins have solved this before going too deeply into a solution involving the server.

doitDave’s picture

So will I, although I haven't found much yet. From inspecting popular services all I could figure was that they seem to do it just so. However, what I would have tried in a second step (I basically need the feature quickly, but would also like a smartest possible solution) were to hook into the view generation, if possible, and try to modify the query to instantly deliver all items up to the page last lazy-loaded. This remains to be checked out. :)

NB: I already considered to also include the window scroll position into the bbq state hash, so after loading, the user would find the actual state of the page as he left it.

NB2: Or do you mean some kind of client-based page caching? I would not vote too much for this. As a Twitter user, I understand that they just do so - and it makes their web client a terrible experience on slower/smaller devices. But I would still give a local cache some consideration. Pure markup is not that much of a cache load again. And the browser would figure to load required images etc. anyway.

marameodesign’s picture

Hi guys,

Is there any progress on this? I have been looking around for a while now and I can't figure out possible solutions.

Thanks