Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust status functionality for transaction component #1239

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

abcrane123
Copy link
Contributor

@abcrane123 abcrane123 commented Sep 11, 2024

What changed? Why?

  • when executing multiple transactions with EOA, we were emitting transactionPending -> transactionLegacyExecuted -> transactionLegacyExecuted
  • correct emission: transactionPending -> transactionLegacyExecuted -> transactionPending -> transactionLegacyExecuted
  • we were also emitting two success statuses: the first one contained both transaction receipts, the second one contained only a single transaction receipt.

Notes to reviewers

How has it been tested?

Copy link

vercel bot commented Sep 11, 2024

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

Name Status Preview Comments Updated (UTC)
onchainkit-coverage ❌ Failed (Inspect) Sep 11, 2024 6:29pm
onchainkit-playground ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 11, 2024 6:29pm
onchainkit-routes ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 11, 2024 6:29pm

useEffect(() => {
if (
transactionStatus === 'pending' &&
lifeCycleStatus.statusName === 'transactionLegacyExecuted'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't lifeCycleStatus already have been set by the useEffect above that also checks transactionStatus pending?

Copy link
Contributor Author

@abcrane123 abcrane123 Sep 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes but transaction status doesn't actually change. it is pending until it reaches the success state so lifeCycleStatus wasn't getting reset to transactionPending after we change it to transactionLegacyExecuted

@@ -76,6 +76,10 @@ export function TransactionProvider({
? TRANSACTION_TYPE_CALLS
: TRANSACTION_TYPE_CONTRACTS;

const [prevStatusEmitted, setPrevStatusEmitted] = useState(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can we use previousStatus, setPreviousStatus instead

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abcrane123 this approach adds more complexity to our logic, and makes it harder to mantain later.

What we should do instead, is add a persistant value inside statusData that keep info regarding the pending part.

With @alessey we are actually exploring this way of thinking for Swap and make sure become the new standard #1237

Make sure to sync with @alessey and follow the same approach.

if (prevStatusEmitted !== lifeCycleStatus.statusName) {
onStatus?.(lifeCycleStatus);
setPrevStatusEmitted(lifeCycleStatus.statusName);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are there any other use cases aside from subsequent transactions that we want to emit duplicate statuses for?

e.g. init?

I'd also add some comments here on why this is an edge case (multiple pending transactions)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also nit but if we can make this something like

if (previousStatus !== currentStatus) {
 // some comment here on edge case
}
``

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants