A nullable type

[samhh]

Some context: https://github.com/unsplash/intlc/issues/102#issuecomment-1089919665

[samhh]

Copied from the linked issue:

---

That's interesting. I suppose it'd be analagous to other. Where other widens e.g. 'a' | 'b' to string (encoded conveniently via a union), null could widen/unionise to null. Not just in select, but also plural.

Ideally though a syntactic construct for null could apply to any type, otherwise we can't handle cases like Date | null. I think that's where the complexity I'd previously considered comes into play, it incorporates a sort of polymorphism (A | null).

If we say hypothetically the implementation would be doable, how about this?:

now being reviewed {topicTitle, nullable, null {by the community} other {in the {topicTitle}}}

# compiles `topicTitle` to `string | null`

Or a motivating example for the broader nullable type:

You joined {joined, nullable, null {a while ago} other {on {joined, date, long}}}

# compiles `date` to `Date | null`

[samhh]

How could we prevent the following without introducing our own typechecking?:

{x} {x, nullable, null {} other {{x}}}

In the above design x is probably string | null however that makes the first interpolation unsafe.

[OliverJAsh]

@samhh In theory this could be caught by running @typescript-eslint/restrict-template-expressions on the output code? We have that rule enabled in unsplash-web but IIRC we don't currently lint the generated TS.

[samhh]

@OliverJAsh I don't think we can leave this for userland. This'd be a type error on output:

{x, number} {x, nullable, null {} other {}}

Where number | null would be fed to Intl.NumberFormat.

[OliverJAsh]

@samhh Perhaps it's OK to have a type error on output? I guess it's a trade-off: defer validation to TS/tsc vs provide validation upfront.

[samhh]

I think the above would actually compile to number via intersection of arguments, making it safe.

string & (string | null) = string