Fix user feedback on clicking Audit CSV export button

[awwaiid]

Summary

Steps to reproduce

• Sign in as a Bank user ([email protected])
• You'll need an Audit
  • Inventory -> Inventory Audit -> New Audit
  • Select a storage location (ex: Bulk Storage Location)
  • Select an item that we are auditing form the dropdown (ex: Adult Briefs Medium/Large)
  • Enter any qty as how many we have (17)
  • Click Confirm Audit and confirm in the pop-up
  • This shows you a list of items you audited and items you didn't audit, go to the bottom and click Finalize Audit and confirm
• Now that you have an Audit, navigate again to Inventory -> Inventory Audit you will see your audit
• Click Export Audits
• The button changes to Please wait... while it generates the CSV
• .... but it never changes

For this, ideally the button would change back to Export Audit after the CSV has been generated.

Things to consider

We aren't sure exactly how to detect that the CSV has been generated; if it gets complicated please share here what your plan is.

Also consider if there is a general solution for all of our Export CSV buttons.

Criteria for Completion

• [ ] Button changes back
• [ ] System test that verifies the behavior
• [ ] No update needed to user guide

[bellitabellota]

I would like to give this one a try.

[cielf]

Please do!

[bellitabellota]

1. The first idea I came up with would be setting a cookie before calling send_data in the AuditsController#index action.

And then adding a stimulus controller which, once the button is clicked, starts an interval to check if the logic in the format.csv block has been run by checking for the cookie. If so, it would re-enable the button and reset the cookie.

---

2. However, by having a closer look at the current logic, I noticed that the button (which actually is an <a> tag) is disabled by using disable_with in the _link_to ui helper:

disable_with seems to be handled by the library @rails/ujs. Below is a screenshot where I inspected the click Event Listener of the "Export Audits" button which led me to the assumption that it is the @rails/ujs library that handles the disabling:

So I started reading about disable_with. In particular, I found this article very helpful. It mentions that when "the request is done, an ajax:complete event will be fired and Rails UJS uses that to re-enable all the elements doing the inverse process".

Currently, the button does not send an AJAX request but it does when adding data-remote="true". However, we should also consider that when the request is processed very quickly, the user barely gets the time to read the button text:

https://github.com/user-attachments/assets/70f745a2-190c-47fc-b478-0634eef87c37

So if we go for this approach, we should find a way to add some delay before the button is re-enabled to avoid the user seeing a flickering button.

---

Both approaches should be applicable to other Export CSV buttons as well.

What do you think @awwaiid should I proceed with one of the described approaches?

[dorner]

I'd rather make use of something like an Ajax complete event than messing around with setting cookies, which is a lot harder to share across other export buttons.

If we change this to data-remote=true - does the CSV download still work as expected?

My hunch is we should be able to do something with Turbo events if that's what's powering the link.

[bellitabellota]

@dorner Thank you a lot for your thoughts and guidance.

Indeed, I could not get the CSV download working with data-remote=true.

I tried to make use of the Turbo events in the Stimulus controller. However, although Turbo is enabled on that page, it does not seem to handle that request (probably because it is requesting a csv format rather than HTML?).

However, I got a working solution by adding a 'click' EventListener and making an Ajax request in a Stimulus controller. Please find the details in the Draft pull request I added a few minutes ago.

In order to proceed, I would need to know:

• if there are implementation details that should be changed,
• if a totally different approach should be taken or
• if we may go ahead with the current approach.

The current approach has some caveats as described in the linked draft pull request. One of those is that, given that the Ajax request is handled in the Stimulus controller, there seems to be no way to implement a system test (please correct me if I am wrong).

[dorner]

To be honest, I think this is over-engineering a problem that we can fix by just skipping it entirely. If you pass data: { disable_with: false } to the button, it should just not disable it at all. Since this is an export button and isn't executing any write operations, I feel like it's pretty safe to just not do debouncing in this case due to the extra complexity.

@awwaiid thoughts?