我制作了一个可以在终端上查看GitHub项目板的应用程序【TUI】

1 年 ago

雅, 悟

1 minute

源代码在 GitHub 上。

有什么应用程序？它能做什么？

您可以在终端上查看 GitHub 的项目看板和问题的详细信息。它是专为 GitHub 项目看板设计的查看器。

意圖

我想要制作这个应用的原因很简单，就是我想要制作一个终端应用。与Web应用相比，终端应用的设计要求并不是很高。虽然我不是很擅长前端，但我会过于关注细节和外观，所以制作Web应用时花费最多时间的是设计和实现。实际上，我最想做的是后端部分，所以我在终端这种不需要太过关注设计（我自以为）的地方想要制作一个应用。

当我考虑要制作一个终端应用程序的主题时，我开始进行了一些实验来看能否将 GitHub 的Project boards，Issue和Actions结合起来进行任务管理。我试图通过Issue来管理任务，通过Project boards来可视化整体任务，并尝试使用Actions来自动化Issue状态的变更。我在那时的实验内容已经在Qiita上写了出来。

【GitHub】GraphQL で issue を登録する

用GraphQL和Hub命令进行了各种尝试，但在终端上操作并在浏览器中确认结果的行为反复重复开始变得繁琐。因此，我想如果能在终端上操作并在终端上确认结果将会很方便，于是我决定制作这个应用程序。

应用科技

这个应用是基于 Node.js 构建的，与 GitHub API 的通信使用了 GraphQL。我们开发的应用可以通过 GitHub Actions 的工作流自动创建 Docker 镜像，并上传到 GitHub 的容器注册表中。我们充分利用了 GitHub 提供的功能。如果你想立即使用这个应用，请拉取 Docker 镜像。无需克隆源代码和安装依赖库，就可以启动应用程序。

JavaScript（JS）是一种广泛使用的编程语言，用于在Web浏览器中创建交互式网页和应用程序。Node.js是建立在JavaScript运行时的一个开放源代码、跨平台的后端JavaScript运行环境。

我懂得的語言有 PHP、JavaScript、Python，而從中看，JavaScript或Python都可以實現終端應用程序。也許PHP也可以實現，但當時我正努力學習JavaScript或Python的其中一種，所以我將PHP排除在選擇之外。我也考慮過用Golang實現，但那樣就要同時應對學習未經歷的Golang和開發終端應用程序這兩個問題。考慮到本次我僅專注於終端應用程序的開發，所以我放棄了用Golang實現。不過，我計劃將來也要嘗試用Golang來實現。

我是一名服务器端开发者，最初使用Python开发了这个应用。然而，GraphQL的响应速度感觉很慢（大约1秒的感觉时间），所以我尝试使用Node.js进行开发，并发现这样的响应速度更快，因此决定重新用Node.js实现它。

在使用Node.js创建终端应用程序时，我使用了blessed库以及扩展了它的blessed-contrib库。

选择使用blessed和blessed-contrib的原因是，它们似乎可以轻松实现网格布局。为了在终端上显示项目板，实现网格布局是库的选择标准。由于blessed-contrib提供了一个可以轻松实现网格布局的界面，我们决定采用这些库。

GraphQL

为了获取来自GitHub的项目版和问题的信息，我使用了GitHub GraphQL API。我选择使用GraphQL而不是REST API的原因是，GraphQL可以减少API请求的次数，并且我想尝试一下GraphQL。

我曾经没有在实际工作中使用过GraphQL，但我在这个网站上完成了前后端教程，所以对GraphQL有一定的了解。我想尝试使用GraphQL来构建应用程序，并且这次我使用GitHub提供的GraphQL API，因此不需要设计和实现解析器，只需要在客户端实现，所以负担不会太大。实际上，我花了一些时间来查找在GraphQL API中应该使用哪些查询，但是在实现过程中并没有遇到太多困难。

Docker，GitHub操作

我已经使得实现的应用程序可以从Docker镜像中启动。我们使用GitHub的容器注册表作为注册表。从创建Docker镜像到推送到注册表，我们使用Actions进行自动化。

做出的努力

为了能够在短时间内一气呵成地实现，我设法合理安排时间，而不是拖延开发。此外，由于使用GitHub的API，为了不给GitHub带来压力，我还尽量减少了向GitHub发送请求的次数，特别是在应用程序启动时。

时间的运用

由于应用开发的目标是“在终端上可以确认Project Board和Issue的内容”，所以在处理其他部分时，遇到困难时不要陷入其中，需要考虑避免，并尽量不花费太多时间。例如，当我使用Python实现GraphQL通信处理时，响应速度感觉很慢。本来应该调查为什么慢，但这次我尝试用Node.js实现了相同的处理，发现响应速度没有问题，因此我决定切换到使用Node.js来实现。

我們做出了如下的改變，當遇到問題時，我們會先試著使用替代解決方案，如果問題無法解決，就直接採取原先的方案，在終端上展示以節省時間並增加使用的頻率。

减少通信次数

当启动应用程序时，我们会通过向 GitHub API 发送请求来显示项目板。接着，我们会再次与 GitHub 通信，以便在对 Issue 取得焦点并按下回车键后显示此 Issue 的详细信息。为了减少与 GitHub 的请求次数，我们将获取的 Issue 详细信息保存到数组中，在再次显示时无需向 GitHub 发送请求，而是从数组中获取并使用。如果在应用程序运行期间添加了问题或修改了内容，您可以通过退出应用程序并重新启动来显示最新的数据。

辛苦经历

如果在除了终端显示以外的地方遇到问题，我会尝试使用替代方法或更快的方法来处理，但是在终端显示和涉及blessed/blessed-contrib的部分，则没有替代方案可供选择，因此在实施时我遇到了一些困难。

事件处理

这次的应用根据键盘输入来改变屏幕显示的组件。关于根据事件来切换组件的方式让我很苦恼。虽然有有关blessed的概述信息，但详细的介绍不光在Qiita上，甚至在网络上都找不到，所以只能依靠blessed的README。blessed的README中列出了公开的API（属性、方法、事件等），但没有详细说明。因此，最后我要么直接查看源代码，要么靠感觉进行实现。

试着制作一个应用程序

我很满意能够制作出与想象一样的东西，但仅有一个查看器是没有什么用途的，所以我认为需要添加问题创建和修复功能。
在制作终端应用程序后，我发现它可以做到不输给图形用户界面的操作和表达能力，这让我暗暗地为TUI看到了潜力。此外，从Actions的发布开始，我也被GitHub所吸引，并在考虑如何利用GitHub进行自动化。如果有灵感，我可能会开发一个结合问题、Actions和终端的个人强大任务管理应用程序。