Null handling

[japgolly]

What do we do in cases where a type in facade is nullable? We have js.UndefOr but sadly there's no js.NullOr. In scalajs-react I add | Null to facade types but the problem is it's non-trivial to get rid of the null (outside of Scala 3's experimental explicit-nulls), and I've had to add helpers with casts.

I absolutely hate the idea of just saying AudioTrack and the user having to somehow know that it's nullable. I want more clarity for users: types would be the best, information is probably the fallback (eg. annotations, worse: doc).

What do to? It might be an idea to add something like NullOr to scala-js-dom itself.

[armanbilge]

Yes, I ran into this too when reviewing a PR. The idiom here so far seems to be not to indicate the possibly null type. OTOH, so far this library has essentially been a pure facade and adding opinionated nice-ities is arguably out of scope?

[armanbilge]

Btw, #414 (comment) made me think critically about what the purpose of this library is. I don't mean to open a can-of-worms over null but it is helpful if we clarify the goals/scope of scala-js-dom going forward.

[japgolly]

this library has essentially been a pure facade and adding opinionated nice-ities is arguably out of scope

I agree with that sentence but I don't agree that clarifying nulls in types goes beyond that scope. In the same way the js.UndefOr is a facade over A | undefined (with a few helper methods for nice Scala usage) I think a similar concept over null is just as in scope. It adds precision to the facade types.

Plus I'd also argue that in addition to simply being pure facades, we also provide utilities for convenient Scala usage, and there's already precedent for that. (Check out the [S_] tagged items in the api report.) As an example, one of the most annoying things ever, is getting a NodeList back from a facade, and not being able to iterate over it via typical Scala collections. I think I saw somewhere recently that this is fixed in our pending PR queue? But regardless, I'd argue we've got to go beyond providing the most minimal use. I think we should hard-limit our scope to JS DOM and browser API, but within that scope I think we should make it as nicely usable as possible, and as safe/precise as possible.

[japgolly]

Re #414, yeah I don't know about generating this code from TS. Seems like a great idea if everything's up-to-date, and we have a means of overriding certain generated decisions. It's interesting but I'd also say it's orthogonal to the goals/purpose of this project. Like regardless of whether we hand-write or generate the code in this repo, we still need to make decisions about how to make the facades as precise as possible, and ensure they have good-enough dev ergonomics, so I'm happy to separate the decisions.

[armanbilge]

I think we should make it as nicely usable as possible, and as safe/precise as possible.

So, why not return Option for example? I guess I'm confused where the line is drawn.

[japgolly]

Option is a Scala type, we need a type that behaves like Option but represents X | Null at runtime in JS world. Option is None | Some

[japgolly]

Plus different subtle semantics too, like you can't represent Some(None) as X | Null because it would be reinterpreted as just None.

[armanbilge]

Plus different subtle semantics too, like you can't represent Some(None) as X | Null because it would be reinterpreted as just None.

Right, but as long as we rule out nested Options I don't think that should crop up :)

I guess the question I'm asking is, what's the difference between having a facade that uses X | Null but then has an implicit conversion to/from Option for convenience sake, versus defining the interfaces in terms of Option to begin with and implementing them via a raw facade hidden from users.

[japgolly]

Option isn't a JS type. It's a sum type of two Scala classes None and Some. From a JS pov, having two Scala classes is not the same as having a nullable JS type. Eg. None != null and Some(1) != 1. Theory aside you basically can't use Scala types in facades as a blanket rule.

We could have an implicit conversion from A | Null to Option but I don't think an implicit conversion is a good idea. It's non-obvious, users have to Just Know that they can call option methods on a non-option, plus they're require a special import (which I'd like to avoid as much as possible).

The reason I'm wondering about NullOr is that it wouldn't require any imports, it's mandatory and explicit, and it would be identical to js.UndefOr which is a pattern that's in place already everywhere.

[armanbilge]

Apologies, perhaps I'm misunderstanding, but js.UndefOr[A] is just a type alias for A | Unit, so then wouldn't be your proposed NullOr[A] just be A | Null with all its caveats?

[armanbilge]

Theory aside you basically can't use Scala types in facades as a blanket rule.

Right, of course it doesn't go on the facade itself :) absolutely not! But in theory this library could provide a higher level interface with Options rather than a raw facade.

[japgolly]

I haven't thought deeply about the solution, I'm just clarifying the problem and the limitations here :) But yeah if we end up with just a type alias over X | Null then I want to ensure that whatever's been done to make js.UndefOr function as more than just a type alias, get's done for NullOr too.

[armanbilge]

that whatever's been done to make js.UndefOr function as more than just a type alias, get's done for NullOr too.

See my comment above about implicit conversions ;)

[armanbilge]

Although you make it good point, it's an implicit conversion to add syntax rather than an implicit conversion to another type. Important distinction, my bad!

[japgolly]

But in theory this library could provide a higher level interface with Options rather than a raw facade.

That's a nightmare! As an example scalajs-react is mostly that, the facades aren't as safe and nice to use as typical Scala stuff, so here's a better layer on top of that, and it's the most time-consuming library to maintain that I have. Maybe I'm misunderstanding you but if you're suggesting having double the types with one always performing minor conversions to the other, I don't think that's the way to go.