These are a slightly different beast, as transactions cannot be identified by name to ask the server for lookup.
The implementation is likely going to require something of a list view approach or other interactive approach as might be provided by Charm's 'bubbletea,' a courtesy that also ought be extended to the transaction LOGGING as well, for a better user experience.
One idea might be to have a bubbletea model that renders a list of transactions, and when the limit is hit near the bottom, a message is sent outside the model to another goroutine that requests the next (LIMIT) amount of transactions, then adds it to the list.
These are a slightly different beast, as transactions cannot be identified by name to ask the server for lookup.
The implementation is likely going to require something of a list view approach or other interactive approach as might be provided by Charm's 'bubbletea,' a courtesy that also ought be extended to the transaction LOGGING as well, for a better user experience.
One idea might be to have a bubbletea model that renders a list of transactions, and when the limit is hit near the bottom, a message is sent outside the model to another goroutine that requests the next (LIMIT) amount of transactions, then adds it to the list.