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.
 *
 * Resolution order is deliberate:
 *  1. `instance_slot_data.transaction_guid` — the beat explicitly naming its subject.
 *  2. `beat.primary_transaction_guid` — the standard beat-level pointer.
 *  3. `beat.transaction_guids[0]` — last resort for beats that only carry the list.
 *
 * 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`.
 *
 * `beat.primary_transaction` is the fallback of last resort: it is a payload snapshot, not a store
 * object, so inline edits against it would not propagate. Preferring it over a store hit would make
 * editing silently no-op, which is why it is only used when the store genuinely has nothing — and
 * only when it is a snapshot of the *same* transaction the guid resolved to (or when no guid
 * resolved at all). A snapshot of some other transaction is not an answer to this question.
 */
export declare const useTransactionDetailsBlock: (beat: Beat) => TransactionDetailsBlockState;
export {};