white-whale-defi-platform / white-whale-frontend Goto Github PK

Newly discovered, on local and it seems prod sometimes we see this issue everywhere except the swap page.
Need to debug for more info.

Today we see total deposits and a given users deposits in USD value but there is no displayed dollar sign
This is confusing and makes it look like there is much more tokens of a given currency for example on Juno which is worth 5 a piece.

To make this work we need to setup a separate CI/CD pipeline within out pipeline sort of. I am trying to put as much information here as I can as when I was exploring this I found very little.
For Akash deployments to work in github actions we will use this action https://github.com/ovrclk/akash-ghaction-setup either directly from CI or by defining our own akash action based on the above.

With the action to help we now we two jobs for this pipeline which depends on each other. The first the image generation which will be pushed to a container registry and then second a deployment to akash Job.

Some things to note:

• The very first deployment most likely is always manual to get the DSEQ and SSH Certs and all that for the secrets
• The wallet where deployments happen must be prefunded in some means to do things
• On each new push to main we want to update the akash deployment with a newly built image

Indexing and display of precompiled data to give metrics such as the over time Volume and APR of a pool or vault is a massive area of opportunity to improve on the current frontend. We had a decent indexing APR built on the V1 Solution which leveraged Lambda, Typescript and Mongo Db. For V2 we have been experimenting with getting a Subquery API live however there have been a number of issues with getting it working for N chains.

• #72
• #73
• #74
• #75
• #76

Chain or Pools

Relevant Info:

• A new chains information is added in chain_info.json
• A new pools information is added in public/mainnet/<chain>-1/pools_list.json
• A new vaults information is added in public/mainnet/<chain>-1/vaults_list.json

Currently the frontend supports or in the past has been able to support 6 and then both 6 and 18 decimal tokens.
If your desired token has a different number of decimals there may need to be an additional change needed. For the most part this should be fine.

Proposal

