1

So I have deployed a smart contract and can interact with it via a web UI using web3.eth.contract(abi).at(address) and Metamask - so far so good.

However, between a transaction being submitted and it being mined I would like to display one message and once it has been mined another one.

I understand that web3.eth.getTransactionReceipt(txhash).blockNumber == "" until the tx has been mined. But how do I check this until it has in fact been mined using javascript and the injected web3 from Metamask?

EDIT: I am trying to make it work with promises but just can't wrap my head around how to implement it. This is my code that should handle a transaction receipt via a promise:

function approveFactoryContract(factory) {
  factoryAdress = $("#factory").val();
  RegistratContractInstance.approveFactoryContract(factoryAdress, false, {from: web3.eth.accounts[0]}, function(error, result){
           if(!error)
               console.log(result),
               $("#message").html("Approval request has been submitted - please wait a moment for it to be mined. You can check your transaction <a href=\"https://ropsten.etherscan.io/tx/"+result+"\" target=\"_blank\">here</a>");
           else
               console.error(error);
       });
}

How do I make this work?

Display text while pending: Please wait for your transaction to be mined. Display text when resolved: Your transaction has been mined.

1 Answer 1

1

There is more than one way to do this.

This library is useful. It gives you a Promise for the mined transaction, so you can carry on after you know it's mined, update the UI etc.

https://gist.github.com/xavierlepretre/88682e871f4ad07be4534ae560692ee6

In practice, I've found that I'm always setting up event listeners to watch for updates from anyone and then if that information has an impact on the display, updating the relevant fields. It leads to nice dynamic updates on so-called static web pages.

I've observed that when that sort of thing is in place, I don't need to be concerned about mined transactions from this user because I'm already watching for updates from any user. If something happens that impacts a field, message, style etc. on the screen, the callback deals with it.

There's a hidden requirement here. Every important state change that unfolds in the contract will fire an event emission that will describe everything important about the state change. I would argue it's a best pratice to do that. Among other benefits, having that in place is certainly convenient at the UI construction stage.

Hope it helps.

2
  • Triggering an event handler for every event sounds fairly excessive. Imagine that "best practice" for an ICO page with thousands of TXs. I'd be hesitant calling this a general best practice. IMO that's why we have filters and topics to selectively subscribe to.
    – SCBuergel
    Commented Jul 14, 2017 at 16:07
  • @ValidityLabs-Sebastian. I don't disagree with you, so possibly misstated my meaning. Trying to say contracts should emit an event. Clients can selectively listen but there has to be something to listen for. Commented Jul 14, 2017 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.