5 ms·
I once decided to write my own UI pagination component. I thought it would be fun and, why bring in a library for something so simple? Three years later, we now
by jaeming 6y ago
I once decided to write my own UI pagination component. I thought it would be fun and, why bring in a library for something so simple? Three years later, we now use this component for all our pagination. Probably four of us know it really well by now as it turns out, there have been many bugs around it. Turns out pagination was not such a trivial problem to solve when you consider all the edge-cases and crazy PM requirements.
Every once and a while some engineer who's fixing a bug on it will ask, "why in the world did we write this? Why don't we just use this bootstrap pagination instead?". I ask in return, "would it fix the bug you currently have with it?". Every single time the answer has been no. It's almost always centered around the state of how the parent component is using it. I wrote with the intention of using querystrings to store pagination state in the url, but someone else at some point decides to store their pagination data in memory and just adds a few props and now it's doing it two different ways, etc...
I think the criminal offense here was not writing pagination from scratch. It was that I didn't extract it into a library and write some basic documentation.
- akvadrako 6y agoIt does sound like you’re agreeing with the premise of the article. Pagination is hard but it’s even harder to find a library that meets all your requirements and doesn’t have bugs.