Gitter：高颜值 GitHub 小程序客户端诞生记

前言

嗯，可能一进来大部分人都会觉得，为什么还会有人重复造轮子，GitHub 第三方客户端都已经烂大街啦。确实，一开始我自己也是这么觉得的，也问过自己是否真的有意义再去做这样一个项目。思考再三，以下原因也决定了我愿意去做一个让自己满意的 GitHub 第三方客户端。

• 对于时常关注 GitHub Trending 列表的笔者来说，迫切需要一个更简单的方式随时随地去跟随 GitHub 最新的技术潮流；

• 已有的一些 GitHub 小程序客户端颜值与功能并不能满足笔者的要求；

• 听说 iOS 开发没人要了，掌握一门新的开发技能，又何尝不可？

• 其实也没那么多原因，既然想做，那就去做，开心最重要。

1. Gitter

• GitHub： https://github.com/huangjianke/Gitter ，可能是目前颜值最高的 GitHub 小程序客户端，欢迎 star

• 数据来源：

GitHub API v3： https://developer.github.com/v3/

目前实现的功能有：

• 实时查看 Trending

• 显示用户列表

• 仓库和用户的搜索

• 仓库：详情展示、README.md 展示、Star/Unstar、Fork、Contributors 展示、查看仓库文件内容

• 开发者：Follow/Unfollow、显示用户的 followers/following

• Issue：查看 issue 列表、新增 issue、新增 issue 评论

• 分享仓库、开发者

• …

Gitter 的初衷并不是想把网页端所有功能照搬到小程序上，因为那样的体验并不会很友好，比如说，笔者自己也不想在手机上阅读代码，那将会是一件很痛苦的事。

在保证用户体验的前提下，让用户用更简单的方式得到自己想要的，这是一件有趣的事。

2. 探索篇

技术选型

第一次觉得，在茫茫前端的世界里，自己是那么渺小。

当决定去做这个项目的时候，就开始了马不停蹄的技术选型，但摆在自己面前的选择是那么的多，也不得不感慨，前端的世界，真的很精彩。

• 原生开发：基本上一开始就放弃了，开发体验很不友好；

• WePY ：之前用这个框架已经开发过一个小程序， 诗词墨客 ，不得不说，坑是真多，用过的都知道；

• mpvue ：用 Vue 的方式去开发小程序，个人觉得文档并不是很齐全，加上近期维护比较少，可能是趋于稳定了？

• Taro ：用 React 的方式去开发小程序，Taro 团队的小伙伴维护真的很勤快，也很耐心的解答大家疑问，文档也比较齐全，开发体验也很棒，还可以一键生成多端运行的代码 (暂没尝试)

货比三家，经过一段时间的尝试及踩坑，综合自己目前的能力，最终确定了 Gitter 的技术选型：

Taro +  Taro UI + Redux + 云开发 Node.js

页面设计

其实，作为一名 Coder，曾经一直想找个 UI 设计师妹子做老婆的 (肯定有和我一样想法的 Coder)，多搭配啊。现在想想，code 不是生活的全部，现在的我一样很幸福。

话回正题，没有设计师老婆页面设计怎么办？毕竟笔者想要的是一款高颜值的 GitHub 小程序。

嗯，不慌，默默的拿出了笔者沉寂已久的 Photoshop 和 Sketch。不敢说自己的设计能力如何，Gitter 的设计至少是能让笔者自己心情愉悦的，倘若哪位设计爱好者想对 Gitter 的设计进行改良，欢迎欢迎，十二分的欢迎！

3. 开发篇

Talk is cheap. Show me the code.

作为一篇技术性文章，怎可能少得了代码。

在这里主要写写几个踩坑点，作为一个前端小白，相信各位读者均是笔者的前辈，还望多多指教！

Trending

进入开发阶段没多久，就遇到了第一个坑。 GitHub 居然没有提供 Trending 列表的 API！！！

也没有过多的去想 GitHub 为什么不提供这个 API，只想着怎么去尽快填好这个坑。一开始尝试使 用 Scrapy 写一个爬虫对网页端的 Trending 列表信息进行定时爬取及存储供小程序端使用，但最终还是放弃了这个做法，因为笔者并没有服务器与已经备案好的域名，小程序的云开发也只支持 Node.js 的部署。

开源的力量还是强大，最终找到了 github-trending-api ，稍作修改，成功部署到小程序云开发后台，在此，感谢原作者的努力。

• Trending 列表云函数

 复制代码

// 云函数入口函数
exports.main =async(event, context) => {
const{ type, language, since } = event
letres =null;
letdate =newDate()
constcacheKey =`repositories::${language ||'nolang'}::${since ||
'daily'}`;
constcacheData =awaitdb.collection('repositories').where({
cacheKey: cacheKey
}).orderBy('cacheDate','desc').get()
if(cacheData.data.length !==0&&
((date.getTime() - cacheData.data[0].cacheDate) <1800*1000)) {
res =JSON.parse(cacheData.data[0].content)
}else{
res =awaitfetchRepositories({ language, since });
awaitdb.collection('repositories').add({
data: {
cacheDate: date.getTime(),
cacheKey: cacheKey,
content:JSON.stringify(res)
}
})
}
return{
data: res
}
}

