也来写个PR内容产生器吧
用React开发桌面app帮自己省点时间
说话便宜。给我看代码。
repo放在前头是礼貌，react菜鸡欢迎批评指教(合掌)
https://github.com/TomatoSoup0126/PR-content-generator
继去年用 Vue + 电子 做了个excel转换器之后，一直觉得Electron是个让前端无缝写桌面app的好文明，在开了几次让人厌世的PR(Pull request)后，决定来写个side project以解决撰写PR内容缓慢的过程。
缘起：
公司专案在开PR的同时，会需要在标题注记该项PR对应的需求票号以自动同步该票的状态(on dev / on production …)，并在内容贴上该票连结，方便QA和需求单位验收。
平常单项功能进到dev branch的情况，这个额外的小作业并不至于太麻烦，但轮到大进版时，整包release往master推的这种PR，就会需要爬commit或是看file diff来整理这支PR上所关联的所有票号，整个过程就会变的相当耗时，再加上公司的需求票同时存在于 红矿 和 存在 两套专案管理工具上(这说来话长先跳过)，所以往往会花上不少时间在两套专案管理工具上来回找查需求票，再将其剪剪贴贴到PR中，按照目前两个礼拜一次的进板节奏，每到那时候就是个开PR到厌世的日子(眼神死
发想：
想让上述手动作业自动化的念头油然而生，整理一下工人智慧的情况下都干了什么：
- 开出PR，例如dev branch → release branch
- 肉眼扫commit，找出有注记票号的commit
- 辨识票号是哪种格式，是jira票号还是redmine票号
- 前往对应的专案管理工具，找出那张需求票
- 将票号贴进PR标题中、把票号网址贴进PR内容中
- 重复2. ~ 5.项作业，直到commit扫完
转换成自动化的难点应该还是在资讯的取得，也就是：
- github是否有查询branch diff的api?
- jira、redmine是否有查询票号详细内容的api？
有api的话，剩下的就和平时前端做的事情87%像，没有的话就只好认份的用 傀儡师 爬资料了(?
很幸运的，爬文后都有XDDD
大愉悅
上面三者分别需要对应服务的验证机制，前两者是Bearer token、后者为Basic auth，所以最好有个介面可以输入token们和Basic auth的username，再让我有个介面可以指定repo和branch供api查找…
理一下使用者故事大概就是:
- 可以输入github token
- 可以输入redmine token
- 可以输入jira account、token
- 可以输入两个branch name
- 可以用1. 和4. 的资讯打github api拉回branch diff
- 拉回branch diff后，从其中的commits用正规表达式滤出redmine和jira票号
- 若有redmine票号，用所有redmine票号搭配2. 逐项打api拿回相关资讯
- 若有jira票号，用所有jira票号搭配3. 逐项打api拿回相关资讯
- 将7.、8.的资讯整理成markdown并显示在画面上
- 9.的部分可以复制到剪贴簿，最后手动贴到PR上就算完成功能
技术选择：
大概知道要做什么之后，就轮到思考要用什么技术来弄出这东西…
token等相关设定似乎不方便外流，而且又有点懒得部署到网路上…那就是 电子 了，在自己桌面上直接启动App来使用吧！
前端框架的部分倒是毫不犹豫地选了 反应 ，因为还没用React实做过任何作品嘛(自找麻烦XD
Javascript的部分，也来尝试一下 打字稿 好了，大不了之后写成anyscript(不对
接着找寻有没有现成的Electron + React template，翻了翻github上还不少这种template，就挑个顺眼且结合了 快的 的模板： 电子反应
UI library的部分就爬了些网路文章：
5 个最佳 React UI 框架，可在 2022 年更快地构建 Web 应用程序
看了看简介再稍微看看各套件的文件，最后选了文件感觉较亲切点的 材质界面 **** (隔壁的查克拉UI好抢眼啊！
最后的问题便是CSS library要用谁好，在 unoCSS 和Tailwind之中犹豫了几秒…上面好像够多未知数了，至少CSS这边先用长期配合的切版好战友 顺风 吧XD
所以最后的选择变成：
接着就来开工吧！
v1.0
打铁趁热，马上一天内先弄出了个第一版体验一下，大致上可以满足上述一开始提出的功能，另外补上把设定写入local storage的功能，减少每次打开就要一路贴token的额外麻烦。
v1.0，沒什麼用到tailwind的外觀
心得和难点稍微记录一下：
- material ui的 sx 道具 还满强大的，library内部的的component都可以使用这个prop来进行排版，也是tailwind大幅减少出场机会的元凶。
- 正规表达式每次都上网找别人组好的，真的要自创pattern还是只能乖乖面对，靠 正则表达式101 不断的try and error才顺利完成两种pattern。
- 连续fetch jira和redmine的作法，原本傻傻地用forEach去逐项打api，但结果就是造成各种非同步状态管理的不方便，最后使用 承诺.all() 来进行处理，直接使用一个函式去map票号阵列，回传一个包含各个Promise fetch的阵列来进行Promise.all()，就可以很好的等待所有票号api都完成后再开始处理所有资料。
- jira和github token如果commit起来推到github上，会马上寄讯息通知你token已外泄并强制注销，颇为安心啊XD
- 剪贴板在electron内有自己的 api ，简单好用。
- TS的型别检查真的严格，花了不少时间解，不过很高机率是该方法可能回传null和undefind的情况下，必须确保其型别已经有所列举。
v2.0
开心的用着v1.0开PR几分钟后，就觉得…那些设定没事可以不用看到吧？还有要对不同repo开PR，每次都要在input上剪剪贴贴也是挺麻烦的，以及branch只有dev、release、production三个选项，其他repo的staging和feature branch我也想用啊啊啊啊！
身为前端，满足自己的UX应该也是很合理的吧？
于是开始思考优化的方向：
- 设定相关应该可以独立出一个分页，设定好应该就不用看它了
- repo和branch应该可以对选项进行CRUD，但Update有点麻烦，CRD就好(?
- 因为2的关系，repo栏位可以从input变为selector
- 该拆出component了，当前的v1.0全部都挤在App.tsx中
方向都有了，那就开始优化吧！
拆分大成功 ☆
同样的记录一下心得和难点：
- 因为主架构变为App内包含ActionPanel、SettingPanel两个component，但ActionPanel会需要SettingPanel设定的资料，故设定相关资料依旧留在App内，再将资料与其set function用props往两个Panel component传下去。
- branch、repo的列表设定介面基本上就是个todo list component，另外将部分icon、placeholder、data、set function抽成props，就可以复用成两个列表了。
- 子层input onInput事件去触发父层的set function更新整个object会造成子层re-render，看起来像是输入一个字元就强制blur的bug，目前解决方法是不即时触发set function，待输入完毕后按下储存钮再一次触发所有set function来避免这情况。
v3.0
这版主要是来自同事的两个需求，有其他使用者当然要好好照顾一下啊XD
来自同事的需求part 1：
白色好伤眼喔，可以有Dark mode吗？
伟哉Material ui有内建 黑暗模式 ，主要是应用的react hooks的createContext，让 主题提供者 内的所有元件都可以取得 切换颜色模式 来进行切换，并使用已包装好的 在主题（） 来取得相关的设定值，再补上一些对应元件的颜色切换，和之前一样把设定往local storage内储存，便能开心完成Dark mode啰！
工程師友善介面
来自同事的需求part 2：
要追更新很麻烦耶，一般桌面软体不是都有自动更新吗？
看了下electron确实有 自动更新 的套件，并且仰赖electron自家的server对指定repo的github release进行比对确认是否有更新释出，完全不需要自架server来处理这段，实在是非常优秀XD
魔鬼藏在細節處QQ
马上照着指引安装套件，再将package.json内的repo设定好…
最后一步便是要设定Builds时的code-signed用以证明这个App无毒友善，macOS需要申请 苹果开发者计划 来能签署，赶快来申请一下吧！
年費$3400的高牆阻擋於此
果断放弃实作自动的念头，直接把钱拿去刷了 github副驾驶 ，感谢苹果让我如此果断，side project写一写顺便刷了copilot，真香XDDD
但是自动更新的需求还是没有解决，重新思考一下，问题应该是在：
使用者不主动查询的情况下，不会知道软体发布更新了
不能自动下载安装更新，但换成通知使用者有更新，后面的下载安装交给使用者自助，应该有机会吧？
于是找到有基于原有服务的通知版套件 电子更新通知器 ，基本设定和原有服务一样，马上可以直接沿用，重启App便会自动侦测到new release并跳出通知啦！
按下Download就會導至release頁面囉
早知道这功能应该先做上去的，相见恨晚莫过于此。
目前这专案就更新到v3.0.1，相较一开始的需求要多做了点东西上去，整体开发体验也是挺舒服的（除了那个Apple Developer Program），暂时如果没有其他需求被提出来可能就是偶尔修修bug或是improvement吧！
另外就是electron打包后的档案肥硕问题暂时好像无解，这专案安装后居然就要200多MB，让人意外到不行，下次来试看看其他资深大大建议基于Rust和webview的 艰辛 ，看起来可以有效减低打包体积呢！
最后还有个和开发较无相关的部分，就是为了不想用预设的App icon，请教了公司的UI/UX如何使用figma做点简单的图示，成果就是一开始的图片啦，写side project就是会点到其他技能树呢(?
若有其他指教欢迎留言或是发PR，或是有相关需求欢迎许愿让我练练手喔！
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/37456/26341803
标签：PR,写个,票号,github,token,api,产生器,branch From： https://www.cnblogs.com/amboke/p/16704120.html