crocswap / ambient-ts-app Goto Github PK

Currently, the trade configurator for each of the trade types (and the buttons to toggle the trade type) are coded inside the nested routes. This means that the header and buttons are unnecessarily re-rendering when the user clicks between the three transaction types (Market, Limit, and Range).

Each nested route re-uses extremely similar code for this display. Move the code out of the three nested routes and code the display once inside the Trade.tsx file.

Our app retrieves outside token lists and hosts them in local storage. As these lists are maintained by people/organizations outside of Crocodile Labs, we need a mechanism to periodically re-query URIs to see if a token list has been updated. To this end we need some sort of value to trigger the app to run such a query.

The first step is to add middleware to fetchTokenLists.ts to add UNIX time, or some other recognized date/time format, as a key value pair on each token list to mark when it was retrieved. This way we can have the app run a function on initialization to see if any token lists need to be updated (if a specified time interval has passed) and, if so, update that particular list.

Currently, the CSS for the transaction configurator is written with the assumption the user will never need to use a token with more than four characters. In the event the user selects a token with more, a scrollbar appears because the element displaying the symbol overflows its container.

The CSS needs to be able to display the full symbol without an overflow.

https://ambient-finance.netlify.app/account/benwolski.eth
https://ambient-finance.netlify.app/account/miyuki.eth

Currently in development I'm having issues with CORS errors if the an outside token list URI 404s my IP address's request instead of responding with data. As the app currently processes multiple fetch requests with Promise.all(), a single 404 request causes the entire function to fail. Instead, we should use Promise.allSettled() which assumes only some of the promises will be fulfilled and others may be rejected (but still waits for resolutions).

There are two main efforts to this:

1. Refactor Promise.all() in fetchTokenLists.ts to use Promise.allSettled(). This will require some syntax updates and instructions to handle 404 requests.
2. Design the functionalities to activate and deactivate lists to understand what to do if a list is not present. We should likely make fetchTokenLists.ts indicate in local storage that a request was rejected by the URI and not simply missing for handling control flow on making secondary attempts to fetch a list.

Currently the function validateChain() has a hardcoded list of chains supported by the Ambient app. We tried to use an array of network names to pull valid values from a data object in the file, but this threw TypeScript errors. Decided with Ben to hardcode valid lookup values for the time being and revisit later.

Currently the app is pulling token lists from outside URIs. We need to:

