Inconsistencies

[hickscorp]

From the docs:

I'm trying to make impossible states impossible, and I don't seem to be able to.

• If an unsuccessful result is always null, then what's the point of the successful fields?
• The typings for the validation messages is something like: (ValidiationMessage | null)[] | null. The docs says that it's empty when there are no errors - but it can also be null. Which on is it?
• The validation messages are typed in a way that individual messages can be null. What does that mean?

Generally speaking, why not make the return type impossible to represent something impossible?

• I would enforce that the messages must be either ValidiationMessage[] or ValidiationMessage[] | null. Having individual null messages is just both confusing and adds lots of uncertainty about the meaning of such cases.
• IMO saying that result will always be null when unsuccessful is a mistake. Sometimes a user posting a form can be partially successful. Having a result with partial changes applied and a list of errors models this already. I think there should be no success flag at all - extracting success from a payload should be as easy success = () => messages || message.length == 0 || !result.

In our case, having to handle these cases has shown to be very laborious, and particularly misleading for the frontend team, especially when using more strong typed languages that aim at eliminating runtime errors (Elm, TS, etc). The fact that an impossible state is made possible makes the frontend developer have to address it, regardless of how absurd it is.

Maybe a bit of love on the base Payload concept would be great before too much adoption?