ch06-08 订单状态刷新和深度展示

返回本章

先从用户动作开始

先从用户动作开始。“订单状态刷新和深度展示”在产品里会表现为按钮、表单、状态刷新或错误提示；链上仍然会落到固定的 Pool 和 BalanceManager 入口。

源码入口

• packages/deepbook/sources/pool.move：place_limit_order、place_market_order、cancel_order(s)、cancel_live_order(s) 等 Spot PTB 入口。
• packages/deepbook/sources/order_query.move：iter_orders 分页读取 bids/asks，服务订单簿和深度展示。
• packages/deepbook/sources/book/order_info.move：订单生命周期事件、执行策略校验和用户可见错误来源。
• packages/deepbook/sources/balance_manager.move：创建或复用 BalanceManager、deposit/withdraw、TradeProof 授权。
• book/ch06/code/s01-pool-list-cli 至 book/ch06/code/s05-mini-terminal：本章 CLI/PTB 示例的应用侧落点。

从应用反推链上

order_query::iter_orders 是链上订单簿分页接口。参数包括 start_order_id、end_order_id、min_expire_timestamp、limit 和 bids。买单从高到低遍历，卖单从低到高遍历。返回 OrderPage { orders, has_next_page }。

前端深度展示应把同价位订单聚合为 price level。分页时保留最后一个 order ID 作为下一页 start，且过滤已过期订单。min_expire_timestamp 可以设为当前时间，减少前端展示过期订单。

工程旁白：Spot 应用先看用户状态机：市场、余额、订单、提交、确认。链上提交仍然落到 pool.move 和 balance_manager.move；UI 只是把这些固定入口组织成用户能理解的交易动作。

读模型要区分链上查询和 indexer 缓存。packages/deepbook/sources/order_query.move 适合读取当前订单簿快照，个人成交历史则应以事件和交易 digest 为准；前端本地缓存只能做临时加速，不能覆盖链上最终状态。

写应用时

• 所有用户输入先做 decimal、tick size、lot size 和 min size 转换，再构造 PTB。
• 提交前 dry run，提交后用 digest、事件和 order_query.move 刷新状态。
• UI/CLI 中分开展示 wallet coins、manager 余额、open orders 和最近一次交易状态。

动手检查

• 订单状态刷新和深度展示 需要哪些对象 ID、type arguments、cap/proof 和数值参数？
• dry run 失败时应给用户显示哪类提示：余额、精度、订单状态、版本暂停还是 Gas？
• 交易成功后应用应该依赖事件、order query 还是本地缓存更新页面？