Your readme would really benefit from code snippets illustrating the library. The context it currently contains is valuable but it’s more what I’d expect at the bottom of the readme as something more like historical context for why you wrote it.
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.