OpenAPI Explorer
这个示例展示了一个三栏浏览器：
- operation 列表
- operation 详情
- schema 详情
和活动监视器不同，这个示例不是“实时刷新驱动”的，而是“结构化信息浏览驱动”的。
这让它成为一个很好的参考：
当你的应用不是监控面板，而是一个文档或资源浏览器时，Ansiq 应该怎么组织界面。
1loader 读取本地文件或远程 URL
2parser 把原始文档转成中间模型
3左栏展示 operation 导航
4中栏展示 operation 详情
5右栏展示 schema / ref 详情
运行方式
cargo run -p ansiq-examples --example openapi_explorer -- --input /path/to/spec.yaml也可以传远程 URL：
cargo run -p ansiq-examples --example openapi_explorer -- --input https://example.com/openapi.yaml
真实运行的 openapi_explorer 示例界面。
这个示例展示了什么
它适合用来理解：
- split-pane 布局
- selection 和 detail browsing
- 本地文件 / 远程 URL 的加载入口
- 结构化数据如何映射成 TUI 浏览器
这个示例主要用到哪些 widgets
为什么这个示例重要
很多 TUI 示例只展示：
- 列表
- 表格
- 表单
但真正的终端应用经常还需要处理另一类问题：
如何在有限空间里浏览复杂结构化信息。
OpenAPI Explorer 就是在展示这一点。
它不是一个“请求客户端”，而是一个：
- 文档浏览器
- 结构导航器
- schema 检视器
运行时建议观察什么
1. 左栏不是“原始文本”，而是压平后的导航模型
这说明 UI 不应该直接消费原始 OpenAPI JSON/YAML，而应该消费一套更适合浏览的中间模型。
2. 中栏和右栏承担了不同层次的信息
- 中栏：当前 operation 的详情
- 右栏：schema / ref 视图
这种分工非常适合 Ansiq 的多 pane shell，因为它把：
- 导航
- 主信息
- 辅助信息
明确地放在了不同区域。
3. 它的复杂度主要来自数据准备，而不是 widget 本身
这个示例提醒你一个很重要的事实：
当应用开始处理真实格式时，最大的复杂度常常不在 UI，而在：
- loader
- parser
- 中间模型
- 选择逻辑
读代码时的顺序建议
推荐按下面的顺序读：
loaderparsermodels- 场景状态
- 最后再看三栏布局
如果你直接从 UI 树开始读，会觉得它只是“左中右三个 pane”；但真正值得学习的是它如何把 OpenAPI 文档整理成一个适合浏览的模型。
这个示例没有做什么
它当前故意只做浏览，不做：
- 发送请求
- 历史记录
- 命令模式
- 复杂 filter
这样可以让它保持一个清晰边界：
先把“浏览器”做扎实，而不是一下子把它变成终端 API 客户端。
对应阅读
如果你想把这个示例和 Guide / Internals 连起来，推荐：
Last updated on