Archives for : 前端

第1293天:开发环境和生产环境复杂接口场景

由于历史原因,接口有点混乱,有的是开发环境和生产环境共用,有的有区分,被逼出了这么个解决方案,看上去不会出错了。

// 环境判断
const isProdEnv = xxxxxxx

// 域名列表
const server = ‘https://server.xxx.chat/’
const test = ‘https://test.xxx.chat/’
const www = ‘https://www.xxx.chat/’
const wx = ‘https://wx.xxx.chat/’
const api = ‘https://api.xxx.chat/’

export const baseUrls = {
basic: isProdEnv ? server : test,
login: isProdEnv ? www : www,
scene: isProdEnv ? www : wx,
message: isProdEnv ? server : server,
redirect: isProdEnv ? www : test,
pay: isProdEnv ? api : api,
socket: isProdEnv ? www : www,
}

第1292天:前端编码约定

简单整理了一份《前端编码约定》,这是其中一条:

组件思想
参考:https://cn.vuejs.org/guide/essentials/component-basics.html

页面入口文件是一个集合组件的文件,不要直接在入口文件写业务代码。

即:进入一个页面,首先看到的是一棵树,然后才能看清它的树枝 (component) 和树叶 (children),而不是一开始就掉进树里,看不清方向。

第1259天:圆形进度条用 conic-gradient 只要几行代码

今天折腾这玩意,从复杂到简单,最后发现只要这几行就能解决,效果还十分优雅。

css

.progress-circle {
width: 100px;
height: 100px;
border-radius: 50%;
}

html

const progressStyle = `background: conic-gradient(#fff ${progress}%, rgba(0, 0, 0, 0.3) 0%)`

<View className=”progress-circle” style={progressStyle} />

${progress} 是变量,0 到 100。

第1225天:第一次写 sql 语句

20240509-1

发现这样换行组织语句,可读性还蛮好的,排错也容易。

第1224天:MySQL Workbench

有老司机带的感觉,真好。

第1223天:mysql2

这两天 get 新知识。

以前的后端技能半桶水不到,现在有半桶水了。

借助 mysql2,小程序云函数轻松连接 mysql.

第1208天:看 TaroUI 源码受到启发

前两天弃坑了,打算还是自己搞 UI,于是就想看看人家的写法,借鉴一下。

看了之后果然收获不小。把 api、utils 都集中放在 index 去 export,开发、维护、调用都好方便。

第1205天:TaroUI 不太稳

今天使用 WebView,报这个错:

Template `tmpl_0_67` not found

前几天也有遇到类似问题,添加这段配置可以解决:

compiler: {
type: ‘webpack5′,
prebundle: {
exclude: ['taro-ui']
}
}

而 WebView 这个问题,社区连 issue 都搜不到。TaroUI 开发交流群也比较冷清。

Taro 在维护,而 TaroUI 看起来已经被抛弃,导致不兼容。

还好早发现,没陷太深。果断弃坑。

第1166天:重新安装 cnpm 的坑

三四年没有碰 npm,发现 cnpm 几年前就改了域名,原来的已经不能再使用。

不知道咋回事,npm 和 cnpm 都用不了,重装 node 和升级 node 都没用,单独升级 npm 也升级不了。

最后发现重装 cnpm 就行了。

不过直接 install cnpm 也不行,安装失败,需要先 uninstall,然后再 install.

这坑,必须 mark 一下。

npm uninstall -g cnpm

npm install -g cnpm –registry=https://registry.npmmirror.com

第1162天:Git工作流规范

写了一份 Git 工作流规范,方便团队协作。

基础分支(不要直接在这两个分支上开发)

  • develop (开发环境)
  • master (生产环境,主分支)

工作流基础

  • feature (开发分支,从 develop 拉取)
  • release (预发布分支,从 develop 拉取)
  • hotfix (补丁分支,从 master 拉取)
  • merge (合并分支)

第一部分:开发

创建个人开发分支

  • 开始新功能开发时,每个人都基于 develop 创建一个新的 feature 分支,这个 feature 不会影响他人。
  • 每天提交代码到自己的 feature,避免本地代码意外丢失。

同事之间同步代码

  • 每天都把 develop 分支 merge 到你的分支。如果长时间没有进行这项操作,那么将来 merge 分支时很可能会有大量代码冲突。
  • 如果确认你分支的代码已经可以正常运行,记得把你的分支 merge 到 develop。
  • 如果有需要,同事之间也可以互相 merge 分支,你 merge 我的,我 merge 你的。

解决代码冲突(这个很重要)

  • 如果 merge 分支时发生代码冲突,一定要找冲突方确认。
  • 群里截图问一下这段代码是谁的,双方确认后手动解决,避免误删同事代码。

第二部分:测试

  • 所有人把自己的分支合并到 develop 分支,将 develop 代码提交到测试环境进行测试。
  • 如果有 bug,大家仍然在自己的分支中修改,修改完后再 merge 到 develop 分支。

第三部分:预发布

  • 所有人把自己的分支合并到 develop 分支,由专人从 develop 拉 release 分支,进行发布前的最后测试。
  • 此时应该没有大的问题,如果有问题,大家可直接在 release 分支修改。

第四部分:发布

  • release 分支确认最终测试通过后,由专人将 release 合并到 develop 和 master 分支,将 master 发布上线。
  • 到这一步后,此前参与开发的所有分支都不要再使用,可以删除本地分支。新的功能拉取新的 feature 进行开发。

第五部分:bug修复

  • 如果需要修复线上 bug,从 master 拉取 hotfix 分支,修复完成后合并到 develop 和 master 分支,将 master 发布上线。