Null query params

[ArcherWheeler]

This is mostly just tests to make sure this works, which it does - sort of. The problem is for the query param types:

This is easy to implement (and works rn)

{ x: ?string }

This is hard to do (and not done)

{ x? : string }

Interestingly the server looking for this type will accept an input url/foo? without the param. However, the safe api client will throw an error. As discussed with @sleexyz irl, due to limitations of $Exact<T> and type splats there isn't an easy way to get the types to correctly merge just for optionals.

22

[ArcherWheeler]

@sleexyz It's a good thing you brought up the testing a spy rather than the response. I didn't realize "" is false-y (🙄 ) so input.x || null was overwriting ""s into nulls. This means that nulls are not correctly preserved. However, both "" and undefined are. I've added a test to show the behavior, which is the default node query string parsing behavior. I talked to @astampoulis irl, and we decided it'd be best to only override this behavior explicitly through typ_rep. That'll come in a later PR.

I'm going to argue that long term the client to server serialization should be id under JS. So, weird standard & expected node behavior should not be the default. However, it makes sense that should be clearly encoded in the type defs. Luckily, rest has %00 as a null, I just don't know how common that is (node turns it into "").