jshelpers/jshelpers.syntax/jsnull

jsnull

object jsnull
class Object
trait Matchable
class Any

Type members

Classlikes

object OrNull

Extensions

Extensions

extension [A](a: A | Null)
@targetName("getOrElseOrNull2")
def ??[B >: A](default: => B): B

getOrElse but less typing.

getOrElse but less typing.

@targetName("nullAbsorbNull")
def absorbNull: A

Absorb the null and change A|Null => A. Value could still be null, which is valid in scala, but it will no longer by typed that way.

Absorb the null and change A|Null => A. Value could still be null, which is valid in scala, but it will no longer by typed that way.

def collect[B](pf: PartialFunction[A, B]): B | Null

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def contains[A1 >: A](elem: A1): Boolean

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def exists(p: A => Boolean): Boolean

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def filter(p: A => Boolean): A | Null

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

@targetName("filterTruthOrNull")
def filterTruthy: A | Null

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def flatMap[B](f: A => B | Null): B | Null

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def flatten[B](implicit ev: A <:< B | Null): B | Null

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def fold[B](ifNull: => B)(f: A => B): B

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def forall(p: A => Boolean): Boolean

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def foreach[U](f: A => U): Unit

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

@targetName("nullGetOrElse")
def getOrElse[B >: A](default: => B): B

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def isDefined: Boolean

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def isEmpty: Boolean

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def isNotDefined: Boolean

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def iterator: Iterator[A]

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def knownSize: Int

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def map[B](f: A => B): B | Null

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def merge: A

Collapse A|Null => A but the value may be null! You are on your own. Should be called unsafeMerge.

Collapse A|Null => A but the value may be null! You are on your own. Should be called unsafeMerge.

@targetName("nullGet")
def nullGet: A

Get the value or throw if its null.

Get the value or throw if its null.

def orElse[B >: A](other: B | Null): B | Null

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def orElse[B >: A](alternative: => B | Null): B | Null

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def orNull[A1 >: A]: A1

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def toList: List[A]

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def toOption: Option[A]

Like .toNonNullOption.

Like .toNonNullOption.

@targetName("toTruthyOrNull")
def toTruthy: Boolean

If Null, then false, else true.

If Null, then false, else true.

def toTruthyOption: Option[A]

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def toTruthyUndefOr: UndefOr[A]

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def toUndefOr: UndefOr[A]

null => undefined, otherwise A.

null => undefined, otherwise A.

@targetName("nullToUndefOrNull")
def toUndefOrNull: UndefOr[A | Null]

Uh-oh, thought it was A|Null but you need to say its a js.UndefOr[A|Null] because the docs were wrong :-).

Uh-oh, thought it was A|Null but you need to say its a js.UndefOr[A|Null] because the docs were wrong :-).

def unzip[A1, A2](implicit asPair: A <:< (A1, A2)): (A1 | Null, A2 | Null)

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def withFilter(p: A => Boolean): WithFilter[A]

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

def zip[A1 >: A, B](that: B | Null): (A1, B) | Null

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

It is common in interop code to model a value as A or null but not undefined even though null and undefined may both mean "absent value." See |.merge Many of these methods are already on js.| but they appear to be left biased as near as I can tell. I'm happy to delete these methods if that's not correct.

Note that chaining many js.| together probably not work like you think and sometimes its better to create a new target type then target implicits to convert from each individual type (in the or) to the new target type. You must model your type as A|Null for this implicit to be picked up.

These methods exist to try and stop a conversion to UndefOr or Option as part of null processing. Hey! Every bit counts!

Todo

Perhaps the force get methods should throw since .orNull exists in the scalajs standard library now.

extension (a: String | Null)
def orEmpty: String

Return string's "zero" which is an empty string. Could be called orBlank.

Return string's "zero" which is an empty string. Could be called orBlank.

extension [A](a: UndefOr[A] | Null)
@targetName("nullSwap")
def swap: UndefOr[A | Null]

Swap js.UndefOr[A|Null] for js.UndefOr[A]|Null.

Swap js.UndefOr[A|Null] for js.UndefOr[A]|Null.