feat(activity): open a transaction's details from any activity row - #1417
Open
bmc08gt wants to merge 1 commit into
Open
feat(activity): open a transaction's details from any activity row#1417bmc08gt wants to merge 1 commit into
bmc08gt wants to merge 1 commit into
Conversation
An activity row states what moved and when, and nothing else. Tapping one did nothing, so the exchange rate, the token quantity, the fee, and the settlement state had nowhere to be read, and a sent cash link could only be cancelled from the row's own swipe action. Rows in the wallet preview, the token-info preview and the full activity history now push `AppRoute.Sheets.TransactionDetails(messageId)`, which draws the same entry as a screen: heading and avatar, the signed amount, and a receipt of the values a row has no space for. `TransactionDetailsMapper` shares `TransactionItemMapper`'s reading of the metadata (counterparty, avatar, direction), so a row and the screen it opens cannot disagree about what the entry was. What it adds is the kind stated in the user's own voice, the receipt values, and the two actions. `ResolvedTransaction` carries the drawn state and the action targets in one emission: cancelling needs `IndirectlySentCrypto.creator`, and opening the conversation needs the user id plus the profile, neither of which belongs in a UI model. The screen reads through `MessageDao.observeMessageById`, so cancelling a cash link from the app bar redraws the screen once the update lands rather than leaving a stale "Pending". `TransactionDetailsViewModel` lives in `:features:transactions` rather than beside the mapper: cancelling goes through `TokenCoordinator`, and `:shared:transaction-history` depending on `:shared:tokens` closes a cycle through chat. Two receipt rows are built but unreachable from real data. Neither the message metadata nor the notification carries a withdrawal destination or a deposit source, so `account` is always null and the To/From row never renders; and a legacy buy/sell records only the mint that moved, so its subtitle has no counterpart mint to name. Both are left in place for when the server sends them. The token quantity is an estimate: `estimatedTokenAmountIn` prices against the mint's current supply, so on a historical entry it says what that value is worth now, not what it bought then.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An activity row states what moved and when, and nothing else. Tapping one did nothing, so the exchange rate, the token quantity, the fee, and the settlement state had nowhere to be read, and a sent cash link could only be cancelled from the row's own swipe action.
Rows in the wallet preview, the token-info preview and the full activity history now push
AppRoute.Sheets.TransactionDetails(messageId), which draws the same entry as a screen: heading and avatar, the signed amount, and a receipt of the values a row has no space for. Figma node 9708:105260.How it resolves
TransactionDetailsMappersharesTransactionItemMapper's reading of the metadata — counterparty, avatar, direction — so a row and the screen it opens cannot disagree about what the entry was. What it adds is the kind stated in the user's own voice, the receipt values, and the two actions.ResolvedTransactioncarries the drawn state and the action targets in one emission. Cancelling needsIndirectlySentCrypto.creator; opening the conversation needs the user id plus the profile. Neither belongs in a UI model, and opening three flows on one id invites them to disagree.The screen reads through
MessageDao.observeMessageById, so cancelling a cash link from the app bar redraws the screen once the update lands rather than leaving a stale "Pending".AvatarSlotmoves out ofActivityFeedRowintoTransactionAvatarImage, parameterised by size, so the screen opens on the same avatar that was tapped rather than a second rendering of it. Its defaults are the row's geometry unchanged.Where the ViewModel lives
TransactionDetailsViewModelsits in:features:transactions, not beside the mapper. Cancelling goes throughTokenCoordinator, and:shared:transaction-historydepending on:shared:tokenscloses a cycle through chat.Two receipt rows are unreachable from real data
Neither the message metadata nor the notification carries a withdrawal destination or a deposit source —
IndirectlySentCrypto.creatoris a gift-card vault, not an account — soaccountis always null and the To/From row never renders. A legacy buy/sell records only the mint that moved, so its subtitle has no counterpart mint to name, andPaidCryptocarries a pool id with no name. Both are built and left in place for when the server sends them.The token quantity is an estimate.
estimatedTokenAmountInprices against the mint's current supply, so on a historical entry it says what that value is worth now, not what it bought then.