Scalajs-react与Xored Scalajs-react与SRI的比较

Question

这些 Scala.js 和 React.js 库有什么区别？我应该选择其中一个吗？

1. Xored Scalajs-react - 最后一次提交是8个月前，所以开发可能已经不再活跃。
2. Scalajs-react - 非常活跃和完整，并带有自定义URL路由。但API似乎偏离了实际的JavaScript React代码编写方式，而且没有支持React-native，加入了Scalaz和Monocle会增加库的大小，增加浏览器需要下载的JavaScript代码。文档称Scalaz和Monocle是可选的，所以默认情况下它们被排除了？我个人认为这个库只需要是React.js代码的一个非常简单的外观，这样就更容易更新到新版本的React.js，而它不是一个简单的外观意味着将生成更多的JavaScript代码，浏览器需要下载更多的代码。我可能错了，请纠正我？
3. SRI - 新手，外观看起来非常完整，支持Web、Relay和React Native，但没有URL路由支持和DOM DSL。外观API看起来非常简洁，非常类似于编写JavaScript React.js代码。但它相当新，可能还不适合生产环境？

请纠正我，如果我错了，因为有太多的选择，希望有一种方法可以在Scala.js中编写React.js代码。

- user794783

---

有一个xored项目的分支显示了一些开发活动 kanterov/scala-js-react。 - MxFr

Answer 1

截至2015年10月：

• 我也得出结论，xored/scala-js-react 当前并未积极开发。用于模板的方法是保持类JSX的XML语法，我在某些方面确实喜欢这种方法，特别是因为它使代码看起来更像普通的React。更新：@MxFr 指出有一个稍微活跃一点的fork
• 毫无疑问，japgolly/scalajs-react 正在积极开发中。支持React 0.14即将到来。该方法使用自定义版本的lihaoyi/scalatags进行模板化，而不是使用XML语法。这样做的缺点是一开始让代码看起来有点奇怪，但你会习惯它，并且它提供了良好的类型安全性。
• chandu0101/sri 是一个新的解决方案，希望成为更具跨平台性（Web、Android、iOS）的解决方案。有一些讨论关于使 chandu0101/sri 使用 japgolly/scalajs-react，并且sri的作者似乎对基于那次交谈而这么做特别感兴趣。

基于以上，目前最有吸引力的解决方案是japgolly/scalajs-react，请记住这个领域变化很快。

- ebruchez

Answer 2

我是scalajs-react的作者，关于其他两个库的评论将会少得多，希望不会有误，但是我们来看看。

• scalajs-react - 目标是提供最好的Scala体验和类型安全。具备许多Scala好处、性能实用工具、FP支持、镜头等（全部可选）。重点是Web上的React。

• xored - 目标对我来说是尽可能接近JSX在Scala中的使用。

• Sri - 目标对我来说似乎涵盖了大部分JS领域（甚至Relay），并且尽可能接近JS。

当然还有其他细节，（上面的评论提到了scalajs-react使用React.createClass而不是扩展React.Component，但这是一个微不足道的实现细节，可以在10分钟内更改而不会破坏Scala向后兼容性-我不会担心那个），但我相信项目层面的哲学应该是你决定因素。如果您想要尽可能接近JS而无需费心，则使用Sri；如果您想要类型安全性和Scala体验优先，则使用scalajs-react。

此外，scalajs-react将将其核心模块分成核心和dom以匹配React。我不会指望添加本机模块，除非社区中的某个人让它发生。另一方面，Sri已经支持Web和本机，我知道@chandu（Sri作者之一）一直在玩弄本机，因此它应该在Sri的生命周期内获得大量支持和改进。

我个人认为，这个库只是一个非常简单的React.js代码外观，这样更新到更新版本的React.js会更容易

是的，但一个简单的外观并不是我想要的。我想要一个可以信任我的代码始终工作的外观 - 许多事情可能会使React出现问题，随着时间的推移，所有这些细节规则和运行时问题都会嵌入到外观类型中，以便scalac可以为我们提供支持。

< p >< em >（此外，跳过升级到React 0.13的决定并不是因为难度。scalajs-react在发布后几天内就获得了对React 0.14的支持（当前在scalajs-react v0.10-RC1上）。

< blockquote > < p >不仅仅是简单的外观，这意味着将生成更多的Javascript代码以及浏览器需要下载更多的代码。

是的，这是正确的，但我们可能只说几KB的大小。使用Scala.JS至少增加了150KB+，而且它的优化器非常擅长排除您不使用的代码。

希望这有所帮助！选择是一件好事。

- Golly

Answer 3

使用Sri，您可以开发Web和移动应用程序，而scalajs-react/Xored Scalajs-react则专注于Web。我从未使用过Xored Scalajs-react，因此无法对此进行评论。现在的问题是Sri-web与scalajs-react。

Sri-web vs Scalajs-React

对于任何Scala React Web应用程序，我们需要三个核心原则：1）定义React组件/元素的方式；2）一些内置组件/基本构建块；3）一个路由器。

1）定义React组件/元素：

Scalajs-react具有设计良好的API ReactComponentB，但它基于旧版本的React.createClass，而Sri则基于新的React ES6类React.Component的ElementFactory。总的来说，在React 0.14中，React.Component比React.createClass更快，除非您非常需要mixin。也就是说，我们正在讨论将ReactComponentB和ElementFactory结合在共同的项目中。

2）基本构建块/基元：

Scalajs-react带有dom-dsl（您可以选择整个dom元素/属性）。Sri也带有dom dsl和react-native-web组件。

3）路由器：

Scalajs-react具有基于URL的路由器。Sri具有UniversalRouter，可以在移动设备和Web上同时使用，但它不支持URL，并且有一个基于URL的WebRouter。

当然，scalajs-react还有许多其他辅助程序和酷炫的FP东西。如果有人不同意我的观点，请随时开始讨论，我很乐意了解新事物：）

最后希望我们很快会有一个共同的核心项目（1），这样用户就可以根据自己的口味选择/切换渲染器，在这一天结束时，scala.js应该胜出：）

编辑: 顺便说一下，我是Sri的作者 :)

编辑2: 更新了路由器部分，因为Sri 0.4.0有基于URL的Web路由器。

编辑3: 更新了构建块部分，因为Sri 0.6.0现在具有DOM DSL。

- invariant

---

只是一个小细节：在SO上，通常要披露与相关项目的关联。因此最好提到您是Sri的作者（特别是因为这一点并不明显从您的SO名称中）。 - gzm0