1.0.0-beta20

Fixes a type inference issue for react components with type parameters which are inferred to be Nothing

1.0.0-beta19 - Updated scalajs-react flavour

Full changelog

Finally ported the scalajs-react flavour to use builders as well

This completes the migration from apply methods and brings it in line with the Slinky flavour. This is again a rather big, but hopefully somewhat satisfying rewrite if you used the old version.

Here is a short example of what it looks like

    val js.Tuple2(isModalVisible, updateIsModalVisible) = useState(false)
    
    val renderModal = <.section(
      <.h2("Modal"),
      Button.onClick(_ => Callback(updateIsModalVisible(true)))("Open modal"),
      Modal
        .visible(isModalVisible)
        .title("Basic modal")
        .onCancel(_ => Callback(updateIsModalVisible(false)))
        .onOk(_ => Callback(updateIsModalVisible(false)))(
          <.p("Some contents..."),
          <.p("Some contents..."),
          <.p("Some contents...")
        )
    )

Ported all slinky demos to scalajs-react

See this new demo repo https://github.com/ScalablyTyped/ScalaJsReactDemos .
This opens up a lot of doors, for instance now scalajs-react suddenly has a story for developing react-native apps! :)

Support for react intrinsics (a, div, and so on)

Both slinky and scalajs-react have rather odd DSLs for working with DOM elements. Since all the machinery was in place, we now generate the same react component builders for intrinsics. This means you can use them like this:

import typings.std.global.console
import typings.react.components.{a, div}
div(
  a.href("https://scalablytyped.org")("Click here"),
  div.onClick(e => console.warn("Clicked div"))
)

Try it out! You may find it's much better since it's fully typed, generates optimal javascript (on scala 2.13+, see below), relies much less on implicits and is very ergonomic.

Limited support for Scala 2.12.x

The newest revisions of the builder pattern didn't compile anymore on Scala 2.12 because of a bad interaction between universal traits and this.type. This was solved in #183 by removing extends AnyVal when generating code for 2.12.x, which means that the resulting Javascript will allocate somewhat more when using the react builders. Consider it motivation to upgrade

Other improvements:

• #175 fixes a bug with computing mapped types
• #176 fixes encoding of javascript setters
• #178 adds varargs syntax for the builders for props of type js.Array
• a31be4c fixes ref type detection from props

1.0.0-beta18 - Replace `apply` methods with builders

Full changelog

Version 1.0.0-beta13 introduced builders objects under the flag stExperimentalEnableImplicitOps. This has proved so much better than the old encoding with apply methods that it's the new default. The idea is that you'll have to migrate your code to upgrade further to 1.0.0-beta18, but get it touch if that is a big problem.

Also a few bugfixes:

• CLI didnt write error messages to screen
• react component identification didnt recognize functional components with return type of any

1.0.0-beta17 - Bugfixes

Full changelog

• Bugfixes for using Slinky flavour with minimization and es5 stdlib. If the library you're working with really doesn't need the DOM using es5 might speed up conversion quite a bit
• Tweak for slinky encoding, TagMod[Any] was used for ReactNode in typescript where ReactElement should be used

1.0.0-beta16 - Bugfixes

Full changelog

• Dont rewrite type unions to inheritance when the types will be replaced with external types.
• Don't spam error messages on plugin failure
• Enforce custom package for library plugin a10c5be

1.0.0-beta15 - Now with library development workflow

Full changelog

Source generator plugin for library developers

Documented here

Support dots in stOutputPackage

You can now generate code into for instance org.foo.bar.facade, useful if you want to develop a library where the code is in org.foo.bar.

Plugin: Shade organization in maven coordinates as well when stOutputPackage is changed

This enables use of the converter plugin in more than one project in your build if you really have to

1.0.0-beta14 - Slinky fixes

Full changelog

• A few bugfixes for the new slinky flavour
• plugin now respects -Dsbt.ivy.home PR

Contributors

10  Øyvind Raddum Berg
 1  Andreas Gabor

1.0.0-beta13 - Build all the things!

Full changelog

This release has a lot of goodies, and some breaking changes.

New slinky encoding

Slinky support just went from ok to pretty awesome!

The previous pattern was apply methods with default parameters, which has several issues:

