-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Paul/saved action #574
Paul/saved action #574
Conversation
|
||
nativeAmount: { [currencyCode: string]: string } | ||
networkFee: { [currencyCode: string]: string } | ||
tokenId: string | null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There cannot be a tokenId
inside a MergedTransaction
, because this combines all the coins together.
I see that there is a currencyCode
in there already. This was a mistake from Eliran, and we should delete it.
The only place where we use the tokenId
/ currencyCode
is in the onBlockHeightChanged
processor. Since the goal is to update the block height, we either need to iterate over Object.keys(MergedTransaction.tokens)
to update every currency, or since that will cost a lot of bridge traffic, we could just use the default currency code / null tokenId, but fix the GUI to handle block-height changes in a currency-agnostic way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Agreed. But such a change is a bit outside the scope of this PR. Can we punt that to another task. The tokenId here at least mirrors the currencyCode use and they can both be fixed simultaneously when we agree on the method.
export const asNumeralString = (raw: any): string => { | ||
if (typeof raw !== 'string') throw new Error('Not type string') | ||
if (isNaN(Number(raw))) throw new Error('Does not parse as a number') | ||
return raw | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have asIntegerString
. Please use that.
Otherwise, if you want decimal support, we should make an asDecimalString
using a regexp. Remember, biggystring doesn't support 1E+6
syntax, but JavaScript does, so we need to be more picky than just using isNaN(Number(raw))
. Inputs could pass this filter that still crash the app.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intent was decimal support although unneeded for its current use. Once Sam merges his biggystring PR we'll have full scientific notation support. For now I'll change to asIntegerString
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I think this is the right solution in any case, since these are native amounts. Native amounts should never have decimal points or exponents.
export const asEdgeTxActionFiatType: Cleaner<EdgeTxActionFiatType> = asValue( | ||
'buy', | ||
'sell', | ||
'sellNetworkFee' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so with this design, we need to save two copies of the action, duplicating the orderId and all other fields. One copy goes with the parent currency as a fee, and one goes with the token. The only difference between the two copies is the type
field.
You already have a tokenId
inside the action itself, so there is no need for this duplication. The GUI can easily see which side is the fee and which side is the sell by using tx.tokenId === savedAction.cryptoAsset.tokenId
.
So, I really think the whole concept of saving the action per-currency is a mistake. There should be one action per transaction, saved at the root level.
When we first discussed this, I trusted your assertion that the actions needed to be saved per-token. Now that I'm seeing what the action looks like, I think that's a deeply flawed assumption.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the case of a fiat transaction this might be simple, but consider a DEX swap on Ripple. You have an action to create an order which pays XRP, the outgoing send which is considered a 'swap' which could pay USD.bs, then the receive which is the fulfillment that receives USD.gh. Do you really want the GUI to have to figure that all out.
As well the plugins report transactions per asset as they send individual EdgeTransactions. Now while they might not use savedAction
but instead action
, they would still be putting the action info per asset which we don't want to conflict.
d25d4f7
to
1cb4bba
Compare
1cb4bba
to
3ed9d40
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some changes on the metadata stuff.
I don't really understand the new savedAction
/ chainAction
/ assetAction
design. I see that savedAction
/ assetAction
are per-transaction, which makes sense, and the new assetAction
is per asset. What I don't understand is how the plugin / app coordinate on setting up assetAction
.
export const PARENT_TOKEN_ID = '' | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this line should live in currency-wallet-files.ts
, since it's related to the on-disk representation.
category?: string | null | ||
exchangeAmount: { [fiatCurrencyCode: string]: number } | ||
name?: string | ||
notes?: string | ||
name?: string | null | ||
notes?: string | null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't actually want to store null
on disk. The only reason we allow null
in the user-facing type is to be able to delete fields. We need to revert this type definition, plus whatever changes are needed to the merging / updating code to make that work.
If could make sense to defined an EdgeMetadataChange
type that includes | null
for the fields that can be deleted, and revert the original EdgeMetadata
type to how it was before. That makes it clear that metadata will never contain nulls. It's just a sigil for deleting fields.
category: asNullable(asString), | ||
exchangeAmount: asOptional(asObject(asNumber), () => ({})), | ||
name: asOptional(asString), | ||
notes: asOptional(asString) | ||
name: asNullable(asString), | ||
notes: asNullable(asString) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. We don't want to save null
on disk.
d1a4196
to
fe7e855
Compare
This works as follows. Plugins edit GUI edits |
fe7e855
to
bd5851f
Compare
37f4e76
to
ebb6513
Compare
ebb6513
to
7fce6f5
Compare
We need to provide both per-asset and per-transaction information, both on-disk and from the plugin.
This allows us to replace SwapData with EdgeTxActionSwap
7fce6f5
to
427c168
Compare
CHANGELOG
Does this branch warrant an entry to the CHANGELOG?
Dependencies
noneDescription
none