undefined causes badarg

[fogfish]

Hello,

A list of key/value pairs causes badarg exception if it contains an undefined value.
E.g. jsx:to_json([{key, 3},{val, undefined}]).

undefined is a common atom is Erlang to identify unset values. On JavaScript its analogy is null.
I would expect that library would understand this semantic and converts undefined into "null"

• Dmitry

[talentdeficit]

issue 18 has a bit of discussion on why i'm reluctant to equate null and undefined

[fogfish]

Hello,

I've notice issue #18 too late :-) but I would not fully agree with conclusion...
Like kostyushkin said "In fact, undefined is used not only in proplists, but also in the records, and in many other modules. In erlang records undefined used in same context as null in json."

Because, list of key/value pair is not efficient due to inability to apply pattern matching, record and tuples are mainly used in Erlang to model data structures. In my option list of key/value pairs is mainly used as an external interface (e.g. settings, json mapping, etc). Indeed, list of key/value pairs is use-full to model "flexible" data structure but high-performance solution requires tuples.

Based on previous conclusion, records and tuples shall be viewed as primary structures. Therefore and efficient mapping of record into lists of key/value properties is required. In my view, the following code is the best one

jsx:to_term(
lists:zip(
record_info(fields, Record),
lists:nthtail(1, tuple_to_list(Instance))
)
)

However, badarg is throws is any of fields is not defined. Unnecessary list filtering is required.

On another hand JavaScript objects {} and {key: null} are different. The first one obj.key == undefined and second is obj.key == null

Should the {key, undefined} tuples gracefully ignored by jsx? As example [{a, 1}, {b, undefined}] has to correspond to {a: 1} Javascript object. This rule should facilitate both erlang and js sides...

[talentdeficit]

jsx is mostly concerned with manipulating json within erlang applications. the choice of proplists/lists as json representations within erlang was made as those are familiar to erlang programmers and are well supported by language and library support. their use should not be viewed as an attempt to draw an equivalence between json and erlang terms. null in json is null in jsx because jsx needed a representation for null and null was the most obvious choice. undefined is not present in json and is therefore not present in jsx

i do agree that a more general mapping between erlang records and json would be a useful thing but i don't think jsx is an appropriate home for it. the undefined/null problem is just the tip of the iceberg when it comes to having to make opinionated choices about how best the two should be mapped

[fogfish]

it has not been requested to implement record to prop-lists mapping within jsx. I would agree that this is not relevant place to do it.

Instead, jsx should gracefully handle {atom(), undefined} tuples. I am not ever saying that undefined should be mapped to null. My point was that if such tuples are ignored by jsx then it would facilitate most of use-case and would be compliant both to erlang and js.