332/slippage bips rather than amounts on metadata

[alfetopito]

Summary

Part of #332

Waterfalls onto/supersedes #750

Using the latest version of the appData.

Updating metadata way less often by storing only the slippage instead of sell/buyAmounts and quoteId

To Test

1. Open the console, filter by appData
2. Play with the slippage in the settings

• Every update should trigger a new appData being generated
• The slippage will be stored as BIPs. For example, the default 0.50% will be stored as 50

3. Place an order

• Verify it contains the appData hash calculated in the previous step

[github-actions]

CLA Assistant Lite All Contributors have signed the CLA.

[github-actions]

• 🔭 GP Swap: CoW Protocol v2 Swap UI

[anxolin]

Approved.

A small nitpick. I notice some delay between submitting the tx and seeing the uploading.

I think this is due to the updater checking only from time to time.
I think the:

• Updater don't need to run so frequently
• We should trigger an action that tries to upload the document right away. This way, the effect is that we attempt the upload right after posting the order, and if it fails is when the updater takes over and re-attempts

[alfetopito]

Approved.

A small nitpick. I notice some delay between submitting the tx and seeing the uploading.

I think this is due to the updater checking only from time to time. I think the:

* Updater don't need to run so frequently

* We should trigger an action that tries to upload the document right away. This way, the effect is that we attempt the upload right after posting the order, and if it fails is when the updater takes over and re-attempts

Yes, this is true.

More of a technical reason. I don't want to react to every change as that leads to race conditions since the same state is used to track when something is being updated or not.
Also, not a big concern given that uploading the file is not time sensitive, even more so now that we are back at reduced amount of files.

Maybe what does make sense is to check whether the file exists before trying to pin it 🤔

[elena-zh]

Changes related to Slippage LGTM besides I regression issue I reported for GA analytics event: #639
So in this PR I see duplicating appdatahash logs when I'm filling in the slippage field

[elena-zh]

Approving with the issue above

[alfetopito]

Changes related to Slippage LGTM besides I regression issue I reported for GA analytics event: #639 So in this PR I see duplicating appdatahash logs when I'm filling in the slippage field

Elena, I don't see a duplication here.
It is regenerating at every keypress, though.
You can check the slippageBips is different, as well as the CID and appDataHash

[elena-zh]

Elena, I don't see a duplication here. It is regenerating at every keypress, though. You can check the slippageBips is different, as well as the CID and appDataHash

@alfetopito , I'm sorry, I did not explain it correctly. I meant that the log appears when I'm still typing into the field, so when I want to specify a 2-3 digits slippage value, I will see 2 logs for appdata, and I called it 'duplicating'.
So my point was to log appdata as soon as user removes a cursor/mouse from the Slippage field or so.

[alfetopito]

Elena, I don't see a duplication here. It is regenerating at every keypress, though. You can check the slippageBips is different, as well as the CID and appDataHash

@alfetopito , I'm sorry, I did not explain it correctly. I meant that the log appears when I'm still typing into the field, so when I want to specify a 2-3 digits slippage value, I will see 2 logs for appdata, and I called it 'duplicating'. So my point was to log appdata as soon as user removes a cursor/mouse from the Slippage field or so.

Ah, got it.
Not a problem Elena, as it won't upload the file anywhere by that point, and it's fairly cheap to re-calculate