1. Isolate a list of current-chain tokens from active lists
2. Send the data of active tokens to the choose token modal
3. Render buttons to select each individual token, highlighting the current token
4. Update the DOM vial local state when the user selects a token
5. Sync RTK from local state after the user selects a new token to accurately persist the pair (see issue #78)

Re-use the modal code to make a warning; we selectively overlay a blurred background over a component with a warning message and a button. Once the user reads the warning, they can click the button to dismiss the warning.

When the user selects a new token pair, many elements in the DOM are updated instantly or nearly so. However, an external call is needed to get a new pool price, so for a short period of time the DOM will display a new token pair but outdated information based on the old pool price.

We need to do the following to address this:

1. Locate an SVG loader or a series of loaders (if needed for elements of different sizes and dimensions)
2. Replace the outdated DOM elements with the SVG loader when the the user selects a new token pair
3. Replace the SVG loader with the live component once a pool price has been received and the code depending on it has processed

For reference on the second step, refer to the TokenSelect.tsx component and note sections of control flow where the reducer setDidUserFlipDenom(false) is dispatched to RTK.

My intuition is to make a useState() value in App.tsx called "waiting on pool price" or similar. When the token pair is changed it's set as true. Once code dependent on pool price has processed, the value is set to false. Use the value of this state hook to determine whether relevant components render content or the SVG loader.

Currently the Ambient token list is coded in two places.

1. /src/utils/data/ambientTokenList.ts
2. /public/ambient-token-list.json

The purpose of the file in the /public folder is for the app to disseminate the Ambient Token List to anyone in the world who wants to use it, including us. The file in /src exists because TypeScript wants fallback values in some functions where we use the token list, and while a fetch() request to a local public file is fast, it's still not immediately available when the app compiles. That said, I also prefer to not host duplicate data hardcoded in the front when it also exists in a place where it's disseminated from for the public to use.

We're going to refactor to follow Uniswap's model which is to host the token list in the SDK. Putting the data in a dependency we control makes the data available when the app compiles and also bakes in our proprietary token list to the SDK if and when any other parties decide to use it.

I think it make sense to push this until we've completed migration to Goerli, until then I don't want to lose the convenience of being able to manipulate the Ambient token list for testing purposes inside the front.

Core goals to accomplish this are as follows:

1. Host the Ambient Token List in the SDK
2. Delete the file /src/utils/data/ambientTokenList.ts
3. Refactor any instances of the app which use the data from the deleted file to use the SDK data instead

Secondary goals include:

1. Discuss what URI & CDN we want to use to disseminate our token list to the outside world. Will we use an API service not contained in the UI? If it remains in the UI, can we re-write logic to simply hand off the data from the SDK in that file?
2. Should we re-write logic so that we don't get data for the ambient token list from a fetch() request at all? This could be more performant, but will require re-writing the logic to get the Ambient list as a special case, which is not ideal.

The secondary goals are open for discussion and do not necessarily need to be completed as part of this effort. They may be ignored, modified, or completed as a separate feature once the core functions are built.

Currently, slippage tolerance is a hardcoded value in the app. This feature branch has three goals:

• track the user's slippage tolerance in RTK
• persist the user's slippage tolerance across sessions in local storage
• synchronize data between RTK and local storage appropriately

This is on hold pending discussion with Doug re: initialization. Last week we discussed initializing slippage based on the fee tier of a pool and then persisting a custom value which is user/pool-specific across across sessions. Before continuing I want to be sure we've properly spec'd the goals of this feature.

Important Notes

• RTK must initialize from a value hardcoded in the slice. If we want to initialize the app on a custom value, we need to initialize then update with a useAppDispatch(), possibly in a useEffect() or when the SDK function returns pool data
• The architecture of the app will allow us to manage this effectively with local state. We may not have need to go through RTK at all, and that may be easier
• Tracking user-customized slippage tolerances for each pool one has been created for will require a more complex approach to storing data in local storage
• Need information from Doug and Ben about what data we would use to reference an individual, specific pool. Is there a hash?

Currently, each of the Market/Swap, Limit, and Range order components all have their own version of DenominationSwitch.tsx, which is the switch controlling which token numeric values are shown in terms of. This should be reduced to one file in /src/components/global which all three modules import separately, particularly given the value they're setting is universal to the app.

Companies whose platforms manage sensitive data or financial services for users often put a warning for users in the console of the deployed app. This warns the user against using the console to put commands directly into the app and alter its actions which could be used by a scammer for theft or fraud. See the image below for a screenshot from my Facebook account as a guide.

Since we're using the console frequently for dev purposes, I'd like to kick this one until shortly before we push to production. We can discuss content as a group as well. We should also find a way to deactivate the code in our local environments so when developing, the warning doesn't chew up limited on-screen real estate in the console.

When the user selects a range with low and high bounds that places the current place outside the range, populate text in the DOM to warn them.

• Choose a red color which is noticeable but doesn't feel out of place.
• Populate below the "X% difference" line.
• Do not disable any functionality, just populate the message.
• Populate the same message in the Confirmation Modal as well.

To add personality to our app, users will be allowed to assign custom names to their positions and transactions as saved in the app. We'll need to set up the data in local storage for the user that has full CRUD for these, stored in an object in which they're a value stored to a key which is the hash to which the custom name.

In coding a solution for Issue #79, specific functionality will be programmed into the generic modal. Once this functionality is achieved, we need to abstract it out of the modal code and pass it in such that the modal code becomes reusable for other purposes in the app.

• [ ]

The app will warn users when they are trying to make a Limit Order for a low-liquidity pairs. Make a value in local storage that tracks pairs that the user has said to not warn them in the future of transactions on that pair.

At the moment Ben has code written in Swap.tsx which pulls balances from the user's wallet of the two tokens in the active pair. I want to relocate this logic such that after the app pulls the user's token list from local storage, it retrieves balances for all tokens and puts that data in the token data object.

It's important to remember control flow; the user's local storage token list is never overwritten by the token list being used and manipulated in the DOM. It's only changed by the user adding or removing tokens from their list with the import feature, and the data object is always retrieved from the list.