2 ms·
Yes, it is an issue, but not for the reasons you think. For example, take these two APIs: // returns null if post doesn't exist async function loadPost
by Nullabillity 3y ago
Yes, it is an issue, but not for the reasons you think. For example, take these two APIs:
// returns null if post doesn't exist
async function loadPost(id: string): Promise<Post | null>;
interface ResourceState<T> {
// null if no data has been loaded yet
data: T | null;
}
function createResource<T>(load: Promise<T>): Observable<ResourceState<T>>;
Both are largely designed to fit together (`createResource(loadPost(id))`), but if you do then you now have no idea whether `data` is null because the post couldn't be found, or because it's still being loaded. You would either have to use different nulls (null vs undefined) or have `ResourceState` box T somehow.
§um types are safe from this because they can distinguish between `None` and `Some(None)`.
- rtpg 3y agoRight, I agree with that. I think in practice this is largely circumvented by ad-hocing tagged unions in these cases. Higher level, I think that it's fairly rare to see Optionals outside of the _very_ basic cases, and downstream of that you're actually not flinging around nulls or undefined as data. Instead everyone reaches for a kind attribute. Especially in cases like you're talking about (where there's this notion of not finding something, but also this notion of something still loading). Not to say the distinction doesn't matter, but TS feels well designed in the sense that all of its unsafety is in places that end up not coming up in many "normal" codebases