https://en.m.wikipedia.org/wiki/Option_type
If you are using TypeScript (TFA mentions it), fp-ts provides a good functional programming layer. Although if you aren't already familiar with functional programming it's going to be hard as the documentation is rather lacking.
If the FP community wants to say that impure languages have been "doing FP" for decades then great! The religious war is over! We can happily have mixed paradigm languages and move on. But that's not what I'm seeing.
I would go even further that even if the semantics are a little clunky (wrap/unwrap) any programming language can implement Option.
As an aside, TypeScript is very unsafe by default, and still relatively unsafe with strict mode enabled. Stringent fp-ts usage bypasses these issues.
Is it? I have been using Typescript more and more these last few years, and lately haven't really experienced any issues where it's type system failed me.
To clarify, I'm not trying to argue against your point, genuinely curious to learn if fp-ts can really improve my code quality in production.
Beyond that there's functions that throw/reject doing so outside the type system, something solved by Either/Option/similar types in fp-ts.
The biggest benefit of fp-ts though is that it makes you think functionally. If you're dead set against that, then there are plenty of other libraries that give you types/wrappers like these without having to use pipe/flow (two functions you'll want to use before anything else in fp-ts).
Only in Javascript though. In Typescript this would be clear from the fact that the type has the property.
Of course Typescript is not Javascript, but nobody should use plain JS anymore.
When I'm using hooks in React this is very common.
You must give an initial value, and at some point in the future you will update it.
By setting the value as null initially I can easily check whether the variable has been filled or not. This is most important for initially rendering the UI.
> By setting the value as null initially I can easily check whether the variable has been filled or not
I don't think there's anything wrong with this but it does mean your variable can be in two states~, one where "it shows it should be filled" and one where the value is present and can be used.
You can use null for this if you want and most programmers will understand these states. You can also choose to make this even more explicit by creating a type that expresses this.
example in Kotlin but you get the idea (applies to any variable in any language)
sealed class ThatVariableYouCareAbout {
object ShouldBeFilled: ThatVariableYouCareAbout()
data class HasBeenFilled(val x: String): ThatVariableYouCareAbout()
}
// usage
fun test(thatVar: ThatVariableYouCareAbout) {
if(thatVar is ShouldBeFilled) {
//
} else if(thatVar is HasBeenFilled) {
}
}
All that being said, null is generally understood to have this meaning~ and I have/do use it but with an understanding that it's of lazyness/not wanting to be overly verbose (language consideration).
The case you are describing is very familiar to me (rendering UI with initial states through a framework like react) and having an explicit type for the initial state is the ideal, or at least the most explicit, solution.
Option works for 2-state variables like this
It would be better to just error out and not allow the uninitialized usage at all, but unfortunately that's not possible in Javascript.
For instance, if I'm fetching some data I usually want to initialize the data variable as null for a couple of reasons.
1) null is not truthy, empty arrays and objects are
2) It shows that the variable is supposed to be filled, unlike undefined