持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第3天，点击查看活动详情
本文不会涉及太多技术细节和源码，请放心食用
大家好，我是 HelloGitHub 的老荀，好久不见啊！
我在完成 HelloZooKeeper 系列之后，就很少“露面了”。但是我对开源和 HelloGitHub 的热情并没有丝毫的减少。这不，逮着个机会就来输出一波，防止被大家遗忘😂。
这次带来的是我写的一款在终端浏览 HelloGitHub 的工具：hg-tui，让你双手不离开键盘就能畅游在 HG 的开源世界。功能如下：
- 色彩丰富、平铺展示
- 关键字搜索月刊往期的项目
- 类 Vim 的快捷键操作方式
- 一键直达开源项目首页
- 支持 Linux、macOS、Windows
下面我将分享自己发起这个开源项目的缘起、构思、再到开发的全部过程，最后分享一下，我通过做这个项目对开源的一些感悟。
一、起因
我本职是做 Java 开发，但架不住 Rust 太有意思了！所以最近在学 Rust 恰好前段时间看到 HG 讲解 tui.rs 的文章。
看完后手痒得厉害，就写了一篇 tui.rs 入门文章，但感觉还不过瘾就想写一个项目练手。
因为我平时经常上 HelloGitHub 找开源项目，所以就决定用 tui.rs 做一个终端浏览 HelloGitHub 官网的工具。
二、构思
首先我希望这个应用能有以下功能：
- 有搜索框，可以按关键词搜索 HelloGitHub 中的任意项目
- 通过表格按列展示搜索结果
- 既然是终端应用，那操作方式肯定是使用键盘方式，快捷键我采用了一些大家熟知的 Vim 快捷键
- 浏览项目的途中，可以随时在浏览器中打开当前浏览的项目
有了这些主要功能点的思路，下面就要想想怎么设计一个界面了，我本职工作后端一碰到画界面就头疼，几经周折大概把界面设计成了这样：
又因为是 TUI 界面层级不能太深，所以再多弄个详情页面（用来浏览文字明细）或者弹窗页面（提示消息）就差不多了。
我又想到了 GitHub 为每一种编程语言都设计了一种颜色，我也可以把这些颜色应用在我的项目里，让整个终端界面看起来没那么单调，色彩更丰富。效果如下：
主界面：
详情页：
弹窗提示：
最后为了向 TUI 妥协，按期数或类别搜索，我是通过使用搜索前缀来和普通关键词搜索作出区别。
上面展示的这些差不多已经是这个项目的全部了
三、开发
3.1 技术选型
要实现上述的那些功能，就要从 Rust 的生态中选择合适的库了
下面这些是我在这个项目中使用到的：
- 基础设施：
anyhow、thiserror、lazy_static、better-panic - 绘制 UI：
tui、crossterm - HTTP client：
reqwest - 缓存：
cached - HTML 解析：
nipper - 工具：
regex、crossbeam-channel - 命令行：
clap
虽然 Rust 还是编程界的小学生（2011 年启动），但是经过了这些年的发展，生态已经逐渐完善，工具库已经很丰富了。再加上 Rust 是系统级的语言，值得投入时间学习！
3.2 项目结构
项目结构规划（非全部）
src
├── app.rs // 统一管理整个应用的状态
├── cli.rs // 命令行解析
├── draw.rs // 绘制 UI
├── events.rs // UI 事件、输入事件、通知
├── fetch.rs // HTTP 请求
├── main.rs // 入口
├── parse.rs // HTML 解析
├── utils.rs // 工具
└── widget // 自定义组件
├── ...
合理的分文件（目录）开发，可以让每个功能模块 高内聚、低耦合，并且可以很容易地分开进行单元测试。
当然这些文件也不是在项目之初就已经一股脑地建立好的，都是在完善功能的路上一点点添加进来的～
3.3 主要代码
因为是基于 tui.rs 开发的应用，所以主流程肯定是遵循该库的设计的，首先需要定义一个 App 用来保存整个项目的状态信息。
pub struct App {
/// 用户输入框
pub input: InputState,
/// 内容展示
pub content: ContentState,
/// 弹窗提示
pub popup: PopupState,
/// 状态栏
pub statusline: StatusLineState,
/// 模式
pub mode: AppMode,
/// 项目明细子页面
pub project_detail: ProjectDetailState,
...
}
每一个状态字段,其实就是对应一个自定义组件.要在 tui.rs 中实现自定义组件（实现方式也是我自己的理解）也很简单只要三步，我以 Input 组件为例。
/// 用户输入框组件，组件本身没有字段，是一个无状态的对象
/// 无状态对象只关心 UI 怎么绘制，不存储数据
pub struct Input {}
/// 组件的状态，每一个字段就是组件需要存储的数据
#[derive(Debug)]
pub struct InputState {
input: String,
active: bool,
pub mode: SearchMode,
}
/// 最后为 Input 组件实现 StatefulWidget trait
impl StatefulWidget for Input {
type State = InputState; // 指定关联类型为 InputState
/// area 绘制的区域
/// buf 缓冲区（可以直接写入字符串，如果要高度定制的话，可以理解为画笔）
/// state 从这个变量中直接取绘制过程中需要的数据
fn render(self, area: Rect, buf: &mut Buffer, state: &mut Self::State) {
// 具体绘制的逻辑
...
}
}
只要是面向用户的应用，都会处理各种各样的用户输入（事件）。Rust 中一般都使用 channel 来解耦处理各种各样的事件，再利用 Rust 强大的枚举支持，定义各种各样的事件（用户输入和非用户输入）即可。
/// 定义事件枚举
#[derive(Debug, Clone)]
pub enum HGEvent {
/// 用户事件（键盘事件）
UserEvent(KeyEvent),
/// 应用内部组件的通知事件
NotifyEvent(Notify),
}
#[derive(Debug, Clone, PartialEq)]
pub enum Notify {
/// 重绘界面
Redraw,
/// 退出应用
Quit,
/// 弹出窗口展示消息
Message(Message),
/// tick，比如一些数据需要每隔一段时间自动更新的（比如：显示的时间）
Tick,
}
/// 弹窗的消息，分为 错误、警告、提示
#[derive(Debug, Clone, PartialEq)]
pub enum Message {
Error(String),
Warn(String),
Tips(String),
}
为了区分用户事件和通知，我使用了两个不同的 channel 分别处理这两类：
lazy_static! {
/// 因为通知队列希望被应用内部共享，所以使用了 lazy_static 方便使用
pub static ref NOTIFY: (Sender<HGEvent>, Receiver<HGEvent>) = bounded(1024);
}
又因为不同的事件处理，并不应该互相阻塞，所以整个应用采用了最基础的多线程模型来提高性能，这里使用的也是标准库的多线程。
pub fn handle_key_event(event_app: Arc<Mutex<App>>) {
let (sender, receiver) = unbounded();
...
std::thread::spawn(move || loop {
// 单独一个线程接收用户事件
if let Ok(Event::Key(event)) = crossterm::event::read() {
sender.send(HGEvent::UserEvent(event)).unwrap();
}
});
std::thread::spawn(move || loop {
// 单独一个线程处理用户事件
if let Ok(HGEvent::UserEvent(key_event)) = receiver.recv() {
...
}
});
}
其他剩下的就是业务逻辑，完整的代码可以直接看仓库 github.com/kaixinbaba/…
四、心路历程
一开始我做 hg-tui 项目的时候，仅仅是为了做个实际的项目把玩一下 tui.rs 这个框架，做好之后问题层出不穷，但我深知没有与生俱来的完美，只有不断的迭代才能让它越来越好，经过 100 多次的提交后，现在用着感觉顺手多了。毕竟作者是项目的第一个用户，自己用着不舒服其他人就更不喜欢了！
我想着既然要让别人用，一定要容易安装。接着我做了基于 GitHub Action 自动编译和发布，支持 Windows、Linux、macOS 直接下载就能用。
我还做了对 homebrew 安装的支持，但因为 Star 数不够没有收录到 homecore 要求：30 forks、30 watchers、75 stars
希望大家看到这里的话能给个 star✨
五、最后
hg-tui 它从出生那一刻起，体内流淌的就是开源的血。
它很小甚至是微不足道，我本不想开源，但蛋蛋的一段话让我改变了主意：开源不是完结，仅仅只是开始。
一个开源项目可能只是作者的一个灵光乍现，也可能只是为了解决自己实际工作生活中的小小痛点，没准用完就丢到角落里了。但开源出来或许就能找到有相同需求的人，从而延续这个项目的生命，或许这就是开源的本意吧。
以上就是我做这个项目的全部心得和收获，如果你们对 hg-tui 有什么建议和问题，欢迎给我提 issue
最后，如果你喜欢本文和项目的话，欢迎点赞和 Star 爱你们哟～
