当前位置: 首页 > 工具软件 > lein-figwheel > 使用案例 >

笔记, 关于 figwheel reagent 环境的配置

刘意
2023-12-01

具体步骤很坑爹, 短短的配置折腾了两天, 和 Webpack 一样坑多而且牛逼
加上一些 Cirru 的语法文件, 整个 demo 的项目算是跑起来了
https://github.com/jiyinyiyong/figwheel-demo-in-cirru
简单记录一下过程和想法

关于缩进和 index.html 的插件

首先关于缩进语法写 Cirru 的事情, 更新了两个插件, 基本可用了
https://github.com/Cirru/lein-cirru-sepal/
https://github.com/Cirru/sepal.clj
我对于缩进很极端, 对括号无所谓的话不用管 cirru 相关的文件

然后 index.html 文件, Clojure 社区两个手段
一个是手写, 一个是用 ring server 搭配 hiccup 写
我习惯了前端这边的, 故意搞了插件用 hiccup 命令行生成
https://github.com/mvc-works/lein-html-entry

关于 React ClojureScript 绑定

这个事情有点意外, 原来以为只有 Om, 实际上有很多, 收集了下
http://react-china.org/t/reagent-minimalistic-react-for-clojurescript/3064
其中特别是 reagent 这个库, 很中意, 封装得非常漂亮
https://github.com/reagent-project/reagent
还有文章专门做对比, 结果是 reagent 更好用, om 当然也有好处
http://diogo149.github.io/2014/10/19/om-no/
http://theatticlight.net/posts/Om-and-Reagent/

reagent 的语法继承子 hiccup, 后者是 Clojure 后端的模板引擎
https://github.com/weavejester/hiccup
确实比起 JSX 来说, 这个语法好看多了
加上 Lisp 系本来就一切皆是表达式, 风格其实非常漂亮
Om 用的是另一套语法, 但据说不如这个写法容易操作

ClojureScript 中不可变数据类型处理得更好, 因而性能存在优势
大概就是相当于 React.js 加上 Immutable.js 的优化, 他们默认就做了
Om 似乎是用的 global single state, 但是 reagent 很像 React.js
reagent 用了 atom 类型, 实际上允许了局部变量
看下官方的介绍大概就懂了, 就算不会 Lisp http://reagent-project.github.io/

关于 figwheel 环境

实际上我是看了这篇文章, 照着运行了一遍, 然后灵光一现的
http://yogthos.net/posts/2015-11-12-ClojureScript-Eval.html
https://gist.github.com/jiyinyiyong/54a2a4a223c47953c0f6
这篇文章真的是很好的一个例子, 从配置环境到运行代码

原本我被 lein 搞得晕头转向的, 渐渐一些概念终于连到一起了
首先, Clojure 是用 jar 包跑的, 并不方便, 依赖管理也比 Node 麻烦
于是有了 lein, 也就是 Leiningen, 实际上对应了 npm + gulp 的功能
lein 上边有各种插件, 比如 lein-cljsbuild 就是编译 ClojureScript 用的
还有 lein-figwheel, 这个插件加上以后, 几乎有 Webpack 的功能了

ClojureScript 编译本来用的是模块带的 API 做的
https://github.com/clojure/clojurescript/wiki/Quick-Start
lein-cljsbuild 把 API 封装成了插件, 在 lein 当中配置和调用
https://github.com/emezeske/lein-cljsbuild/
另外 lein-figwheel 基于 cljsbuild 再加上了一些配置
https://github.com/bhauman/lein-figwheel/wiki/Quick-Start
整个配置完成, 已经到 babel-plugin-react-transform 的程度了
也就是: 打包代码, 局部替换代码, 显示编译报错, 等等

figwheel 和 Webpack 的异同

整个看下来其实挺惊奇的, 相似点太多了, 特别是热替换部分
而且我前面的博客才介绍了 Webpack 做 Node.js 热替换
我发现 figwheel 也能, 从配置过程看相似点还不少:
https://github.com/bhauman/lein-figwheel/wiki/Node.js-development-with-figwheel
总之两个工具都是对 JavaScript 做了步骤繁多的编译

ClojureScript 的不同大概是, 由于数据类型不同, 代码完全不一样
ClojureScript 编译结果, 不用 Source Map 基本上就用不上了
基于这个区别, 我怀疑值的更新策略也和 JavaScript 这边不同
毕竟 figwheel 没有引入 module.hot.accept API 就把热替换做掉了

其他

今天还扒到了 Reactive2015 大会的视频, 在 Youtube 上, 吐槽过, 没剪辑
其中 FRP 相关的分享内容越来越多, 可以看一下节目单
https://reactive2015.com/schedule_speakers.html#
特别是有个估计是华裔的妹子在大谈 ClojureScript 大谈 PureScript
对比一下国内才多少人在跟进这个领域, 几个 QQ 群一共多少人, 凌乱了

以及这个 React vs Angular 2 的文档, 可以看到 FP 影响多大
https://docs.google.com/document/d/1Ah9IJ72DhV4AzoZ1TJUnMzj42PzQrLrwQUkg9koO0dg/
现在的 React 已经各种引入 FP, 包括 Angular 2 也引入 fRP(响应式编程)
为了不远的时间, 这个 JavaScript 社区被搅得一地鸡毛不是没有可能
而且不久前的 LLVM 大会上 WebAssembly 团队汇报了一下进度
https://www.youtube.com/watch?v=5W7NkofUtAw
理性得说, JavaScript 的流行度被瞬间逆转的可能是存在的, 各种语言虎视眈眈

好了经过近期的折腾, 用 Clojure 代替 JavaScript 写个人项目的障碍基本扫了
可以开始说 JavaScript 坏话了... 我反正对 C 风格的语法一直很反感
Babel 最近的状态也让我很不看好, Flow 和 TypeScript 我倒说不准
其实 Clojure 也很难学, 不见得舒服, 但为了某些目的我还是坚持
JavaScript 也一样, 那么多人学, 因为拿浏览器没办法, 如果有办法了呢?

 类似资料: