paging&back-button: layout lost

[mugwump]

Here's the scenario:

I've set up a pager using kaminari and added the wiselinks data-attributes (push=true, and a target='#paging-content' ), templates now look like this:

%span.last
  = link_to_unless current_page.last?, raw(t 'views.pagination.last'), url, {:remote => remote, :data => defined?(data) ? data : {}}

and the paginator is called like this:

= paginate @my_models, data: {push: true, target: "#paging-content"}

The paging itself works fine, however, the back-button shows the last page but only unstyled: only the content that is normally rendered into #paging-content is shown, the rest has vanished.

I'm not yet sure, if this is a general problem or it only does not work with a specified target (maybe anything that is less than the whole html causes this problem?!) - or if this is indeed what the back-button in this case is supposed to do?!

I've read the lengthy and tiring discussion in https://github.com/igor-alexandrov/wiselinks/issues/9, but I still hope that we can find a way to reproduce the scenario and get the back-button to work...

PS: thx for the quick "exception"-fix!

[igor-alexandrov]

Can you please try to reproduce this somehow in our demo application here: http://wiselinks.herokuapp.com/catalog

Does it work fine for you?

[mugwump]

sorry, this took me a while: The reason here is a discrepancy between the wiselinks-initialization and a target: We have several areas on the page that need to be updated separately, our approach was to leave out the target from the initialization:

window.wiselinks = new Wiselinks();

and then add a specific data-target on the link/form:

link_to_unless current_page.last?, raw(t 'views.pagination.last'), url, {:data => {push: true, target: "#my-target"}}

The back-button works, when we specify the same target in the initialization:

window.wiselinks = new Wiselinks("#my-target");

Not sure, if the back-button implementation falls back on the target that was used to initialize wiselinks? Probably need to keep track of the target for every single invocation?! (just guessing here...)

[igor-alexandrov]

Of course you are using latest version of Wiselinks 0.6.3, yes? We had such problem in older versions. As I said before, please take a look at our demo application. We have exactly the same logic as you here (pagination replaces only part of page):

http://wiselinks.herokuapp.com/catalog?page=3

And what browser are are you using?

[igor-alexandrov]

And by the way, do you have any specific caching settings in your application and on your server?

[mugwump]

I was afraid you'd say something like this :) - so I'll have to keep looking. And yes, we're on 0.6.3, no specific caching, currently running without any caching in development...

[igor-alexandrov]

What browser?

[mugwump]

there is nothing special about the @role-handling there?! We're using #id's as targets, that at least is an obvious difference...

Browser is safari, but the example is working fine in safari, it's only our own code that is screwed up...

[igor-alexandrov]

So demo works fine for you? Can you please try to replace #ids with classes for example to test behaviour?

[hmaack]

Hi @igor-alexandrov. I´ve got almost the same behavior like @mugwump it explained. I´m currently using wiselinks (0.6.4) with the latest version of Chrome and your example is working perfectly. @mugwump: I´d tried to analyse and the link should contain the option data-target='partial'. You need a partial for example _index.html.haml in your controller action. Thats it!

  new Wiselinks($('body'))

my wiselinks having standard options like yours

def wiselink_params target='#another-container', push=true
  {:data => {:push => push, :target => target}}
end

The only big difference is that @igor-alexandrov is using data-push='partial' for the pagination.

Go ahead. :palm_tree:

[igor-alexandrov]

When you are using data-push='partial' it means, that you want to render link without layout (like partial rendering works in Rails).

Can you please try to use it in your project and share results with me?

[igor-alexandrov]

Can you also try to make public maybe some code extraction from your project, so I will be able to check?

[hmaack]

@igor-alexandrov I´m totally with you! But the documentation could be misinterpreted. It sounds like there is no problem to use links like this:

<a href='/?page=2' data-target='#example' data-push='true'>foo</a>

Okay, the link is working and the JS is using the target correctly. But if you are going on page 3 for example and after that one step back (history.back), the JS dont care about the target option which was set in the a-tag before. The JS is using the default container e.g. $('body'). I don´t know if you could follow.

So I guess it makes no sense to combine data-push='true' with the data-target attribute. Maybe it is a good information in the documentation. :lollipop:

All in all you are right, using the partial attribute value like data-push='partial' is the right way for the pagination! So not a issue for me! :+1:

Anyway, a great gem, thank you for providing!

[igor-alexandrov]

Thanks! Maybe @mugwump have the same problem? And you are right, I should somehow mention about this in documentation.

[igor-alexandrov]

If you have time, please provide a pull request for README file.

[mugwump]

Yes, thx, drove us crazy that we couldn't reproduce the error: We actually changed two things at once: we added the targets to the initializations and replaced data-push="true" with data-push="partial" - and although we thought the first one did the trick, it was the partial that solved the issue for us. Thx for the explanation, really helps to understand why things were not working as expected& why things are working now!

[igor-alexandrov]

Great! Our goal now is to update documentation.