Отзыв о пользовательском интерфейсе децентрализованного приложения с ожидающей/заминированной транзакцией с использованием Metamask?

Итак, я развернул смарт-контракт и могу взаимодействовать с ним через веб-интерфейс, используя web3.eth.contract(abi).at(address)и Metamask — пока все хорошо.

Однако между отправкой транзакции и ее добычей я хотел бы отобразить одно сообщение, а после того, как оно было добыто, - другое.

Я понимаю, что web3.eth.getTransactionReceipt(txhash).blockNumber == ""до тех пор, пока tx не будет добыт. Но как мне это проверить, пока он действительно не был добыт с использованием javascript и внедренного web3 из Metamask?

РЕДАКТИРОВАТЬ: я пытаюсь заставить его работать с обещаниями, но просто не могу понять, как это реализовать. Это мой код, который должен обрабатывать получение транзакции через обещание:

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);
       });
}

Как мне заставить это работать?

Отображать текст в ожидании: пожалуйста, подождите, пока ваша транзакция будет обработана. Отображать текст при разрешении: Ваша транзакция была добыта.

Ответы (1)

Существует несколько способов сделать это.

Эта библиотека полезна. Он дает вам Promise для заминированной транзакции, так что вы можете продолжить после того, как узнаете, что она заминирована, обновить пользовательский интерфейс и т. д.

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

На практике я обнаружил, что всегда настраиваю прослушиватели событий для отслеживания обновлений от кого -либо, а затем, если эта информация влияет на отображение, обновляю соответствующие поля. Это приводит к хорошим динамическим обновлениям на так называемых статических веб-страницах.

Я заметил, что когда такие вещи существуют, мне не нужно беспокоиться о добытых транзакциях от этого пользователя, потому что я уже слежу за обновлениями от любого пользователя. Если происходит что-то, что влияет на поле, сообщение, стиль и т. д. на экране, обратный вызов обрабатывает это.

Здесь есть скрытое требование. Каждое важное изменение состояния, которое разворачивается в контракте, вызывает эмиссию событий, в которой описывается все важное, связанное с изменением состояния. Я бы сказал, что это лучшая практика. Среди других преимуществ, это, безусловно, удобно на этапе создания пользовательского интерфейса.

Надеюсь, поможет.

Запуск обработчика событий для каждого события звучит довольно избыточно. Представьте себе эту «лучшую практику» для страницы ICO с тысячами транзакций. Я бы не решился назвать это общей передовой практикой. ИМО, поэтому у нас есть фильтры и темы для выборочной подписки.
@ValidityLabs-Себастьян. Я не согласен с вами, поэтому, возможно, исказил мою мысль. Попытка сказать, что контракты должны генерировать событие. Клиенты могут выборочно слушать, но должно быть что-то, что можно слушать.