• Add chain_info for Injective testnet and mainnet (#121)
• Add testnet pools info (#121)
• Add testnet vaults info (#121)
• Manual test and confirm features work as-is (Revealed issues, we need support for injective-ts)
• #123
• Test full suite of actions: Swap with direct pair, swap with 3 hop route, provide and remove lp, deposit and withdraw to vault

Right now we have a very basic linting setup as the drive has been on getting features implemented. Alot of places there is going to be code which is dead or otherwise non-compliant with a strict linting setup.

As a dev on the frontend
I want a better linting config
So that I can work on getting the project compiling under strict lints

As a way to test right now we have strict checking turned off on FE, if you run

yarn build 

It builds with very little checks.
With a better lint setup we should be able to see all these problems which would cause a strict yarn build to fail. In another issue we can work on solving them as thats a bigger task

Injective uses a different typescript client and message format for the most part in its actions, we need to update the execute actions to reflect this

There are two prospective clients this one is an official one from injective: https://github.com/InjectiveLabs/injective-ts. There is also InjectiveJS from cosmology which looks quite nice.

We already have a wallet abstraction which can be found here:

https://github.com/White-Whale-Defi-Platform/migaloo-frontend/blob/5c44be81bbd3aebc545a945658838980683a612d/util/wallet-adapters/wallet.ts#L7

The abstraction is inherited and used here with this final connection method connectWithSigner

https://github.com/White-Whale-Defi-Platform/migaloo-frontend/blob/5c44be81bbd3aebc545a945658838980683a612d/util/wallet-adapters/offlineSigningWallet.ts#L40

It seems like Injective use a number of different types and even a diff pub key proto so in the case of injective test or mainnet we should be able to handle this.

Fixes for this should be targets to go into the branch for #122 and then the entire integration merged in one go.

We require a new page on the app which allows us to submit a json of a flash loan to a deployed flashloan router.

Related PR #95

We need:

• Contributing, Code of conduct, security docs #95
• Pull request and issue templates #95
• Precommit hook scripts or integration with husky #95
• Improved readme linking to all the above as well as docs #95
• Add tests husky hook such that tests are run before push #95
• Add basic CI setup #110
• Open Source the frontend 🥂 -- Today :D

The frontend is in need of some nice integration testing suite of tests.
In order to build this up similar to #61 we need some proper test runner/suite/so on.

There are alot of potential options now, we have seen in the wild people running integration test scenarios against :

• a locally spun up or remote local terra to do on demand chain interactions.
• ts-relayer for testing chain to chain interactions and possibly can be used for the above

We need to get some base in place with which all further tests can import as integration testing setup is a big affair for a new dev to figure out, this individual needs alot of piping plumbing ready to go and documented so they can then focus on the testing case.

Currently the frontend has just enough CI/CD for deployments. This has a simple condition, that yarn build passes.
We need more CI/CD jobs based on work done in other related issues

• #67
• #68
• #69
• #70

Use case

Proposal

Currently with a large flashloan payload the text looks like so

With it like this its not possible to expand and see all the json. We should add something like :

So that we can expand the editor

Additional context

Would save confusion and prevent people from waiting for info to load before realizing they have to connect wallet

Similar to #62 and should be done after. Once we have a better linter we now see all the code compilation issues again ideally, this issue is to track working on and removing all of those such that as a result of this task we can once again enable strict:true on the next config for strict checking. This will help with code quality in the future so that builds fail when unused code is commited.

Another nice to have would be to get some hooks such that on commit we can have this run or at least on push. Build time is cheap with netlify but this would be more efficient.

Small one here. We need a common node version that all devs are working on and ideally is the deployment version. No strict requirements on a given version stable vs latest but it should be defined for all and when needed incremented.

Additional context

Would save confusion and prevent people from waiting for info to load before realizing they have to connect wallet

After integrating Wallet and a bunch of other features it still is the case that the balances and overall state are not being retrieved properly on second load with an already connected wallet.

To reproduce, assuming you are using the app for the first time:

• Connect Wallet on any chain.
• Balance and address should show as expected
• You can switch to some tabs without issue
• Reload page
• Wallet is connected, address is showing but balances are not fetching
• As a result you no can't use the app for anything useful

From some investigation I noticed that in walletAtoms.ts we are not storing the client in cache. This seems okay but assumes we are instantiating a new client somewhere. After a fair bit of debugging, so far its looking like on subsequent loads the cache is returning null for client (as designed) but no where is there logic to reinstantiate a client in this case. As a result all pending queries for balances for smart contract interactions fail.

Meta issues mostly for tracking. Each page as an issue can have its own issues defined also.
We need some new Pages either on the existing app where it makes sense and is a small sensible addition otherwise these 'pages' can be developed also as a micro app or SPA.

Pages to be developed:

• #91
• #105
• Charts Page enabling anyone to at a glance see metrics like volumes pricing and so on
• Validator Page enabling xyz benefit to stakers or validators
• IBC Transaction Send enabling anyone to send a token from one chain to another via an established IBC Channel. We can do it all in a CLI but a UI is much handier for the general user
• Claim Page for Airdrops which can be reused for other claims like vesting
• #151
• ...add other pages as needed

We have a keplr wallet integration for the frontend, we now need a terra station integration also as an option

It needs to be done such that a user can toggle the chains here

Starting with for example Juno where Keplr is used
If we select Luna, terra station should now be used

It should be possible to switch between the networks and use the webapp with either wallet depending on networks. Eventually more networks will be added and potentially other wallets please consider this in the design.

End goal is to have an abstraction around these chains and wallets in the frontend such that the devs can import something, feed it some info when instantiating and then regardless of network feed it transactions to simplify the process of adding newer components.

Pls include code comments and some level of documentation of the solution in-code.

As of right now, there are no automated tests in any capacity. This is a huge area of opportunity to reduce errors making their way to production but getting the frontend to some reasonable % coverage level is a big undertaking to be broken into steps. Before we can get there we need a nice initial test setup that we can depend on over time to avoid redefining testing methods and techniques all over the place.
We need fixtures, mocks and other things which we can have in one place and build up that location over time such that all tests are using common code from this one place. This will make it easier to deal with fundamental changes at any level and when needed we can handle very specific cases in the tests themselves.

For this task we just want an initial setup, ideally something both at the Unit testing and Integration testing level either is fine for a starting point. Afterwards in other issues we will build this up but cant do that until we have a starting point.

Flip pool labels such that base pools are second and assets are priced in their base pair.

Also flip pool icons such that it reflected the base in the end

We can assume that pools will always come in the form BASE-OTHER such as ATOM-LUNA or ATOM-JUNO.
Where ATOM is base token in these cases we should show on the frontend LUNA-ATOM or JUNO-ATOM showing base token second as its denominated in this.

If the Pool contains stabletoken, stable token should remain as base in frontend i.e second token shown

When providing LP deposits, trying a small amount of Huahua to get a quote on the 18 decimal token we see this issue. This is most likely some further decimal issues that need to be ironed out so we can use N token decimals rather than always expecting 6

only on terra should have an option to switch to terra station but it shouldn't auto disconnect you.

Intermittent issue, maybe this isint happening to everyone and undersome condition this is happening.

As a result of this task either a fix is delivered or some steps to prevent the issue ideally. If the fix is just removing the chains in certain ways then document this.

Insufficient available balance?

Right now we can only connect wallets mainly on mobile
But we should be able to use mobile connect where possible

Get frontend deployed on netlify
Needs a fixed and passing 'yarn build' and some config in netlify UI

Currently, pools are only loaded when a user has connected their wallet and selected a chain.

When providing liquidity and getting a valid quote we cannot finish the process due to this invalid coins error. This is like #97 could just be a decimal issue too but needs fixing so users can provide liquidity.

Blocked by #99 and other decimal issues we discovered.
Overall alot of places were using a hardcoded 6 decimal but as we grow we need support for N decimals. Right now that is 18 decimals for two pools on chihuahua and eventually all tokens on Injective but we want to do this in such a way we dont get into another problem with for examplee 4, 2 or some other combination of decimals.

After adding 2 pools each with an 18 decimal native token a number of issues have been exposed.

• #101
• #100
• #99
• #97
• #98
• Testing on an 18 decimal chain

padding for vault page aligns the vaults component at the top while swap and pools have top padding to center the components on the screen. They should all be centered or all at the top.

Currently the app is designed to be responsive on both mobile devices and web but currently it only works best on the web.
This task details some things needed to improve the Mobile UI/UX

• #79
• tbd

Sometimes when going to pages the button only shows Connect Wallet rather than the appropriate state like for example Enter Amount. This happens only on some pages

need live apr numbers

If for example I pass domain/swap?chain=thing

Then it should select the 'thing' chain. If this chain is invalid then default to normal behaviour which is JUNO