沪江网前端沙龙第二期的回顾

0

昨天参加了沪江网的沙龙, 分享了一下最近研究 Redux 的心得和想法
结束以后还听贺老讲了好多东西, 回来很累, 所以回顾的笔记拖到今天了

单向数据流的分享

我分享的内容主要关于 React 数据层的一些想法, 都是网上拼凑起来的
其实演讲的核心内容, 我尝试写过博客的, 主要是归纳了 Kafka 的文章一些想法
In Flux and SSOT, Store is not the Truth, Actions is!
包括近期对简聊的数据层做调整, 也添加了很多的思考和代码
对我而言单向数据流这个未来的方向已经很明确了, MVC 都过时了
单向数据流基于不可变数据, 或者说是 FRP(函数式响应式编程)

然后 actions-recorder 对我来说其实是很重要的项目
觉得 Redux 引入概念太多, 于是自己山寨的方案, 并且计划在简聊运用
实际上在单页面应用的调试中, 前面几天确实已经起到作用了的
我用 recorder 查看 store 数据, 查看 action 操作内容, 梳理加载逻辑
对照 Redux 在国外的轰动效果, 我原本对这个期待是挺高的

从反馈来看, 现场做单页面应用的同学并不多的样子
活动中聊过的同学也都很年轻, 对 React 的具体使用会挺关心
比起去前在蘑菇街那次分享, 确实热闹多了. 当然毕竟都不是 React 专门的会
有问到 React 在 Teambition 的情况, 实际只是简聊团队的 Web 前端而已
相比淘宝和 Strikingly 那样的投入, 我们只是在专心对付单页面应用
但是呢, 那么多人对 React 感兴趣还是很开心的

数据层

React 带来的冲击, 我觉得一定程度上就是 FRP 带来的冲击
virtual dom 进入大众的视野是从 React 开始, 然而马上跟 FRP 紧密结合
其他的 React 当中的不可变数据, 全局状态, 在 Clojure 社区早已尝试
以及 React 组件主要的性能优化的方式, 都受到 Om 影响很大
最近的 Time Travelling Debugger 就完全是走在 Elm 和 Om 的后面

React 作为一个 view library, 几乎影响到 Web 上各种渲染框架和方案
同时不可变数据和 Actions 的概念没有悬念地成为了标配
接下来, 就是对于 Model 这一层开始施加影响了
之前的 Flux 我认为是权宜的方案, 发挥了作用, 也正在渐渐淡出
Facebook 推出 Relay, Netflix 推出 Falcor, 社区发布 Redux
加上各种琐碎的实现, 目前没有呼声一致的一个方案

数据层涉及的方面太广了, 浏览器内存, 网络同步, 服务器接口, 数据库
单单 Relay 就提出了 GraphQL Server 的概念需要大量的代码去实现
至于前端用了不可变数据, 之后呢, 怎样是最合适的办法? 不清楚
有的人用 React 渲染界面, 后边是 Backbone 或者 Angular
有的人用 JSON 对象存储数据, 有的用 immutable-js, 但是具体结构又多种多样
更重要的是要把前后端数据打通, 简直又是一场破坏 Best Practice 的行动
然而这一次 React 社区提供的方案并没有那么顺利, 也不能覆盖所有场景

比如简聊来说, 前端用 immutable-js, 跟后端用 Restful 形式的 API
API 分成两部分, 一部分是请求, 一部分是推送, 需要精确的数据更新
而且更多的情况是后端数据更新, 前端跟着做出响应, 类似数据同步
首先我们切换话题抓取消息的结构, 并不是和组件绑定的, 不像 GraphQL
其次服务器推送更新的机制, 并没有看到 GraphQL 给出明确的方案
我们在单页面应用上希望做到增量更新, falcor 似乎接近一些, 但也未必能用

再有一点, 当我们的应用, 在前端保存较多的数据之后, 数据就需要有效的管理
首先, 为了方便 React 渲染和性能优化, 我们不会去用 IndexedDB 异步管理数据
其次, 我们要考虑数据界面分离, 甚至尝试服务端渲染的方案, 需要独立的数据层
再者, 前端缓存了数据, 怎样和服务器更新保持同步也是问题, 而且两者结构不同
我的判断是, 前端要么完全从后端同步数据, 要么模拟一遍数据库, 再做考虑
前者是我个人项目的 Cumulo, 目前看来太过粗暴, 走向实用难度很大
后者同样是一个缺乏经验的领域, 大概需要大神为我们开路

Best Language

对了, 被贺老黑了 Haskell 的事情, Monad 的梗, 果然还是应付不了
我现在大致能明白 List Monad 和 IO Monad 基本的用法和目的了
主要是在 Haskell 里的类型类, 定义了 join >>= >> 等几个函数
复杂的情况比如 Reader Monad Writer Monad 就用不起来了嗯
至于九瓜老师没事在微博上发的神作 Free Monad 怎么怎么更搞不明白

当然我依然认为 Haskell 是最好的语言, JavaScript 只能算最好的平台
编程语言本身需要支持数据抽象, 操作抽象, 模块抽象, 语言抽象等等
...大致按照 SICP 的目录, 对应编程当中需要的一些抽象能力
除此之外, 类型系统, 编译工具, 语法糖, 总之有各种被人挑剔的方面
而 JavaScript 从语言本身的设计, 并不能看到很漂亮的内容在里边
而且语言很容易把人引入歧途.. 虽然大部分语言这都是很正常的事情..

而函数式编程语言的研究给我们带来的就不仅仅是语言了
而且还会指引我们程序应该怎样设计, 复杂度通过怎样的方式控制等等
结果就是 Haskell 很多人就不能学到能写代码的程度
即便只是这样, 这已经能让人对程序的理解带来一些改观和提升了
再者 JavaScript 委员会纵然好, 我被 Rob Pike 大神的演讲打动了怎么办

结尾

沪江的沙龙跟 Teambition 的氛围挺像的, 但大公司毕竟麦克风好一点 :P
中间茶歇还有会后的聚餐, 也聊了一会见了挺多朋友.. 还有是加微信..
活动合照已转微博, 其他的照片在微信群里有, 我不想转了, 官方怎么没发下
活动的视频, 活动期间有网上直播的, 稍后可能放出视频吧, 等微信群消息


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

载入中...