• poor type inference, especially in the presence of union types
• poor editor support, because you see a wall of text with all the parameters
• cannot express more than 254 props. It is surprisingly common for components to accept more than that (including DOM props), and the workaround was pretty awkward

The new pattern is based on (mutable) builders.

• we can generate overloads for complicated types (specifically those which already require an implicit conversion)
• editor tooling is very good
• can express sufficient number of props
• outputs small javascript code

// before
Mui.Button(name = "foo")(onClick := (() => setState(state + 1)))(
  s"Increment it, ${props.name}"
)

// after
Mui.Button.name("foo").onClick(_ => setState(state + 1))(
  s"Increment it, ${props.name}"
)

See the new slinky flavour documentation page

⚠️ This is a breaking change if you use a Slinky flavour. It's a very mechanical and perhaps even somewhat satisfying refactoring, but a lot of typing, unfortunately. See changes for slinky demos

Implicit ops

Using all the same machinery as the Slinky flavour are Implicit Ops added to all types which

1. are/could be be @ScalaJSDefined
2. don't already have a companion object

This gives you a way to very dynamically duplicate, mutate or combine an object with another one.

// before, sometimes you needed to awkwardly guide the compiler 
ColumnProps(title = "Age": ReactElement, dataIndex = "age", key = "age"),

// now, we generate overloads for complicated cases
val c = ColumnProps().setTitleReactElement("Age").setDataIndex("age").setKey("age"),

// translate typescript const d = {...c, key: "foo"}
val d = c.duplicate.setKey("foo")

// translate typescript {...d, foo: "bar" } for a foo not in the original type
val dd = d.duplicate.set("foo", "bar")

// translate typescript const {key, ...rest} = d
val rest = d.duplicate.deleteKey // (delete only for optional members)

// translate typescript {...c, ...d}
val cd = c.combineWith(d)

Note that implicit ops is currently hidden behind a flag, stExperimentalEnableImplicitOps in the sbt plugin. This is because the syntax may still be tweaked slightly or there may be a better encoding.

Scala.js 1.x

• Support for scalajs-react 1.7.0 with Scala.js 1.x support.
• The distribution and all demos are now on Scala.js 1.x.
• Bumped Scala.js to 1.1.0 and scalajs-bundler to 0.18.0
• the Scala.js 0.6.x release of the plugin should be considered deprecated and will be dropped the first time it causes problems

⚠️ If you use scalajs-react make sure to upgrade all related libraries as well.

Restructured library structure

It seems to be a common problem that users are having a hard time orienting themselves in the generated libraries.

The following changes have been done:

• global values (as opposed to value in modules) are moved into typings.<lib>.global.
  There has been many reports of users unknowingly using global values instead of modules because they were easier to find. Now there will be fewer things available at the top-level, and you choose global explicitly by using that package.

• Anonymous interfaces in typescript which we must name in Scala.js are now also moved inside their own package. Typically typings.lib.AnonFoo => typings.lib.anon.Foo. Some other types of names (like PickFooBarPartialBaz) are also moved in there.

See also the new usage documentation page which tries to explain the top-level structure and where to start. The page is short on content, so feedback very welcome.

⚠️ This is a minor breaking change for all users. You should be able to fix most things up with just a bit of search/replace (see related change in demo repository)

Performance

The conversion process is quite a bit faster, the newly added benchmark mode saw more than 20% improvement.
Parsing and compilation is still slow however, so the effect might not be felt that clearly

Facades are gone

In the distribution there was support for "facades" - handwritten libraries on top of the generated typing libraries. These were only used for react, and were superseded by flavours. They are now deleted

1.0.0-beta12 - Stabilize

Full changelog

• Don't create jar after interrupted compile
• Shade circe so we dont clash with other sbt plugins
• Bugfix with useScalaJsDomTypes and older versions of typescript

1.0.0-beta11 - Further improvements of plugin and conversion

Full changelog

• The type substitution mechanism behind useScalaJsDomTypes and the react flavours got an improvement. Hopefully most types (outside of inheritance) will be rewritten now.
• Plugin now picks up configuration of resolvers for downloading the compiler and dependencies
• Bugfix for slinky flavour which caused a lot of libraries to not compile

Contributors

 9  Øyvind Raddum Berg
 1  Roland Reckel