1

请考虑使用纯 JavaScript CommonJS 模块实现的原生依赖项的 Scala.js 库。

该库包含 JavaScript 依赖项的外观。正如预期的那样，外观包含很多代码，例如：

@JSImport("com", "Foo") @js.native
class Foo extends js.Object { ... }

不幸的是，ScalaJS-Bundler 以一种将 Foo 隐藏在全局范围内的方式捆绑了它。显而易见的修复涉及将 @JSExport 注释添加到其他两个，但这会导致编译器错误。

为什么 js.native 与 JSExport 不兼容？在外观上添加对@JSExport 的支持需要什么？

现在有什么变通办法吗？

4

1 回答 1

3

@JSExport在 Scala.js 0.6.15中不推荐使用顶级类和对象。你所追求的其实是@JSExportTopLevel。

没有与/@JSExportTopLevel不兼容的根本原因。这不是因为以下 3 件事：@JSImport@JSGlobal

  • 支持它意味着在整个编译器工具链中需要做更多的工作来支持它，
  • 这感觉像是一个罕见的用例，并且
  • 还有另一种方法可以达到相同的结果。

实现结果的另一种方法是简单地导出一个val存储导入结果的方法，如下：

@js.native
@JSImport("com", "Foo")
class Foo extends js.Object { ... }

// 'private' not to pollute the Scala API with this object
private object Reexports {
  @JSExportTopLevel("Foo") // or another name
  val Foo = js.constructorOf[Foo]
}

如果您只重新导出一个这样的导入，它肯定会更加冗长，但您可以在唯一的object Reexports.

于 2018-06-05T09:32:21.043 回答