Scalajs-react VS Xored Scalajs-react VS 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 是可选的，所以我猜默认情况下 Scalaz 和 Monocle 被排除在外？我个人认为这个库可能只是 React.js 代码的一个非常简单的外观，它可以更容易地更新到新版本的 React.js，它不是一个简单的外观意味着将生成更多的 Javascript 代码等等浏览器必须下载的代码。我可能在这里错了，请纠正我？
3. SRI - 新人，外观看起来非常完整，支持 Web、Relay 和 React native，但不支持 URL Router 和 DOM DSL。外观 API 看起来非常精简，与编写 Javascript React.js 代码非常相似。但它是相当新的，可能还没有准备好生产？

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

Answer 1

截至 2015 年 10 月：

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

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

Answer 2

我是 scalajs-react 的作者，所以我的 cmets 对其他两个库的了解会少得多，希望不会错，但我们开始吧。

• scalajs-react - 目标是提供最佳的 Scala 体验和类型安全。附带许多 Scala 好东西、性能实用程序、对 FP 的支持、镜头等（都是可选的。）焦点是 Web 的 React。

• xored - 在我看来，目标是尽可能接近 Scala 中的 JSX。

• Sri - 在我看来，目标是覆盖 JS 最多的领域（甚至是 Relay）并尽可能接近 JS。

当然还有其他细节，（评论上面提到的 scalajs-react 使用 React.createClass 而不是扩展 React.Component 但这是一个微不足道的实现细节，可以在 10 分钟内更改而不会破坏 Scala 向后兼容性 -我不会担心），但我认为项目级理念应该是您的决定因素，而不是细节。如果你想不费吹灰之力地接近JS，就用Sri；如果您希望类型安全和 Scala 体验成为优先事项，请使用 scalajs-react。

另外，scalajs-react 会将其核心模块拆分为 core 和 dom 以匹配 React。除非社区中的某个人实现了它，否则我不会屏住呼吸添加本机模块。另一方面，Sri 已经做了网络和原生，我知道@chandu（Sri 的作者之一）长期以来一直在玩原生，所以它应该在 Sri 的整个生命周期中得到很多支持和改进。

我个人觉得这个库可能只是 React.js 代码的一个非常简单的外观，它可以更容易地更新到新版本的 React.js

是的，但简单的外观不是我想要的。我想要一个外观，我可以相信我的代码将永远有效 - 许多事情都会让 React 出错，随着时间的推移，所有这些精细规则和运行时问题都会嵌入到外观类型中，以便scalac 可以提防我们。

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

不是一个简单的外观意味着将生成更多的 Javascript 代码，并且浏览器必须下载更多的代码。

是的，没错，但我们在这里可能只谈论几 KB。使用 Scala.JS 会增加 150KB+，它的优化器非常擅长排除你不使用的代码。

希望对您有所帮助！选择是件好事。

Answer 3

使用 Sri，您可以开发 Web 和移动应用程序，因为 scalajs-react/Xored Scalajs-react 以 Web 为中心。我从未使用过 Xored Scalajs-react，所以无法对此发表评论。现在问题是 Sri-web 与 scalajs -反应

Sri-web 与 Scalajs-React

对于任何 scala react web 应用程序，我们需要 3 个核心原则 1) 定义 React 组件/元素的方式 2) 一些内置组件/基元/构建块 3) 路由器

1) 定义 React 组件/元素：

Scalajs-react 具有精心设计的 API ReactComponentB，但它基于旧的 React.createClass，Sri 具有基于新的 React ES6 类 React.Component 的 ElementFactory。 In general React.Component is faster than React.createClass，从 react 0.14 开始，我更喜欢使用 React.Component 而不是 React.createClass，除非你非常需要 mixin。话虽如此，我们 discussing 正在将 ReactComponentB 和 ElementFactory 结合在一个共同的项目中。

2) 基本构建块/基元：

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

3) 路由器：

Scalajs-react 有基于 url 的路由器。 Sri 有 UniversalRouter，它可以在移动和网络上运行，但它不支持 url，以及基于 URL 的 WebRouter。

Ofc scalajs-react 有许多其他助手和很酷的 FP 东西。如果有人不同意我的观点，请随时开始讨论，我很高兴知道新事物 :)

最后希望我们很快就会有一个共同的核心项目 (1)，以便用户可以根据自己的口味选择/切换渲染器，最终 scala.js 应该会赢:)

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

Edit2：更新了路由器部分，因为 sri 0.4.0 有一个基于 url 的 webrouter。

Edit3：更新了构建块部分，因为 sri 0.6.0 现在具有 dom dsl。