chore: permit modifications #1325
Conversation
…e overview of permit
| handleApproval={() => approval({ amount: amountToRepay, underlyingAsset: poolAddress })} | ||
| actionText={<Trans>Repay {symbol}</Trans>} | ||
| actionInProgressText={<Trans>Repaying {symbol}</Trans>} | ||
| approvalFallback={ |
There was a problem hiding this comment.
could you elaborate on why this is needed now? don't really understand.
There was a problem hiding this comment.
In the updated design, the retryWithApproval is no longer a separate state in the modal, it's a button which is always available inside the TxActionsWrapper, so this component needs to be able to trigger both an approve and permit, but the handleApproval function is only handling one at a time.
The other option I considered is adding a parameter to the handleApproval function which specifies this override, but this gets very complicated because the function is passed as a parameter through SupplyActions -> TxActionsWrapper -> useTransactionHandler
| handleAction={action} | ||
| handleApproval={() => approval()} | ||
| handleApproval={() => | ||
| approval({ amount: repayAmount, underlyingAsset: poolReserve.aTokenAddress }) |
There was a problem hiding this comment.
Need to test this to figure out why the current version is working with blank parameters
There was a problem hiding this comment.
The reason this works is that these params are only used by permit, added them anyways so it will support in the future
There was a problem hiding this comment.
Would it clean it up if we had a permit function and an approval function in useTransactionHandler? That way it'd be clear when/why these parameters are needed.
There was a problem hiding this comment.
This probably doesn't make sense to modify until changes to aave-utilities are finished. These two prs (456 and 458) combine the steps of building approve and permit, which would make these parameters completely unnecessary. The same params are used to build both approve and permit, so it doesn't make much sense to have them duplicated
|
📦 Next.js Bundle AnalysisThis analysis was generated by the next.js bundle analysis action 🤖
|
| Page | Size (compressed) |
|---|---|
global |
472.35 KB (🟡 +936 B) |
Details
The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!
Two Pages Changed Size
The following pages changed size from the code in this PR compared to its base branch:
| Page | Size (compressed) | First Load |
|---|---|---|
/governance |
62.38 KB (-3 B) |
534.73 KB |
/staking |
20.52 KB (🟡 +26 B) |
492.87 KB |
Details
Only the gzipped size is provided here based on an expert tip.
First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this.
|
|
I generally think this is an improvement for wallets not supporting permit. The path for "doing approval" instead of permit is a Why isn't there just a switch or sth to switch between the two methods? Wdyt? |
bojanaave
added
QC Passed
and removed
Ready for QA Review
|
LGTM |
|
@sakulstra My 5 cents on that:
|
|
I would add a question to 'Approval doesn't work?' and redirect users to this article instead to learn more details (Learn more link in the tooltip) |
|
|
|
||
| const tryPermit = | ||
| currentMarketData.v3 && | ||
| permitByChainAndToken[chainId]?.[utils.getAddress(poolAddress).toLowerCase()]; |
There was a problem hiding this comment.
I noticed this doesn't work on forks because of a different chainId. We could move this to a helper in the store and handle the fork logic in there as well.
There was a problem hiding this comment.
Good idea, this belongs in the store anyways
| }); | ||
|
|
||
| // set use permit to false to retry with normal approval | ||
| setUsePermit(false); |
There was a problem hiding this comment.
I think there's some cleanup we could do in here now. I don't think we need usePermit as state and we can just use the param passed in. It's also being returned from this hook, but doesn't look like it's used anywhere.
defispartan
added
Ready for QA Review
|
|
great job! @defispartan |
|
LGTM |
bojanaave
added
QC Passed
and removed
Ready for QA Review
|
| <SvgIcon>{currentMethod === ApprovalMethod.APPROVE && <CheckIcon />}</SvgIcon> | ||
| </ListItemIcon> | ||
| </MenuItem> | ||
| </Menu> |
There was a problem hiding this comment.
Could these menu item components be simplified? They look identical other than the ApprovalMethod.VALUE
There was a problem hiding this comment.
Would end up with more code to split to separate component and pass currentMethod, buttonMethod, setMethod, and handleClose as props so I think it's fine to leave as is
|
|
|
* feat: use updated permit function * chore: bump package for proper export * chore: standardize permitConfig casing * chore: small styling changes to approval flow * chore: remove approval component which was replaced with tooltip * chore: remove retry with approval text placements * chore: modify approval function for explicit parmeters and allow force overview of permit * fix: build errors on handleApproval * chore: run i18n * chore: revert permit utility modification * chore rework approval fallback params * chore: update actions components approval params * chore: update text and link * chore: cleanup unused state * feat: move tryPermit logic to zustand store * feat: add approval tx to gas estimation * chore: remove unused import * feat: design updates for new approve/permit flow * feat: add wallet approval preferences to walletSlice * feat: add approval preference button * feat: apply approval method toggle in TxActionsWrapper * chore: rework params for approval toggle * chore: bump utils package to include permit gas estimations * feat: use wallet approval preference in tx handler * chor: bump icon size * chore: handle edge case with already approved action * chore: rename variable for consistency * test(fix): fix e-mode for polygon * chore: review * chore: review * fix: localStorage override with multiple wallets Co-authored-by: bojank93 <[email protected]> Co-authored-by: NikitaY <[email protected]>
7 participants
General Changes
Developer Notes
tryPermitflag to decide whether permit is available for a market/asset pair to poolSliceAuthor Checklist
Please ensure you, the author, have gone through this checklist to ensure there is an efficient workflow for the reviewers.
mainIf the PR is ready for review:
Openstate and not inDraftmodeReady for Dev Reviewlabel has been addedReviewer Checklist
Please ensure you, as the reviewer(s), have gone through this checklist to ensure that the code changes are ready to ship safely and to help mitigate any downstream issues that may occur.
.env.examplefile as well as the pertinant.github/actions/*files