import { Beat, Transaction } from '../../../core';
import { BottomActions, TopActions } from '../../../transactions/constants/Actions';
interface TransactionDetailsBlockState {
    bottomActions: BottomActions[];
    /** True while the store is still loading; the block shows a loader instead of an empty state. */
    isLoading: boolean;
    topActions: TopActions[];
    /** `undefined` once loading finishes means the transaction could not be resolved. */
    transaction?: Transaction;
}
/**
 * Resolves which transaction this drawer is about, and which inline actions it offers.
 *
 * The subject comes from one of two places:
 *  1. `actionContext.transaction_guid` — set by a parent drawer (e.g. a row tapped in
 *     `TransactionHistoryBlock`) when this drawer is opened nested.
 *  2. `insights_payload.primary_transaction_guid` — the ditto contract for every beat whose
 *     `primary_cta_block` is `transaction_details_block`.
 *
 * The guid is then looked up in `transactionStore.detailedTransactions` rather than used directly,
 * because `TransactionDetails` needs the *detailed* shape (account + category + taggings joined in)
 * and edits must write through to the same store object the rest of the app renders. `buildDetailed
 * Transactions` inside the store is this repo's equivalent of pulse's `buildTransactionDetails`.
 * A guid the store does not have resolves to `undefined` (the block's error state) rather than to
 * any beat-level snapshot, so inline edits can never be made against a stale copy.
 *
 * Actions are not beat-configurable on the v2 contract: `instance_slot_data` is not part of it (the
 * LargeTransactionV2 payload omits the key entirely), so top actions are always the defaults and
 * bottom actions are derived from the triggering CTA's variant.
 */
export declare const useTransactionDetailsBlock: (beat: Beat) => TransactionDetailsBlockState;
export {};