Make transaction type choosable

[janndriessen]

What context is your feature request related to?

Transactions and setting their types.

Right now CodableTransactions are type legacy by default. Using the integrated features this often leads to issues where users would rather choose newer types - instead of legacy - but can't really change the transaction type before sending it.

What solution would you like?

The solution is not clear yet - as this probably touches lots of different places in the library. This will need some more research. Ideas welcome!

[yaroslavyaroslav]

I've leave my view here. Whilst I'd releasing 3.0.0 one, I've thought about to made type of CodableTransaction manageable my any internal method or something. But it have ended with the lack of time and tx in depts knowledge, so I left it as it is now: being able to be set only within initialisation.

The problem I've passed was the inability to appropriately manage internal types as EIP1559Envelope and so on, which one are actually stores the whole types within them, but it seems that it's in a much better state right now, like the data passing through CodableTransaction to them in appropriate way, but for now that's the one way street, when to as I see there's two way data passing required to implement such switches.

One more thing to think about is how to handle gas related properties between Legacy and EIP1559 types? Like they have directly opposite fields in itself, and the design should handle that somehow.

[janndriessen]

One more thing to think about is how to handle gas related properties between Legacy and EIP1559 types? Like they have directly opposite fields in itself, and the design should handle that somehow.

Good points in general. For the gas related properties specifically, I think the question would be what should CodableTransaction be. Should it be very powerful it what it can do or is it just an object to configure/prepare a transaction.

For now, I think I'd prefer the latter one. Keep it very simple and clean (and also more flexible that way). Checks e.g. for gas related properties based on types could probably be done on the individual services (using CodableTransaction).

EDIT: we should probably check again where and how CodableTransaction is used - also in terms of gas.

[yaroslavyaroslav]

Should it be very powerful it what it can do or is it just an object to configure/prepare a transaction.

@janndriessen you've described the exact intent of mine that I've kept in mind when refactored it up to current state before.

It should not become to the only separate framework itself, but should be just the type that encapsulates all transaction values, that all other methods in framework should manage by their own.

[janndriessen]

🤝