312021.3

腾讯3年可以申请更换设备,虽然大家都说Mac好,但是我还是申请更换了一台windows,因为已经有一台iMac,所以打算留一台windows以备不时之需。以前用windows最大的问题是开发环境不好搭,在morningstar的时候,自己装了个vmware跑Ubuntu,但是性能很不爽。而如今windows直接上WSL,在系统底层跑linux子系统,性能和直接用windows没差,简直飞起。而且由于linux子系统和windows主系统共享文件系统和网络,在linux里面跑的服务,直接可以在windows上访问,减少了各种配置工作。而且说实话,windows上的软件,虽然界面确实没有mac好看,但是从功能完整性讲,绝对比mac好很多,在加上winget,总之,现在我已经有点享受windows上开发的乐趣了。

00:34:48 已有0条回复
112021.3

Tally可视化表单

092021.3

2021年中国低代码/无代码市场研究报告

012021.3

移动端 JS 引擎哪家强?

JS 糟粕之全局变量和引用

JS的全局变量是排第一的糟粕。比如:

const a = 1

function get() {
retun a
}

函数内可以直接使用一个函数外的变量,而且可以层层往上引用。如果这个变量还是对象的话,还可以修改对象。例如:

const o = { count: 0 }

function set(count) {
o.count = count
}

这种写法,由于我们写JS写的久了,觉得天经地义,而且还是个与其他语言不同的特性(优点),殊不知,这种东西,害人害己。

全局变量的设计,会使得内存引用及其复杂,且导致内存溢出。虽然js是自动回收垃圾,但是实际上很多情况下开发者需要自己手动释放,而且由于全局变量这个特性,根本释放不了。

如果要改进这门语言,我觉得可以学习rust,去掉全局变量这种东西。

const a = 1
function get(&a) {
return a
}

const b = get(a) // b === a === 1
let b = a // a === null, b === 1

// ---------------

mut o = { count: 1 }
function set(mut &o, int count) {
o.count = count
}

function clone(o) {
return o
}
const n = clone(o)

虽然这使得这门语言麻烦很多,理解起来更复杂,但是可以避免很多问题。

10:19:08 已有0条回复
232021.2

不用纸和笔,一样能搞定手绘风PPT!

222021.2

react jsx编译后中文乱码问题

在一次开发中,我发现,构建出来的react应用出现中文乱码现象。于是我很自觉的,在html头部添加 <meta charset="utf-8" />,然后问题解决了。但是作为资深搬砖人,必须得搞清楚,为啥会乱码。

于是我打开了构建后的文件,发现里面中文被转码为unicode了。

这就尴尬了,但是经过观察之后,我又发现,只有createElement的部分被转码,其他部分的中文还是中文。

于是我想,肯定是编译工具在搞鬼,我得找到是哪个地方的问题,把这个转译给关闭。要么是webpack,要么是babel jsx。

于是还是用bing进行中文搜索,没有一个结果指向这个问题。再用英文搜,也没有找到相关解决办法。最后只能请出google大神,找到这个栈漏答案,找到了相关资料。兜兜转转一大圈,发现这是react自己埋的坑,跟编译工具无关(也有关),总之就是关不掉,只能这样,放弃挣扎。

11:02:23 已有1条回复
  1. 之前也有遇到这情况, 想改个项目里的标题, 搜中文搜不到, 结果发现是unicode
    #1015 ID_1188 2021-03-02 16:29 回复
052021.2

我时常有一些执念,以至于有的时候不合群。我遇到无法修改react传入的props的情况,我大概知道在react源码里面干了些坏事,但是我想确认这一点,于是我在bing搜索相关问题。大部分的答案,无非是和react单向数据流相关的一些废话,谁不知道这些原则,我现在就是想打破这些原则,而我打破不了,你只告诉我原则就是根源,我呸!然后我找了很久,在漏栈上找到一个答案 https://stackoverflow.com/questions/26089532/why-cant-i-update-props-in-react-js 这个答案获得了20个反对票,最主要的原因在于,他指出只有通过修改react核心代码才能实现,于是被一路狂喷。我……我被气炸了!这个回答直指问题本质,就是react中使用Object.freeze(element.props)导致我们修改props会报错。我tm不懂,为啥真正指出问题所在的答案被驳20次,而千篇一律的讲废话的答案得到大量赞同。真是只要主义,不要实际!

18:47:24 已有4条回复
  1. 因为 react 社区动辄喜欢谈设计理念,原则之类的,不考虑实际使用者的场景
    #1006 rxliuli 2021-02-05 19:08 回复
  2. 有的时候爱,有的时候恨,选择太少了
    #1007 回复给#1006 否子戈 2021-02-05 19:52 回复
  3. 没,有时候吾辈反而觉得前端选择太多了,各种乱七八糟的工具链和层出不穷的类似的轮子,上层应用的基础变化太快了。。。
    #1008 回复给#1007 rxliuli 2021-02-05 19:57 回复
  4. 有趣的例子.
    #1009 ID_1188 2021-02-09 15:40 回复
222021.1

动态表单可视化拖拽设计器

132021.1

我为什么不在async函数中使用try...catch?

总之一句话:在async函数中使用try...catch会导致调试难道增加。且任何使用使用try...catch的场景,都会增加调试难度,比如react的报错信息,有的时候,你怎么都找不到问题代码具体在哪个位置。

当一个Error产生的时候,Error会用stack字段记录该Error产生的具体位置。只有,我们得到原始的Error,才能获得原始的stack信息,但是通过try...catch语法,往往会屏蔽原始的Error,导致我们追逐不到错误的原始位置。比如:

<script>
  'use strict'

  async function calc() {
    try {
      const x = await a + await b
      const y = x + await z
      return y
    }
    catch (e) {
      alert('计算错误')
    }
  }

  calc()
</script>

我们用alert来替代我们经常使用的toast, popup等方法。一旦我们通过交互形式接住错误时,我们就直接放弃了获得错误原始信息的权利。

async函数本质上是创建一个异步函数,而非创建一个封闭式的闭包。没错,如果你在async函数中使用try...catch跟使用闭包没有什么区别。异步函数的目标,是完成异步操作,但其中重要的一点是,它的错误是可以被捕获的。为了实现这种捕获,有些开发者会在 catch 中再次把错误抛出来,比如 catch (e) { throw e }。但是这样做,会导致程序在这里又结束了。所以,这种做法又不符合在async函数中使用try...catch的目的。

对于我个人而言,我从来不直接在async函数中使用try...catch,定义async函数是一个纯粹的async...await结构,在使用该函数时,使用.then().catch().finally()接住函数执行过程中的结果逻辑。

10:13:34 已有2条回复
  1. 有点误人子弟了。。。async 函数中的 try/catch 和 then/catch 没什么区别吧?
    #999 rxliuli 2021-01-13 12:07 回复
  2. 要正确使用
    #1001 rxxy 2021-01-14 17:28 回复