Closed julien51 closed 5 years ago
This will be useful to fix https://github.com/unlock-protocol/unlock/issues/1198
There are 3 "states" for a transaction:
The problem exposed in that issue are for 1. and 2. I have for now pushed 1. to the sideline and focused on 2.
For 2. there are 2 sub-problems: a. Knowing about the transaction, b. Knowing what the transaction is about.
Knowing about the transaction is not a problem until the user refreshes the page. However, once the user reloads the page, we have no way of knowing the hash of the transaction (or even that one exists) . One solution considered was to see if there was a way to query the user's wallet (metamask), but that would fail if the user used another device, and there does not seem to exist a clear API for this.
The second solution was to use our locksmith for this so that as soon as a transaction has been created, it is sent to locksmith, and as soon as a user is identified, we retrieve the past transaction hashes for them. This has been implemented (https://github.com/unlock-protocol/unlock/commit/a4d4f988661498e61b02092b7c2a23dc93e8eccb and https://github.com/unlock-protocol/unlock/pull/1455).
For the second part of the problem (knowing what the transacion is about), we introduced a way to parse the input
of the transaction in web3Service
. See https://github.com/unlock-protocol/unlock/commit/4db983ec260450ade0044d0f5348d4ef7fb79aa1
This then leaves us to solve the part 1. of the initial problem: being able to show what a submitted transactions's content is about, until it becomes "pending".
The only way to do that is to pass the input
for a newly created transaction from the walletService
to the web3Service
.
As part of the web3Service split, we have introduced a clear distinction between the act of "sending" and transaction (thru
walletService
) and reading a transaction (thruweb3Service
). We also only use data fromweb3Service
to actually build objects such as the locks or the keys, in order to make sure each object can always be constructed after a browser refresh for example, since no data is stored anywhere.Right now, we also identify the changes performed by a transaction only when it has been mined... and mining takes from a couple seconds to a couple hours! During that time, the user has no idea that their transaction is actually happening... and this is annoying (to say the least!).
The initial approach I was thinking about was to building the object on
sendTransaction
. This would solve the problem of the lag... until the user refreshes, where all data would be lost until the transaction has been mined.Another approach would be to look for pending transactions (not mined yet) and decode them based on the receipient's address (this can help us determine which smart contract the transaction was sent too and which method was invoked).