Remix.run Logo
gethly 3 days ago

This V2 is still pushing forward the retarded behavior from v1 when it comes to handling nil for maps, slices and pointers. I am so sick and tired of this crap. I had to fork the v1 to make it behave properly and they still manage to fuck up completely new version just as well(by pushing omitempty and ignoring omitnil behavior as a standalone case) which means I will be stuck with the snale-pace slow v1 for ever.

adamrt 3 days ago | parent | next [-]

Are you sure about that? Unless I'm misunderstanding they did fix this: https://pkg.go.dev/encoding/json

"In v1, a nil Go slice or Go map is marshaled as a JSON null. In contrast, v2 marshals a nil Go slice or Go map as an empty JSON array or JSON object, respectively. The jsonv2.FormatNilSliceAsNull and jsonv2.FormatNilMapAsNull options control this behavior difference. To explicitly specify a Go struct field to use a particular representation for nil, either the `format:emitempty` or `format:emitnull` field option can be specified. Field-specified options take precedence over caller-specified options."

ycombinatrix 3 days ago | parent | prev | next [-]

What is your preferred behavior for a nil map/slice? Feels weird that it doesn't map to null.

gethly 3 days ago | parent [-]

When you are unmarshaling json, empty map/slice is something completely different than a null or no value present, as you are losing intent of the sender, in case of JSON REST.

For example, if my intent is to keep the present value, I will send {"foo": 1} or {"foo": 1, "bar": null} as null and no value has the same meaning. On the other hand, I might want to change the existing value to empty one and send {"foo": 1, "bar": []}.

The server must understand case when I am not mutating the field and when I am mutating the field and setting it to be empty.

On the other side, I never want to be sending json out with null values as that is waste of traffic and provides no information to the client, ie {"foo": 1, "bar": null} is the same as {"foo": 1}.

Protocol buffers have the exact same problem but they tackle it in even dumber way by requiring you to list fields from the request, in the request's special field, which you are mutating as they are unable to distinguish null and no value present and will default to empty value otherwise, like {} or [], which is not the intent of the sender and causes all sort of data corruption.

PS: obviosly this applies to pointers as a whole, so if i have type Request struct { Number *int `json:"number"} then sending {} and {"number": null} must behave the same and result in Result{Number nil}

3 days ago | parent [-]
[deleted]
Mogzol 3 days ago | parent | prev | next [-]

Isn't that what the new 'omitzero' option is for?

https://pkg.go.dev/github.com/go-json-experiment/json#exampl...

kanbara 2 days ago | parent | prev [-]

you know you can make your case better if you don’t use disrespectful and offensive language