Markdown 解析

嗯，这是一个大坑。

在做技术调研的时候，发现小程序端 Markdown 解析主要有以下方案：

• wxParse ：作者最后一次提交已是两年前了，经过自己的尝试，也确实发现已经不适合如 README.md 的解析

• wemark ：一款很优秀的微信小程序 Markdown 渲染库，但经过笔者尝试之后，发现对 README.md 的解析并不完美

• towxml ：目前发现是微信小程序最完美的 Markdown 渲染库，已经能近乎完美的对 README.md 进行解析并展示

在 Markdown 解析这一块，最终采用的也是 towxml，但发现在解析性能这一块，目前并不是很优秀，对一些比较大的数据解析也超出了小程序所能承受的范围，还好贴心的作者 ( sbfkcel ) 提供了服务端的支持，在此感谢作者的努力！

• Markdown 解析云函数

 复制代码

constTowxml =require('towxml');
consttowxml =newTowxml();
// 云函数入口函数
exports.main =async(event, context) => {
const{ func, type, content } = event
letres
if(func ==='parse') {
if(type ==='markdown') {
res =awaittowxml.toJson(content ||'','markdown');
}else{
res =awaittowxml.toJson(content ||'','html');
}
}
return{
data: res
}
}

• markdown.js 组件

 复制代码

// 云函数解析 markdown
parseReadme() {
const{ md, base } =this.props
letthat =this
wx.cloud.callFunction({
// 要调用的云函数名称
name:'parse',
// 传递给云函数的 event 参数
data: {
func:'parse',
type:'markdown',
content: md,
}
}).then(res=>{
letdata = res.result.data
if(base && base.length >0) {
data = render.initData(data, {base: base,app:this.$scope})
}
that.setState({
fail:false,
data: data
})
}).catch(err=>{
console.log('cloud', err)
that.setState({
fail:true
})
})
}

 复制代码

// Markdown 渲染
render() {
const{ data } =this.state
return(
<View>
{
data ? (
<View>
<import src='../towxml/entry.wxml' />
<template is='entry' data='{{...data}}' />
</View>
) : (
<View className='loading'>
<AtActivityIndicator size={20} color='#2d8cf0' content='loading...' />
</View>
)
}
</View>
)
}

Redux

其实，笔者在该项目中，对 Redux 的使用并不多。一开始，笔者觉得所有的接口请求都应该通过 Redux 操作，后面才发现，并不是所有的操作都必须使用 Redux，最后，在本项目中，只有获取个人信息的时候使用了 Redux。

 复制代码

// 获取个人信息
exportconstgetUserInfo = createApiAction(USERINFO, (params) => api.get('/user', params))

 复制代码

// action
exportfunctioncreateApiAction(actionType, func = () =>{}) {
return(
params = {},
callback = {success:()=>{},failed:()=>{} },
customActionType = actionType,
) =>async(dispatch) => {
try{
dispatch({type:`${customActionType }_request`, params });
constdata =awaitfunc(params);
dispatch({type: customActionType, params,payload: data });

callback.success && callback.success({payload: data })
returndata
}catch(e) {
dispatch({type:`${customActionType }_failure`, params,payload: e })

callback.failed && callback.failed({payload: e })
}
}
}

 复制代码

getUserInfo() {
if(hasLogin()) {
userAction.getUserInfo().then(()=>{
Taro.hideLoading()
Taro.stopPullDownRefresh()
})
}else{
Taro.hideLoading()
Taro.stopPullDownRefresh()
}
}
constmapStateToProps =(state, ownProps) =>{
return{
userInfo: state.user.userInfo
}
}
exportdefaultconnect(mapStateToProps)(Index)

 复制代码

// reducers
exportdefaultfunctionuser(state = INITIAL_STATE, action){
switch(action.type) {
caseUSERINFO:
return{
...state,
userInfo: action.payload.data
}
default:
returnstate
}
}

目前，笔者对 Redux 还是处于一知半解的状态，嗯，学习的路还很长。

有需要的同学可以前往开源仓库查看相应的完整源码，还请多多指教。

4. 结语篇

当 Gitter 第一个版本通过审核的时候，心情是很激动的，就像自己的孩子一样，看着他一点一点的长大，笔者也很享受这样一个项目从无到有的过程，在此，对那些帮助过笔者的人一并表示感谢。

当然，目前功能和体验上可能有些不大完善，也希望大家能提供一些宝贵的意见，Gitter 走向完美的路上希望有你！

最后，希望 Gitter 小程序能对你有所帮助！

更多内容，请关注前端之巅。