UI fixes #199
UI fixes #199
Conversation
How can this be? In one case, permission is given to the Uniswap contract to spend X tokens. In the other, permission is given to Token Locker contract to spend Y tokens. Can someone only give permission to spend certain ERC20 tokens to one contract at a time? |
src/html/transfers.html
Outdated
| @@ -619,12 +617,13 @@ <h3 class="transfer__amount">${window.utils.formatLargeNum( | |||
| if (!(window.ethInitialized && window.nearInitialized)) return; | |||
|
|
|||
| const transfers = await window.transfers.get(); | |||
| const params = Object.keys(window.urlParams.get()); | |||
| const currentParams = Object.keys(window.urlParams.get()); | |||
| const allParams = ['new', 'erc20', 'erc20n'] | |||
There was a problem hiding this comment.
"If current params includes all params, hide recent transfers. Otherwise, show recent transfers."
These names seem really confusing. allParams especially. Maybe irrelevantParams instead? "If params are irrelevant, hide. Else, show."
There was a problem hiding this comment.
allParams are the pages of the app : new, erc20 and erc20n, so we want to display transfers if not one of those pages is active. Maybe appUrlPaths instead then ?
haha yes you are correct, I don't know why I thought that since allowance would be given to a different contract |
After near redirect, display transfers while near tx hash is being checked. Prevents displaying blank page if checkMint/checkWithdraw has an issue.
This is so that a new selection is always created, otherwise the modal is not closed if the token input has not changed.
|
Pushed some changes to this branch. Re: Indicating that the app is in beta, I think in general people understand that when something is in beta, it is still a WIP and might have some rough edges. As long as we can clearly indicate that it is in beta, we don't need to explicitly explain this via a big banner. I've added a "Beta" tag that appears near the logo in all instances. Once we're comfortable with the app's stability and feature-completeness, we can remove it.
|
|
@paouvrard could you let me know what exactly broke the build here? Can't seem to identify what might have caused it... |
|
@corwinharrell the build fails due to the commit message format: https://www.conventionalcommits.org/en/v1.0.0/ |
|
🎉 This PR is included in version 3.4.2 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
@paouvrard ahh makes sense then why it went over my head. Happy to adhere to a specific format if that is helpful 👍 |
Allow the user to remove an Eth -> NEAR transfer before the lock tx is created.
There is no confusion because the transfer was never initiated on-chain so this is effectively deleting the transfer.
It is safer because the user may have another pending transaction with that token for example on uniswap, and if the allowance is consumed, the user will be stuck before the lock step with no way to recover. The allows the user to delete the transfer and start it again.
Note that the approve transaction is not lost as creating a new transfer will skip the approve step if allowance is enough
Add restore functionality from landing page
