is there a pagination ? about bull-board HOT 12 CLOSED

hey @abdolrhman! thanks for opening the issue!

we don't have pagination yet 😅 if you have some time to implement it please feel free to do so! let me know if you need some help

from bull-board.

Thanks buddy,
I will give it a shot,
This package did really helped me alot,
Would be also great if u could helped me to contribute in this great thing :))

from bull-board.

glad that this has helped you! 🤩

you can open a PR starting the changes and we can iterate on that! the UI part would be trickier than allowing pagination on the API itself, so I would say starting from the back-end could be easier!

from bull-board.

i am trying to do it from the front end, by adding
` const [currnetPage, setCurrentPage] = useState(1);

const [jobsPerPage, setJobsPerPage] = useState(10);`

in useStore file,
so that for each click i set a new current page and jobs for that page,
but this requires me to change a little bit in the cycle that is already exist,,

from bull-board.

also i have a poor knowledege in React or in front-end in general, but am trying my best :)

from bull-board.

hey @abdolrhman, sorry for the late response!

Regarding the pagination, the two states you mentioned look like a nice start!
We would then pass their values to the update method so we can read the new query parameters in the route and use then in the getDataForQeues.js file.
Let me know if I can help with anything else 😄

from bull-board.

I think pagination would be super important! especially for larger queues!

from bull-board.

Pagination start to be a thing for us. We are wondering how we are going to add it.

from bull-board.

If queue > 1000 registers loading all list in one page?

from bull-board.

Hi @vcapretz I found this issue interesting and would love to work on it. Really nice package by the way!

Apologies for the hustle! Just managed to use the latest alpha 7 package now. Turns out some issues were on me. Except the Cannot find module 'bullmq' issue, which I bypass it by installing bullmq for now (I'm using Bull 3).

But I wonder which version tag should I work on. In my project I'm using bull board 0.6.0 w/o any issue. When I fork the repo I realize master is now in v1.0.0-alpha.7 and contains a TypeScript rewrite.

I assume it'd be ideal if I start working on the latest alpha 7 code base, since it introduces many changes and some file names have changed as well. But when I tried to use the latest alpha 7 in my project, I got some errors especially for 1) Cannot find module 'bullmq', 2) UI now no longer exist and 3) some typing errors using setQueues. I see the readme documentation hasn't updated to provide instructions for breaking changes in v1 / alpha so got stuck there and couldn't do testing / debugging.

I was able to switch back to 0.6.0 in my forked repo, and published it so I can use the forked package in my project and debug there. But I wonder will there be any issues if I start working based on the 0.6.0 release commit? One concern is getDataForQueues.js file no longer exists in alpha 7, and changes to that file could cause merge conflict. I wonder what would you advise to do in order to get started on the code base?

from bull-board.

hey @rivernews, thank you very much for being willing to work on this issue, that would be awesome.

so yes, we are rewriting the lib in TS and quite a lot of things changed, we were even wondering if we should drop support for bull 3 altogether and only support bullmq, but I'm not so sure about this.

the alpha version is very unstable and we need more work on that, if you want to please create a branch from the latest tag we have (https://github.com/vcapretz/bull-board/tree/v0.6.0) and I can publish a new version on top of that instead of waiting indefinitely for the alpha to become a beta and then a proper release.

Let me know if that works for you! but I believe it's the way to go so we can release this amazing feature as soon as possible 😄

from bull-board.

@vcapretz Thanks so much for the context! I'll keep that in mind, hopefully making the paginator component its own file to mitigate the later on porting issue.

Just completed a rough draft version in Typescript, but I agree it's better to be based on 0.6.0 and aim on that first. I'll convert the draft to a javascript edition (not sure what's a better way to do this but perhaps removing the typings first) and do some refinement.

from bull-board.