we have imported a large amount of generated codes (~65.000) into multiple discounts for migration reasons.
Now we're facing performance issues when viewing a discount detail view, because Vendr is struggling to load and display the amount of codes inside that view. This sometimes causes the browser to freeze even.
Is anything planned to optimize the performance of displaying a large amount of codes inside the discount view?
We haven't got anything planned yet, but you aren't the first to raise this so I think maybe we do need to start reviewing this sooner rather than later.
Simplest thing might just be to put some pagination on the discount codes in the back office to only load several at a time, but I think that would just be a patch.
I'm wondering if at a certain point, managing discount codes in the back office isn't that ideal and maybe once you hit a specific amount, it does something like exposes a download / upload CSV UI for managing them.
I need to give it some more thought, but I'm sure there is a solution to this.
You say you are importing these discount codes from another system. How did you previously manage that many codes before?
yes, a pagination would solve this problem quite well. That's how we did it in the previous system. Basically we just displayed like 50 codes per page and had a code filter functionality, so the user doesn't have to click through all the pages to check if the code exists in the discount.
Additionally we also extended our current project with the CSV download and a code generator for existing discounts, like you metioned.
We're also planing a simple search UI, where it's possible to get the discount by code input, so the backoffice user can jump right in to the discount and check the rules and rewards.
This is quite handy, when it comes to the shopper's use case of "Hey, the code you send me isn't working, can you guys check on that?" and the backoffice user needs a fast way to gather discount settings.
But thanks for your reply, happy to hear that Vendr might have this extension in the future.
Really useful to hear how you used things previously.
My current thinking is that we do add pagination and a filter input to be able to filter the list by code. This should aid with the simple management.
I think we can then also add an export / import menu item (in the actions menu top right) to help with bulk management outside of the system.
I believe this should really then cover all bases.
I do think we might also need to tweak how we load discount codes into the Discount entity though as right now we just fetch them all, but maybe this needs to be lazy at minimum, or, maybe better, don't load them at all and they have to fetched explicitly from the DiscountService.
I'll give that some more thought though.
In your situation right now though, I think the best I could suggest is maybe split your discount up into multiple discounts with a more manageable list of codes per discount. Not ideal, but should keep things running in the meantime.
Backoffice discount detail view performance decreasing with large amount of discount codes
Hi Matt,
we have imported a large amount of generated codes (~65.000) into multiple discounts for migration reasons.
Now we're facing performance issues when viewing a discount detail view, because Vendr is struggling to load and display the amount of codes inside that view. This sometimes causes the browser to freeze even.
Is anything planned to optimize the performance of displaying a large amount of codes inside the discount view?
Kind regards,
Martin
Hey Martin
We haven't got anything planned yet, but you aren't the first to raise this so I think maybe we do need to start reviewing this sooner rather than later.
Simplest thing might just be to put some pagination on the discount codes in the back office to only load several at a time, but I think that would just be a patch.
I'm wondering if at a certain point, managing discount codes in the back office isn't that ideal and maybe once you hit a specific amount, it does something like exposes a download / upload CSV UI for managing them.
I need to give it some more thought, but I'm sure there is a solution to this.
You say you are importing these discount codes from another system. How did you previously manage that many codes before?
Matt
Hi Matt,
yes, a pagination would solve this problem quite well. That's how we did it in the previous system. Basically we just displayed like 50 codes per page and had a code filter functionality, so the user doesn't have to click through all the pages to check if the code exists in the discount.
Additionally we also extended our current project with the CSV download and a code generator for existing discounts, like you metioned.
We're also planing a simple search UI, where it's possible to get the discount by code input, so the backoffice user can jump right in to the discount and check the rules and rewards.
This is quite handy, when it comes to the shopper's use case of "Hey, the code you send me isn't working, can you guys check on that?" and the backoffice user needs a fast way to gather discount settings.
But thanks for your reply, happy to hear that Vendr might have this extension in the future.
Martin
Thanks Martin
Really useful to hear how you used things previously.
My current thinking is that we do add pagination and a filter input to be able to filter the list by code. This should aid with the simple management.
I think we can then also add an export / import menu item (in the actions menu top right) to help with bulk management outside of the system.
I believe this should really then cover all bases.
I do think we might also need to tweak how we load discount codes into the Discount entity though as right now we just fetch them all, but maybe this needs to be lazy at minimum, or, maybe better, don't load them at all and they have to fetched explicitly from the DiscountService.
I'll give that some more thought though.
In your situation right now though, I think the best I could suggest is maybe split your discount up into multiple discounts with a more manageable list of codes per discount. Not ideal, but should keep things running in the meantime.
Yes, splitting into multiple discounts is what we did to make the view maintainable - we figured that an amount of 500 codes is good to handle.
Thanks for your input!
is working on a reply...