Best / recommended way to add an anchor to a generated URL

[MSeneadza]

I just discovered Pagy and I really like the performance & RAM benefits vs. Kaminari, which I've been using. I'm trying to add an anchor to my pagination links. With Kaminari I was able to do:

paginate @equities, window: 1, params: { anchor: 'results_section' }

to produce links like: https://swingtradebot.com/equities?page=2#results_section

What's the simplest / cleanest / recommended way to do the same with Pagy? I was hoping link_extra would do it but I was wrong. Would overriding pagy_url_for be the way to go?

[MSeneadza]

OK, I think I've answered this myself. I went with:

def pagy_url_for(n)
    params = request.query_parameters.merge(anchor: 'results_section', page: n)
    url_for(params)
  end

[ddnexus]

@MSeneadza: your example will work, but I am not sure you really have to override the pagy_url_for for that, unless I missed something.

The anchor segment in the URL will be maintained if it is already in the page URL.

If your pagination is at:
http://your.domain.com/some/path#anchor the links will automatically include the anchor, so by clicking for example on page number 3 you will get http://your.domain.com/some/path?page=3#anchor.

Is that working? Or do you have a different issue?

[MSeneadza]

@ddnexus That makes sense in the general case but here's my situation. Users generally enter that page via a link without the anchor. So, for example .../equities. The top of that page has a form, where they can enter search filters. The search results are paginated below the form. I added the anchor to the pagination links so that upon going to the next page the browser would scroll past the form, to the top of the results table.

But, I'm happy with overriding pagy_url_for

Thanks for the quick response.

[ddnexus]

So that is a static part of all your pagination links, used just to position the content in the browser window. Weird way to do it, but yeah, in that case the overriding the pagy_url_for is the most direct solution.

Just a suggestion: the url_for(params) is a high level helper and it is slower and uses more memory than more low levels rack methods, so you may get some small improvement if you use something more similar to the original method. Anyway, the final improvement is kind of small because thanks to the pagy_link_proc, the pagy_url_for get called just once per pagination nav, instead of once per page link. ;)

[cseelus]

An additional parameter for the pagy function like will_paginates params for arbitrary parameters would be quite helpful for stuff like that.

One use case that I can think of is when one has two collections on one page, each displayed in its own Bootstrap tab. So when you navigate the second collection inside the second tab, you'll want the second tab to be shown automatically when the next page loads, which could be easily achieved with something like this:

<%= pagy_nav @pagy, params: {active_tab: 'users'} %>

[ddnexus]

Even better (and it works already):

pagy @pagy_users, page: param[:custom_param_name]

[cseelus]

I think my comment was hard to understand. I edited the code, so it should be clearer now.

[ddnexus]

Your example <%= pagy @pagy, params: {active_tab: 'users'} %> makes no sense to me. The pagy method is a controller method that return a pagy instance and a paginated collection and you are using its output in a view???

[cseelus]

Its pagy_nav (I use a helper simply called paginate everywhere that calls pagy_nav_bootstrap_compact, so it was a little bit confusing) ;-)

[cseelus]

So no plans to enable the addition of arbitrary parameters?

See my comment above or this Kaminari issue, why this would be really helpful.

[ddnexus]

All the variables can be passed to the pagy method in the controller, when the pagy instance is created. Even custom variables/params that you may want to use for your own purpose. Isn't that enough? I mean why would you want to pass extra variables to the pagy_nav* helpers? I probably need a more detailed use case. BTW, you should open a new issue for that, because this one is closed and has not that specific topic. Thanks.

[cseelus]

That should suffice, but how would one add an anchor via the pagy method in the controller?

[ddnexus]

@cseelus Please, create a new issue for this one, because anchor and URL manipulation could be the subject of some discussion/enhancement. Also, please, add some practical example that would require adding a new feature. Thanks

[jothankele]

found out that you can use fragment: "#anchor" in your pagy() params for anyone looking

[brusacco]

So that is a static part of all your pagination links, used just to position the content in the browser window. Weird way to do it, but yeah, in that case the overriding the pagy_url_for is the most direct solution.

Just a suggestion: the url_for(params) is a high level helper and it is slower and uses more memory than more low levels rack methods, so you may get some small improvement if you use something more similar to the original method. Anyway, the final improvement is kind of small because thanks to the pagy_link_proc, the pagy_url_for get called just once per pagination nav, instead of once per page link. ;)

It's not weird, sometimes you need to show additional information on a category page, like a big header + information, and then have the listings ... so when you paginate, just go to the listing and skip the initial headers. I was requested to implement something like that.

[ddnexus]

@brusacco that's what I was thinking 6 years ago 😁

You can use :fragment now.

[brusacco]

@brusacco that's what I was thinking 6 years ago 😁

Yes :) ... sorry I was having this issue this week.

[ddnexus]

It wasn't a complain: no need to be sorry. I just meant to say that I was not getting the use case years ago, but pagy has :fragment since a few years, so I got it... finally 😁