fix(gov): add loading state to vote and deposit popups

[Hemanthghs]

closes #1035

Summary by CodeRabbit

• New Features

  • Introduced a loading indicator for deposit and vote transactions to enhance user feedback during processing.

• Enhancements

  • Improved governance user interface with new styles for deposit and vote buttons.

• Bug Fixes

  • Fixed an issue where the "Deposit" button remained active during transaction processing. Now it is correctly disabled to prevent duplicate submissions.

[coderabbitai]

Walkthrough

The recent updates introduce a loading state to the governance section of the application, specifically targeting the Vote and Deposit actions. These enhancements improve user feedback by disabling the respective buttons and displaying a loading indicator while transactions are in progress. This ensures users are aware that their actions are being processed and prevents duplicate submissions.

Changes

File Path	Change Summary
.../governance/DepositPopup.tsx	Added loading indicator; disabled button during loading
.../governance/VotePopup.tsx	Added loading state; conditionally rendered vote button
.../governance/style.css	Added styles for .vote-popup-btn and .deposit-popup-btn

Assessment against linked issues

Objective	Addressed	Explanation
Add loading state for Vote & Deposit buttons and disable buttons while loading (#1035)	✅	The changes in the DepositPopup.tsx and VotePopup.tsx files clearly indicate that a loading state has been added, and the buttons are disabled during this state, which meets the requirements of the issue.

Poem

In the realm of code, a rabbit hops around,
Enhancing buttons with a loading bound.
No more clicks in vain, no double spends,
"Patience," it whispers, as the loading ends. 🐇💻✨

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

---

Tips

Chat with CodeRabbit Bot (@coderabbitai)

• You can directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit-tests for this file.
• You can tag CodeRabbit on specific lines of code or entire files in the PR by tagging @coderabbitai in a comment. Examples:
  • @coderabbitai generate unit tests for this file.
  • @coderabbitai modularize this function.
• You can tag @coderabbitai in a PR comment and ask questions about the PR and the codebase. Examples:
  • @coderabbitai generate interesting stats about this repository from git and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit tests.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid.
  • @coderabbitai read the files in the src/scheduler package and generate README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
dev-resolute	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 2, 2024 8:30pm
resolute	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 2, 2024 8:30pm

[coderabbitai]

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between ba2ad3d and e25ab32.

Files selected for processing (3)

• frontend/src/app/(routes)/governance/DepositPopup.tsx (4 hunks)
• frontend/src/app/(routes)/governance/VotePopup.tsx (5 hunks)
• frontend/src/app/(routes)/governance/style.css (1 hunks)

Files skipped from review due to trivial changes (1)

• frontend/src/app/(routes)/governance/style.css

Additional comments: 7

frontend/src/app/(routes)/governance/DepositPopup.tsx (4)

• 4-7: The import of CircularProgress and the TxStatus enum is correctly added to handle the loading state.

• 19-19: The import of TxStatus from @/types/enums is correctly added to manage transaction statuses.

• 48-50: The loading state is correctly retrieved using useAppSelector to manage the UI based on the transaction status. Ensure that the gov.chains[chainID].tx.status path in the Redux store is correctly initialized and updated elsewhere in the codebase.

• 187-195: The "Deposit" button is correctly modified to be disabled and show a loading indicator based on the loading state. Ensure that the TxStatus.PENDING is the only status during which the button should be disabled, and there are no other statuses that should also disable the button.

frontend/src/app/(routes)/governance/VotePopup.tsx (3)

• 6-12: The import of CircularProgress, useAppSelector, and the TxStatus enum is correctly added to handle the loading state for the vote transaction.

• 54-56: The loading state is correctly retrieved using useAppSelector to manage the UI based on the transaction status. Ensure that the gov.chains[chainID].tx.status path in the Redux store is correctly initialized and updated elsewhere in the codebase.

Verification successful

The search results indicate that the gov.chains[chainID].tx.status path is being accessed in both VotePopup.tsx and DepositPopup.tsx. However, the search does not confirm whether this path is correctly initialized and updated elsewhere in the codebase. To verify this, we would need to look for the code responsible for initializing and updating the Redux store's state.

Since the search results only show the usage of the path and not its initialization or update, we should search for actions that might be dispatched to update this part of the state, such as reducers or action creators related to transaction status.

---

The latest search for Redux actions or reducers that might initialize or update the gov.chains[chainID].tx.status path did not yield any results. This could mean that the specific pattern used in the search did not match any code snippets, or that such actions and reducers are not present in the codebase.

To ensure a thorough verification, we should broaden the search to look for any Redux-related code that might be responsible for handling the transaction status without relying on a specific pattern. This includes looking for any action types or reducers that are related to transaction status updates.

---

The search results show multiple instances where txStatus is used and manipulated within the codebase. Specifically, we see references in ibcSlice.ts where txStatus is part of the initial state and is updated to various states (IDLE, PENDING, REJECTED). This suggests that the Redux store does indeed handle the transaction status, and it is likely that similar patterns are used in the governance-related slices of the Redux store, even though they are not directly shown in the search results.

Given the evidence from the search results, it is reasonable to infer that the Redux store is set up to handle transaction statuses, and the gov.chains[chainID].tx.status path is likely to be correctly initialized and updated, even though the exact code for the governance part was not directly found.

Based on this information, the review comment regarding the initialization and update of the gov.chains[chainID].tx.status path in the Redux store can be considered verified with the understanding that the specific governance-related code was not directly observed but is inferred to be similar to the patterns found in the ibcSlice.ts.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that the Redux store path is correctly initialized and updated.
rg --type typescript "gov.chains\[.*\].tx.status"

Length of output: 86

---

---

Script:

#!/bin/bash
# Verify that the Redux store path is correctly initialized and updated.
# Removing the --type option as it caused an error in the previous attempt.
rg "gov.chains\[.*\].tx.status" -g '*.ts*' 

Length of output: 273

---

---

Script:

#!/bin/bash
# Search for Redux actions or reducers that might initialize or update the transaction status in the store.
rg "dispatch.*gov.*chains.*tx.*status" -g '*.ts*'

Length of output: 51

---

---

Script:

#!/bin/bash
# Broaden the search to find any Redux-related code that handles the transaction status.
rg "SET_TX_STATUS|txStatus" -g '*.ts*'

Length of output: 2392

* 189-197: The "Vote" button is correctly modified to be disabled and show a loading indicator based on the `loading` state. Ensure that the `TxStatus.PENDING` is the only status during which the button should be disabled, and there are no other statuses that should also disable the button.

Verification successful

The initial script did not produce any output, which could be due to a variety of reasons. To ensure we have the correct information about the TxStatus enum, I will generate a new script to search for the TxStatus enum without specifying the PENDING status. This will allow us to see all possible statuses within the enum.

---

The TxStatus enum contains the following statuses:

• INIT with an empty string value
• PENDING with the value 'pending'
• IDLE with the value 'idle'
• REJECTED with the value 'rejected'

Based on this information, the review comment is asking to ensure that the PENDING status is the only one during which the button should be disabled. Given the statuses available, it seems reasonable that the button should be disabled only when the transaction is pending, as INIT and IDLE likely represent states where no transaction is in progress, and REJECTED indicates a transaction has failed and may require user intervention or a retry.

Therefore, the code disabling the button when loading === TxStatus.PENDING appears to be correct, as no other statuses seem to indicate a loading state where the button should be disabled.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that there are no other transaction statuses that should disable the button.
ast-grep --lang typescript --pattern $'enum TxStatus { $$$ PENDING $_ }'

Length of output: 73

---

---

Script:

#!/bin/bash
# Search for the TxStatus enum to verify all of its statuses.
ast-grep --lang typescript --pattern $'enum TxStatus { $$$ }'

Length of output: 357