Yup, in my TODO list (I've only recently published this package). For now you can just check the tests, or a SO answer I wrote a while ago (before I published the idea as an npm package): https://stackoverflow.com/a/78937127/544947
function fnO(val?: number) {
if (val == null) {
return "NAH";
} else {
return (val * val).toString();
}
}
test("testing Options", () => {
let foo = undefined;
let bar = 2;
expect(fnO(foo)).toBe("NAH");
expect(fnO(bar)).toBe("4");
});
> FP's languages approach of rather not having null at all
But `None` is just another null / undefined, which brings along a bunch of non-idiomatic code around handling it.
If you do a type check with None, and there is some value inside (so it is Some, not None), it is IMPOSSIBLE that the .value that you extract underneath is gone. This is an important race-condition that you might run into due to the nature of TS/JS, but by boxing the value with an immutable Option type, you're protected.
Also this prevents people to run into NullReferenceException (or UndefinedRefsExceptions, or whatever is called in this ecosystem) for people that didn't turn strictNullChecks ON.