You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are some drawbacks to having a single helper that does the signing and submission, one of which is that it reduces the flexibility if you want to have the user sign it once and then send it either later or multiple times, etc. if, for example, there are network issues.
For our records, the reason we have a draft doing it this way is to carry method type information between (i) constructing the transaction with the request body type, which happens before signing, and (ii) parsing the response data, which happens after submitting.
Maybe we should look into making some clearly container structs like UnverifiedTransaction and SignatureSigned have a type parameter instead of unknown content. It takes us farther away from the possibility of translating type definitions automatically, but seems worth it.
The text was updated successfully, but these errors were encountered:
this will be more good for the future when we (i) make similar wrappers for consensus and (ii) have gas in runtimes. the gas estimation also wants to look at the transaction, so it'll be one more thing that fits better when the steps are separated
making some clearly container structs like UnverifiedTransaction and SignatureSigned have a type parameter
a later idea: keep those types as they are, because there are lots of places where we end up with such a structure without actually knowing what's inside. instead, make wrappers that know what its member SignatureSigned contains, somewhat similar to the types like SignedTransaction in go and its embedded Signed
There are some drawbacks to having a single helper that does the signing and submission, one of which is that it reduces the flexibility if you want to have the user sign it once and then send it either later or multiple times, etc. if, for example, there are network issues.
For our records, the reason we have a draft doing it this way is to carry method type information between (i) constructing the transaction with the request body type, which happens before signing, and (ii) parsing the response data, which happens after submitting.
Maybe we should look into making some clearly container structs like
UnverifiedTransaction
andSignatureSigned
have a type parameter instead ofunknown
content. It takes us farther away from the possibility of translating type definitions automatically, but seems worth it.The text was updated successfully, but these errors were encountered: