fix: spot prices display edge cases

[alfetopito]

Summary

Fix issue when sometimes spot/market prices are not loaded

To Test

1. Load the app in the Safe https://app.safe.global/apps/open?safe=sep:0x8FAb71C0d4272698A3B2d1F3Ed5FC3c1B9b3E531
2. Check limit orders

• Market prices should load
  

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
cowfi	✅ Ready (Inspect)	Visit Preview	Jan 20, 2025 11:42am
explorer-dev	✅ Ready (Inspect)	Visit Preview	Jan 20, 2025 11:42am
swap-dev	✅ Ready (Inspect)	Visit Preview	Jan 20, 2025 11:42am

3 Skipped Deployments

Name	Status	Preview	Updated (UTC)
cosmos	⬜️ Ignored (Inspect)	Visit Preview	Jan 20, 2025 11:42am
sdk-tools	⬜️ Ignored (Inspect)	Visit Preview	Jan 20, 2025 11:42am
widget-configurator	⬜️ Ignored (Inspect)	Visit Preview	Jan 20, 2025 11:42am

[elena-zh]

Thanks!

[anxolin]

What was the issue? I can see the operation is more compact, but the old code reads correct to me. Are we not handling something we should in inputFraction.divide(outputFraction)?

[alfetopito]

What was the issue? I can see the operation is more compact, but the old code reads correct to me. Are we not handling something we should in inputFraction.divide(outputFraction)?

In some cases, the fraction ended up with huge numbers, without needing to.
For some reason it was not reducing it to the smaller numerator/denominators.

For example: 100000/200000 is equivalent to 1/2, but the fraction representation was using 100000 instead of 1 (but with lot more zeros in the real case).
Using directly price.asFraction seems to be enough to make it work as expected.

See https://docs.uniswap.org/sdk/core/reference/classes/Fraction and https://github.com/Uniswap/sdk-core/blob/9997e88/src/entities/fractions/fraction.ts#L154

Although, that's a good question.

@elena-zh did that work for tokens with different decimals? Keep in mind USDC on Sepolia has 18.

[elena-zh]

What was the issue? I can see the operation is more compact, but the old code reads correct to me. Are we not handling something we should in inputFraction.divide(outputFraction)?

In some cases, the fraction ended up with huge numbers, without needing to. For some reason it was not reducing it to the smaller numerator/denominators.

For example: 100000/200000 is equivalent to 1/2, but the fraction representation was using 100000 instead of 1 (but with lot more zeros in the real case). Using directly price.asFraction seems to be enough to make it work as expected.

See https://docs.uniswap.org/sdk/core/reference/classes/Fraction and https://github.com/Uniswap/sdk-core/blob/9997e88/src/entities/fractions/fraction.ts#L154

Although, that's a good question.

@elena-zh did that work for tokens with different decimals? Keep in mind USDC on Sepolia has 18.

@alfetopito
Oh no!!!
I did not know that I needed to do this specific test here: I've just checked that the app is not crashed :(
Prices for tokens with different decimals do not look good in this PR:

Opened this task to address it

[alfetopito]

New attempt to fix it at #5317