我们真的需要 Figwheel 吗？

Question

在我的上一份工作中，我用 Clojure 开发后端，用 ClojureScript 开发前端。日常工作中，我感到最大的区别是重新加载的方式：在 Clojure 这边，我常常一个接一个地向 REPL 发送表单，有时会使用 Integrant 重新启动整个系统。在 ClojureScript 这边，我主要编辑文件并保存，然后 Figwheel 会重新加载一切并刷新视图。

最近，我探索了现有的不同 pREPL，偶然发现了各种 ClojureScript pREPL，并尝试了一个裸骨 ClojureScript 设置，它与 Clojure 的工作流程完全一样，运行也很顺利。所以看起来 ClojureScript 支持与 Clojure 相同的开发方法。

那么，在不使用 Figwheel 的情况下，使用裸骨 ClojureScript，并从 REPL 刷新渲染的 UI 是否可行，类似于在 Clojure 一侧使用 Integrant 所做的那样？如果是这样，为什么 Figwheel 在前端似乎如此普遍呢？

Answer 1

我通常只在处理 UI 布局时才使用 Figwheel。我认为这正是 Figwheel 发挥最大作用的地方，大大减少了代码审查-代码审查的周期，尤其是对于布局调整。

对于库代码或业务逻辑代码，我通常更喜欢进行传统的 REPL 开发（如果是在 Figwheel 项目中，我会停止 Figwheel 的自动构建）。在这些情况下，我感兴趣的可能是改变或添加可能不会立即在 UI 中产生视觉影响的功能行为，因此热重载在那里并不那么有帮助。