Research a better story on optional values

[oyvindberg]

ScalablyTyped/Runtime#1

[oyvindberg]

test notifications

[aappddeevv]

I'll suggest do not try to use a fixed converter runtime, which I think, you may want to minimize the dependency on. You could generate optional types using pure scala.js. I did this and its working great as it can be. Plus you can target extension methods to it. So undefined goes to js.UndefOr and "could be null" becomes to Blah | Null. Both become js.UndefOr[Blah|Null]. You can even monadize the |Null for greater joy. (Alright, no joy, but at least it works better and is more consistent). https://github.com/aappddeevv/scalajs-reaction/blob/master/jshelpers/src/main/scala/null.scala

The other thing you can do is make this configurable. I had to do that for the graphql code generator. So there would be a "strategy" for optional that cover "null,undefined,both" as well as a strategy for naming (per the other issue). It's not as bad as I thought it would be and it helps fit into peoples target js model. You don't want too much optionality because it becomes too abstract but this is a big area.

[oyvindberg]

FTR this is what I was experimenting with.
ScalablyTyped/Runtime#1

Blah | Null is bad because there is nowhere to hang the implicits, so they need to be imported at every use site. Also OOTB you cant use it for anything without casting.

The thing I'm a bit wary about is introducing something like this since dotty brings proper union types and nullability checks.

Actually what I have thought about is to be pragmatic (tm) and replace | Null with a comment. It'll sacrifice some type safety for convenience of course.

[aappddeevv]

I suggest you just make it pluggable since its such a big decision. There are only a few strategies so its not an infinite universe of possibilities.

I use Blah|Null (which should really be Null|Blah) extensively and it works great because for input values, scala.js already allows you to assign a Blah or a null without casting, and on outputs from an API you can write your own extension method in your own code for use if you want when you want to. You don't need to anything inside the converter or in converter generated code. You also do not need to cast, you can write extension methods like I did (its monadic enough so I use everything that Option has) or use built-in monadic goodies already in scala.js 1.0 (https://www.scala-js.org/api/scalajs-library/1.0.1/scala/scalajs/js/$bar.html#merge[B](implicitev:scala.scalajs.js.|.Evidence[A,B]):B) via standard scala.js. I recall that it is consistent with dotty when you turn on the nullability flag, you must have |Null to assign null to a value that has it marked as such--that's one of the reasons I started doing that because I will probably use that dotty flag. This means that Blah|Null is actually consistent scala.

Anyway, most likely a clever command line option could take care of it. One of the options could be the approach in your link above. If one of your objectives is to reduce dependencies on the scalablytyped runtime, then you will want options.

[oyvindberg]

Well yeah, kind of agree. The best argument for the current encoding is that it's pretty future proof.

OTOH ergonomics are bad when something as basic as null basically doesn't work unless you know exactly how Scala.js translates to Javascript and then how to write implicit sugar on top of it. I think that's a pretty good argument for changing it.

It's possible to allow configuration of something like this, but it has severe drawbacks:

• it increases complexity further in the converter itself
• the flavour code generation (which I'm hopeful people will be able to contribute down the line) run on a fully prepared scala AST, so they would have to recognize all forms of optionality
• it multiplies the testing surface
• it makes it almost impossible to write documentation, since you can't write a single example which is copy/pasteable into your own source code

[aappddeevv]

Perhaps it depends on the purpose of generation. I would generate for a particular project and within that project (or program whatever the umbrella is) there are conventions, etc. Within that context, you would have consistency and I would not be concerned about what other people generate at large for their efforts.

I don't know the code but I would guess that any adapter would as part of generating the AST from typescript so it would still be scala AST. Typescript has this an option today on how to treat nulls and undefined so they also have to accommodate nationality. There are also options I have seen in graphql code generators (typescript generation :-)) that address optionality. The test surface would merely need to test whether the optionality mechanism works and all existing tests that may be based on source code textual comparisons could remain the same as today.

I may be thinking about conversion in the small, for projects and teams, versus a "generation" that is "open the public" generated for everyone's benefit.