写点什么

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

  • 2019-02-25
  • 本文字数:3852 字

    阅读完需:约 13 分钟

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

前言

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


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

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

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

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

1. Gitter



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  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 解析云函数


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 组件


// 云函数解析markdownparseReadme() {  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    })  })}
复制代码


// 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。


// 获取个人信息export const getUserInfo = createApiAction(USERINFO, (params) => api.get('/user', params))
复制代码


// actionexport 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 }) } }}
复制代码


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)
复制代码


// reducersexport 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 小程序能对你有所帮助!


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



2019-02-25 08:159676

评论 3 条评论

发布
用户头像
mark
2019-03-17 09:35
回复
用户头像
体验了一下,真的不怎么好,如果用原生开发会比较不错,taro这个坑再也不会迈进了,国内的开源项目真的是慎入坑,怀念linux、spring...这些开源项目的时代
2019-02-27 14:56
回复
你好,能讲解一下,具体哪方便体验不好么,正在选型,考虑用什么框架
2019-03-27 11:48
回复
没有更多了
发现更多内容

智能工厂 | 联合汽车电子有限公司汽车驱动科技上海智能工厂

工赋开发者社区

MySQL SQL脚本语句加上数据库存在判断

Andy

经典智能合约案例之发红包

timerring

区块链

C语言编程—枚举

芯动大师

数据可视化管理尽在RazorSQL注册激活版~

真大的脸盆

Mac 数据库管理 Mac 软件 管理数据库 数据库处理

iOS MachineLearning 系列(20)—— 训练生成CoreML模型

珲少

Go Module 语义化版本规范

江湖十年

Go 语言 go module go mod

知识点总结

程序员小张

1行代码合并多个PPT文件,Python自动化办公

程序员晚枫

Python PPT 自动化办公

线程池是如何执行的?任务太多会怎样?

javacn.site

2023-05-28:为什么Redis单线程模型效率也能那么高?

福大大架构师每日一题

redis 福大大

深度学习进阶篇-国内预训练模型[5]:ERINE、ERNIE 3.0、ERNIE-的设计思路、模型结构、应用场景等详解

汀丶人工智能

人工智能 自然语言处理 深度学习 文心 ERNIE Transformer

CSS小技巧使用 font-variation 让文字起飞

南城FE

CSS 设计 前端开发 动画 字体

Git安装和配置教程:Windows/Mac/Linux三平台详细图文教程,带你一次性搞定Git环境

小万哥

git Linux 程序员 后端 C/C++

MySQL 启动apollo-adminservice 报错 Caused by: java.sql.SQLSyntaxErrorException: Unknown column 'serverconf0_.Cluster' in 'field list

Andy

文心一言 VS 讯飞星火 VS chatgpt (24)-- 算法导论4.2 6题

福大大架构师每日一题

福大大 ChatGPT 文心一言 讯飞星火

LangChain:构建个人AI代理从这里开始

devpoint

人工智能 AI langchain

ChatGPT对软件测试的影响

BY林子

软件测试 ChatGPT

人工智能与数据分析

Data 探险实验室

人工智能 机器学习 AI 数据分析 数据

MySQL Idea 启动主程序 无法识别时区

Andy

大模型全情投入,低代码也越来越清晰

引迈信息

低代码 大模型 JNPF

经典智能合约之智能拍卖

timerring

区块链

GPT用于复杂代码生产所需要满足的必要条件

canonical

低代码 GPT GPT-4 可逆计算

实测 亚马逊AI 编程助手 Amazon CodeWhisperer(全网最全)

攻城先森

人工智能 编程 测试 AWS 亚马逊云科技

软件测试/测试开发丨学习笔记之Web自动化测试

测试人

程序员 软件测试 自动化测试 测试开发 web自动化

用Python做一个翻译器 | Python小知识

AIWeker

Python 人工智能 python小知识

希尔伯特旅馆里,住着AI的某种真相

脑极体

AI 智能涌现

七年老程序员的三四月总结:三十岁、准备婚礼、三次分享

拭心

程序人生 总结思考

软件测试/测试开发丨学习笔记之用户端Web自动化测试

测试人

程序员 软件测试 自动化测试 测试开发 web自动化

QUIC 协议:特性、应用场景及其对物联网/车联网的影响

EMQ映云科技

车联网 物联网 mqtt QUIC

写给程序员的可逆计算理论辨析

canonical

开源 低代码 Docker 镜像 可逆计算 Nop平台

Gitter:高颜值GitHub小程序客户端诞生记_大前端_huangjianke_InfoQ精选文章