0. 前言
嗯,可能一进来大部分人都会觉得,为什么还会有人重复造轮子,GitHub第三方客户端都已经烂大街啦。确实,一开始我自己也是这么觉得的,也问过自己是否真的有意义再去做这样一个项目。思考再三,以下原因也决定了我愿意去做一个让自己满意的GitHub第三方客户端。
对于时常关注GitHub Trending列表的笔者来说,迫切需要一个更简单的方式随时随地去跟随GitHub最新的技术潮流;
已有的一些GitHub小程序客户端颜值与功能并不能满足笔者的要求;
听说iOS开发没人要了,掌握一门新的开发技能,又何尝不可?
其实也没那么多原因,既然想做,那就去做,开心最重要。
1. Gitter
GitHub:https://github.com/huangjianke/Gitter,可能是目前颜值最高的GitHub小程序客户端,欢迎star
数据来源:GitHub API v3
目前实现的功能有:
实时查看Trending
显示用户列表
仓库和用户的搜索
仓库:详情展示、README.md展示、Star/Unstar、Fork、Contributors展示、查看仓库文件内容
开发者:Follow/Unfollow、显示用户的followers/following
Issue:查看issue列表、新增issue、新增issue评论
分享仓库、开发者
…
Gitter的初衷并不是想把网页端所有功能照搬到小程序上,因为那样的体验并不会很友好,比如说,笔者自己也不想在手机上阅读代码,那将会是一件很痛苦的事。
在保证用户体验的前提下,让用户用更简单的方式得到自己想要的,这是一件有趣的事。
2. 探索篇
技术选型
第一次觉得,在茫茫前端的世界里,自己是那么渺小。
当决定去做这个项目的时候,就开始了马不停蹄的技术选型,但摆在自己面前的选择是那么的多,也不得不感慨,前端的世界,真的很精彩。
原生开发:基本上一开始就放弃了,开发体验很不友好;
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列表云函数
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// 云函数入口函数
exports.main = async (event, context) => {
const { type, language, since } = event
let res = null;
let date = new Date()
const cacheKey = `repositories::${language || 'nolang'}::${since ||
'daily'}`;
const cacheData = await db.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 = await fetchRepositories({ language, since });
await db.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解析云函数
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
const Towxml = require('towxml');
const towxml = new Towxml();
// 云函数入口函数
exports.main = async (event, context) => {
const { func, type, content } = event
let res
if (func === 'parse') {
if (type === 'markdown') {
res = await towxml.toJson(content || '', 'markdown');
} else {
res = await towxml.toJson(content || '', 'html');
}
}
return {
data: res
}
}
- markdown.js组件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// 云函数解析markdown
parseReadme() {
const { md, base } = this.props
let that = this
wx.cloud.callFunction({
// 要调用的云函数名称
name: 'parse',
// 传递给云函数的event参数
data: {
func: 'parse',
type: 'markdown',
content: md,
}
}).then(res => {
let data = 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
})
})
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Markdown渲染
render() {
const { data } = this.state
return (
<View>
{
data ? (
<View>
<import src='../towxml/entry.wxml' />
<template is='entry' data='' />
</View>
) : (
<View className='loading'>
<AtActivityIndicator size={20} color='#2d8cf0' content='loading...' />
</View>
)
}
</View>
)
}
Redux
其实,笔者在该项目中,对Redux的使用并不多。一开始,笔者觉得所有的接口请求都应该通过Redux操作,后面才发现,并不是所有的操作都必须使用Redux,最后,在本项目中,只有获取个人信息的时候使用了Redux。
1
2
// 获取个人信息
export const getUserInfo = createApiAction(USERINFO, (params) => api.get('/user', params))
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// action
export function createApiAction(actionType, func = () => {}) {
return (
params = {},
callback = { success: () => {}, failed: () => {} },
customActionType = actionType,
) => async (dispatch) => {
try {
dispatch({ type: `${customActionType }_request`, params });
const data = await func(params);
dispatch({ type: customActionType, params, payload: data });
callback.success && callback.success({ payload: data })
return data
} catch (e) {
dispatch({ type: `${customActionType }_failure`, params, payload: e })
callback.failed && callback.failed({ payload: e })
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
getUserInfo() {
if (hasLogin()) {
userAction.getUserInfo().then(()=>{
Taro.hideLoading()
Taro.stopPullDownRefresh()
})
} else {
Taro.hideLoading()
Taro.stopPullDownRefresh()
}
}
const mapStateToProps = (state, ownProps) => {
return {
userInfo: state.user.userInfo
}
}
export default connect(mapStateToProps)(Index)
1
2
3
4
5
6
7
8
9
10
11
12
// reducers
export default function user (state = INITIAL_STATE, action) {
switch (action.type) {
case USERINFO:
return {
...state,
userInfo: action.payload.data
}
default:
return state
}
}
目前,笔者对Redux还是处于一知半解的状态,嗯,学习的路还很长。
有需要的同学可以前往开源仓库查看相应的完整源码,还请多多指教。
4. 结语篇
当Gitter第一个版本通过审核的时候,心情是很激动的,就像自己的孩子一样,看着他一点一点的长大,笔者也很享受这样一个项目从无到有的过程,在此,对那些帮助过笔者的人一并表示感谢。
当然,目前功能和体验上可能有些不大完善,也希望大家能提供一些宝贵的意见,Gitter走向完美的路上希望有你!
最后,希望Gitter小程序能对你有所帮助!