Maybe types

[gustavopch]

In many cases, the distinction between null and undefined is not important and the code ends up with lots of | null | undefined, so I propose that ?string be expanded to string | null | undefined as supported by Flow: https://flow.org/en/docs/types/maybe/.

Together with #126, we'll be able to write something like:

Component := ({
  foo: ?string
  bar?: ?number[]
}) =>
  // ...

Instead of:

const Component = ({
  foo,
  bar,
}: {
  foo: string | null | undefined
  bar?: number[] | null | undefined
}) => {
  // ...
}

[STRd6]

Thanks for the suggestion, this is definitely something I've felt the need for myself.

Reading the Flow docs it looks like it should also make parameters optional to be completely compatible with Flow semantics.

(x: ?number) ->
---
function (x?: number | null | undefined) {}

[gustavopch]

Isn't it the opposite? 🤔

In the case of objects, a missing property is not the same thing as an explicitly undefined property.

If you want to allow missing properties, use optional property syntax, where the ? is placed before the colon. It is also possible to combine both syntaxes for an optional maybe type, for example { value?: ?number }.

So, to make it optional, you have an extra ? before the colon as in { value?: ?number }.

---

I think it's reasonable because while the distinction between null and undefined is usually not important, sometimes you actually want the property to be explicitly set to ensure intentionality. In those cases, you'd have to go back to | null | undefined. Better have one extra character to opt in to optionality than the whole | null | undefined to opt out.

[edemaine]

I can confirm lots of instances of name?: ?type in a Flow codebase. 🙂 Example

[STRd6]

I think it behaves differently in function parameters than in object properties. Reading the Flow docs further you I see that you're correct about the object property behavior.

So a more complete simple example:

type T = {
  x: ?number
}
(x: ?number) ->
---
type T = {
  x: number | null | undefined
}
function (x?: number | null | undefined) {}

If we take the feature and use the same Flow syntax then I feel we should keep the Flow semantics the same as well.

[gustavopch]

Oh, you're right, just tested here and it behaves differently in function parameters. I don't have a strong opinion on this.

[edemaine]

We've been discussing this more on Discord. There are at least two decisions to make:

• ?T (as in Flow) vs. T? (more like Civet's x? operator)
• | undefined | null (as in Flow) or | undefined (as in TS's x?: T) or | null

We could imagine compiler flags to control which null values get OR'd. Or ? before or after the type could even control the meaning. Unfortunately we can't make one choice that's both consistent with TS's optionals and Civet's runtime x? check.

[edemaine]

We decided (at least for now) to go for T? meaning T | undefined, to match TS optional types. T?? is offered as T | undefined | null, like Flow's ?T. ?T doesn't (yet) have a meaning.