Méthode standard avec pour `@JSExportTopLevel` lors de l'exportation sous un espace de nom dans `scala-js 1.x.x`.

Question

J'ai deux classes avec le même nom A ayant un paquet différent un comme : -

xxx.yyy.v1.A

et le second comme:-

xxx.yyy.v2.A

Je dois utiliser @JSExportTopLevel dans scala-js (1.1.1).

Quelle est la méthode standard pour y parvenir ?

Auparavant, dans scala-js (0.6.x), j'utilisais quelque chose comme ceci : -

@JSExportTopLevel("xxx.yyy.v1.A")

et

@JSExporttopLevel("xxx.yyy.v2.A")

mais avec scala-js (1.1.1 ), il est maintenant supprimé. Exportation sous un espace de nom (déprécié)

Note : - Je suis confronté à ce problème lors de la mise à jour de scala-js. 0.6.x -> 1.x.x

Ma configuration : -

scala -> 2.13.3, jvm -> 14, sbt -> 1.3.13, scala-js -> 1.x.x

Answer 1

L'exportation sous un espace de nom était déprécié dans Scala.js 0.6.26 et finalement supprimée dans la version 1.x parce que ces exportations ne correspondent à rien en termes de module ECMAScript export s. Le compilateur a dû sauter à travers des cerceaux non standard pour qu'ils semblent fonctionner.

Comme l'expliquent les notes de publication de la version 0.6.26, dont le lien figure ci-dessus, la solution de remplacement consiste à construire explicitement un objet JS qui contiendra ces espaces de noms et les valeurs à exporter. Dans votre cas :

object JSNamespacesExports {
  @JSExportTopLevel("xxx")
  val xxx = new js.Object {
    val yyy = new js.Object {
      val v1 = new js.Object {
        val A = _root_.xxx.yyy.v1.A
      }

      val v2 = new js.Object {
        val A = _root_.xxx.yyy.v2.A
      }
    }
  }
}

( _root_. est utilisé pour forcer la résolution xxx en tant que paquetage Scala de premier niveau, au lieu du paquetage val xxx qui est dans le champ d'application).

Avec cet encodage, vous choisissez explicitement la façon dont vous voulez xxx pour apparaître, comme vu de JavaScript. C'est plus transparent que l'implémentation opaque et à moitié conçue que Scala.js 0.6.x utilisait.