vue与mobx

最近接触到MobX,读了读api,发现其结合了vue,meteor的一些写法,为了源码看得更明白些还特意看了看typescript。

其autorun的api很早之前在meteor上看过,当时觉得特别神奇。哇,这就能自动监听数据更新并运行了,当时还以为meteor是靠厉害的词法分析来推倒出数据依赖关系呢。

后来看了vue,发现这种依赖是通过get来收集依赖,然后在set的时候再触发依赖运行。但由于一直以为autorun会在收集依赖之前就可以运行,仍然觉得autorun很神奇。

后来运行了一下mobx例子才发现其autorun和vue一样,其监听函数也必须初始全运行一次收集好依赖关系,才能在数据更新时正确运行。那种我以为的只有在数据更新时,autorun才会开始正确执行的想法是错误的。meteor的autorun也不是靠什么厉害的词法分析来实现的。底层大概也是靠Object.defineProperty来实现的,虽然还没看过meteor的源码。

Posted in ecmascript | Leave a comment

编程与游戏

小时候打过不少电子游戏,工作后总会回想起当年荒废了的那些时光,但当年也确实得到了很多欢乐。

最近有个新同事入职,很爱学习但是从来不玩游戏。一般来说程序员不太可能有从来没玩过游戏吧,他大概属于那种特别听话的好孩子吧,于是我经常在指导程序之余用程序和游戏举个例子,顺带吐他个槽—-让你不玩游戏哈~。

自从干上了程序员,那种对游戏的执着有一部分确实的转移到了代码上。比如当年玩的各种rpg,都会想打个完美存档,该收的宝物一定要收到,该走的情节一定要走全。这种执着转移到代码上之后,就变成了什么地方都会想做到最优。但什么是最优呢,在不同的编成阶段,也会有不同的理解。就像《黑客与画家》里描述的,这种优化(绝大多情况下指的不是运行效率,而是指架构和谐,命名合理,模块复用等等)没有尽头,只有程序员最后不想做了的结果。

很多游戏有二周目,在一周目打不了的情节,或者一些单选的分支只有在多周目中才能凑全。体现到项目中,恩其实你可能已经想到了,那就是重构。重构由什么人来进行呢?必须是做过该项目的同一批人马,如果说换了一波人重构,那和第一次做也差不了太多,该趟的雷还是得趟,躲不过的。就像即使玩二周目的游戏,如果换了个玩家,一周末的存档有哪些分支走过了,有哪些窍门统统不知道,除了继承了点金钱和装备(项目第一版的代码),和第一次玩也没啥区别。

我时常教导年轻同事,当你接触到一个新框架,新类库时,一定要先把整个api文档看一遍,不指望记住,事实也记不住,为的是大概有个印象。当你需要用的时候不用自己造轮子,还没人家现成的造的好用。这条经验对应到小时候玩的街霸、拳皇,就是你可以直接玩,但是不会发招,总是被打。api文档就相当与出招表,过一遍,选个合适的人物,投入实战开练,在与其他角色的碰撞中逐步熟悉,知道什么情况下用什么招数,尤其是在合适的机会用终结技取胜,满足感爆棚。

 

Posted in 未分类 | Leave a comment

react或vue的数据应该在什么时候开始请求

之前在做react的时候,一开始都照着例子,在componentWillMount里进行数据加载请求。

后来在新项目中使用vue,也在beforeMount中开始数据加载请求。

面试的时候被人提问过,也是这么回答的,人家也没就这个话题说太多。

最近在项目中发现这种方法实在是有问题,当当前组件开始载入时,进行数据请求,在请求回调中设置当前组件的数据(react与vue的生命周期比较类似,可以当作同一种来说明)。但如果数据返回较慢,此时用户切换到其他路由,组件已经卸载,一则组件的this在请求数据的回调中存在是内存泄漏,二则组件已经卸载,再更新自身的数据肯定有问题。

我想出来的解决方法有两种

一,是在组件生命周期外部请求数据,在数据确实拿到后再挂载组件。

二,终极解决方法,其实已经用了有一阵子了,但一直没有发现这个好处,即react + redux,vue + vuex。将数据放到外部,其实也相当于将数据请求放到组件的生命周期外部。

有些小项目本以为数据没多复杂,可以不用redux/vuex这种外部数据管理,但如果自己管理数据的话往往又麻烦又容易出各种问题。这样看来,全家桶还是必要的。

Posted in ecmascript | Leave a comment