Portfolio Transaction History improvements

[jaspervdj-da]

In the example splice portfolio, TransactionHistoryService provides an API for retrieving past transactions.

Currently this class just stored transactions in an in-memory array, which works as a PoC but isn't great for two reasons:

1. All history needs to be fetched again when the user refreshes the page
2. Queries are less efficient than they could be without extra work

Additionally, the class currently uses offsets to order transactions. This works when using a single synchronizer, but breaks down in a multi-synchronizer world. Instead, we want to use updateId (for uniqueness) and recordTime (for sorting).

An IndexedDB-based store seems like a good match here. It is widely supported (in particular, browser extensions can also use it). It allows us to have semi-structured data with indices on updateId and recordTime (or alternatively offset if we don't want to solve the multi-synchronizer problem yet).

I recommend using idb to make the API more async-idiomatic.

We will still need to store both parsed and queued (typically we can't parse these yet, but we will once we retrieve older events) transactions. IDBKeyRange.bound/IDBKeyRange.lowerBound/IDBKeyRange.upperBound should make retrieving the right transactions trivial.

[meiersi-da]

commandId (for uniqueness)

did you mean updateId? commandIds are submitter chosen

[jaspervdj-da]

Yep, I meant updateId, fixed in the description

[meiersi-da]

@jaspervdj-da @mjuchli-da : what's your view on how this kind of custom index and the ACS index support in the dApp SDK should evolve? do you already have a view on how the north star for frontend-persisted-and-indexed data looks like?

[jaspervdj-da]

I haven't touched the ACS side too much, since we had an existing helper for that. I'm also not sure if transaction history and ACS management should use the same underlying technology (as long as they offer a reasonably consistent API). I also think this sort of service should ideally be part of the "core libraries" in this repo rather than the dAPP SDK specifically, so it can be reused across components.

I feel like IndexedDB has sufficient features, apart from the indices discussed above, it should allow adding new ones for transaction types, sender/receiver, etc.

I've also looked a bit at sqlite, but I'm not sure if there's any benefits that make up for complicating the build process with WASM to that degree.