I have been using the Alethes Pages package, during development had a couple minor issues that I was able to work-around, but now on live server I’m finding some issues that are not ideal.
The biggest issue is, other users searches affect ALL users. Meaning if one person is browsing the entire collection on Page 1, and another user applied some filters and is on Page 3, the first users, the first users page is going to get changed, and/or the pagination buttons on bottom disappear completely?
I checked the options and it doesn’t seem there’s any options to control this?
I’m not sure how to move forward regarding this. Any suggestions, or any pagination packages that have worked for other users ideally in a live environment supporting multiple users at once?
Thanks
Any ideas?
I find it hard to believe that noone else encountered similar issues!
Pagination is a required feature in almost every project. Considering Meteor’s pub/sub needs very specific methods of pagination, I’m surprised there’s no documented solutions on the forums here…
I’ve never used this package but found it hard to believe that it’s not possible to limit client filters. Saw this in the issues and thought it may be helpful.
I was surprised too. Seems pretty basic functionality.
We are only using the package in the intended method described in documentation (with a slight work-around for occasionally having infinite loading - on the github issues page you can see the post regarding it).
Yet even we disabled the work-around, the issue still persisted. I tried the fork (electronifie pagination) and issue still persisted…
It’s the end of the day now so I do not have time, but I will check that post in the morning and see if it solves the issue.
I will update here with the results incase others have the same issue!
Thanks for the link!
1 Like
So I just gave it a try, seems to be an error with the line:
var _orgId = App.users.getOrgId(sub.userId)
App.users.getOrgId is not recognized. I tried googling it, the only results are to the github link you posted.
Any idea what that’s for? Is it outdated Meteor API or…?
Ah, no so I think that is just a demonstration of an auth function, and getOrgId is probably an internal function that the poster is using.
The valuable part:
Okay, it being an internal function did not seem the case since 1 or 2 other users on the github topics also pasted their code which had the same line. Those were the only search results to come up on google, so it didn’t seem related to a single user.
With that said, there’s absolutely no information on the Pagination object’s userSettings. It doesn’t seem the be mentioned at all in the documentation. I’m not sure how those users found out it even existed…
So I guess I will just start experimentation & use the examples as reference.
(Still very surprised these issues are not common knowledge, since the package is pretty popular… and user-based filtering is not even on by default, and not mentioned in documentation AT ALL… very strange!)
Yeah, honestly, after reading through the documentation, I’m having trouble seeing the use cases for this package outside of something like a public blog. It reminds me of the datatables packages – hacking it to fit your use case may be more difficult than just rolling your own.
Yeah, I just tried using the example from here - https://github.com/alethes/meteor-pages/issues/209
It works if trying to just filter based upon only seeing own user’s posts, but the search filters are still applied to every user. If I’m on page 3 and my co worker applies some search filter on his client, my page buttons disappear immediately.
It’s a shame, because the package actually works very nicely aside from this one issue. How it downloads neighboring pages is very nice for a smooth user experience.
It really boggles my mind that there doesn’t seem to be a solid pagination package for Meteor… It’s basic functionality you literally see on almost every site, and it’s not exactly as straight forward to make with Meteor’s pub/sub system. I would think there “has” to be a solid solution out there… I’m just not sure why this subject seems to be rarely mentioned…?
I’d expect it to be a very common issue, so I can’t shake the feeling that something doesn’t add up when it’s so hard to find documentation on these issues…
Even the github discussion doesn’t really add up. They are speaking about userSettings.filters like it’s common knowledge… yet it’s mentioned absolutely nowhere? I’m not sure what gives, lol
Still no progress with this issue.
Since none of the advice for search filters applying to only yourself, I have no choice but to actively try to find a Meteor pagination package that actually works, and does not have this issue, but no luck so far…
Sorry to see this. I think it’s unfortunate, but many of these packages are just too difficult to repurpose for anything outside of their (sometimes narrow) original use cases. The datatables packages are the same, in my opinion. Amazing and efficient out of the box but just too time consuming and difficult to customize.
Yeah, it’s understandable to a point.
But for there to be absolutely no reliable packages for a feature as important as pagination out there in the community at all…? That just seems so strange to me!
I mean seriously, how many projects that have even a low-medium amount of data, don’t require some form of pagination?
Never used it but this package seems to support client filters?
2 Likes
My only problem with that one is it seems to only have a bootstrap implementation for Blaze, but I can give it a go and possibly work-around that.
Thanks for the share!
1 Like
Hm, looking through again I only see mention of server-side filters. Hope that ends up not running in to the same issue…
I will check out the demo project to confirm.
Hm, it seemed to me that you could use these methods client-side to adjust filters/fields/etc?
I’m checking now. It’s a bit ambiguous, because it does have an option for client side filters.
But the primary question is, if you set a filter to “X: true” - does it actually filter this & only pub/sub to the data with X:true, or does it subscribe/download the entire collection and only filter it client side? Or are the client filters actually being applied to the server filters and controlling everyones output?
Also generating a large data set to make sure no other issues.
Will follow-up with the results here to hopefully help others!
If you take a look here, it looks like the collection.find code on the server-side is taking into account the concat of all of the filters, so that is a good sign.
However, this package also relies on https://atmospherejs.com/tmeasday/publish-counts, which has acknowledged issues with large datasets, so be wary of that. This could be an alternative, but I’ve found that using https://github.com/matteodem/meteor-server-session and setting connection-specific Session vars to be a better approach.
Looks like Counts is minimally relied on in this package, so if you run into issues let me know and I can probably fork the package with a server session implementation…
So far it seems it’s limited to 4000 pages - not too bad and filters should solve that problem.
There’s a definite delay when loading with a larger dataset - but it doesn’t seem too bad so far. I will need to do further testing and this is the end of the work day for me.
I will follow-up further on Friday!
Thanks again!
2 Likes
So I finally got around to testing the package, here’s the results at this point:
With a large data schema and 100,000 inserts in to the collection, it seems to be performing decently with appropriate filters.
One notable issue is on first-load, there’s still a time out of maybe 3-5 seconds. This time is affected by filters and sorting.
If using it completely unfiltered, and/or with sorting features on many pieces of data, the delay is as mentioned.
If using appropriate filters, the display time is acceptable.
The filters ARE client side, and DO work correctly with multiple users.
Potential Issues:
-
Already mentioned delay on initial page load with larger data sets.
-
Template.instance().subscriptionsReady() does not seem to work with it, so I’ve yet to find a way to add a “loading” screen for the pagination.
-
Potentially major issue - It seems Regex filters are not working. So at this point, I haven’t figured out how to do a case insensitive/partial search. All attempts at Regex have returned nothing so far.
Conclusion: The package seems to work pretty well, and issues can be acceptable in most cases. Not the best suited for large data sets without filters, but in most use cases, you would have filters if your using a large data set.
Right now, the only deal-breaker is the lack of regex filters. I’ll still be working on a solution to this! If anyone has any advice it would be appreciated!