by kauegimenes on 6/8/17, 7:24 PM with 63 comments
by billforsternz on 6/8/17, 8:40 PM
by dc2 on 6/8/17, 7:53 PM
by TAForObvReasons on 6/8/17, 8:21 PM
by codezero on 6/8/17, 7:45 PM
Comparing against Numbers (probably a bad comparison?) I am seeing one slightly different result:
If I have a field that is "hehe"
It's encoded as ""hehe""
It looks like Numbers adds the enclosing quotes:
"""hehe"""
I only see enclosing quotes if there's a comma:
"hehe,hehe" -> """hehe,hehe"""
Anyhow, I'm not sure what the "correct" thing to do here is, if there is one, just a heads up!
by danso on 6/8/17, 7:43 PM
The complex array usecase is where an opinionated-type of conversion tool is particularly needed, but I wonder why it behaves like this:
name: 'Robert',
lastname: 'Miller',
family: null,
location: [1231,3214,4214]
lastname,name,family.type,family.name,nickname,location
Miller,Robert,,,,1231,3214,4214Why not have `location_1, location_2, location_3`, instead of having a single location column? The latter implementation makes the data difficult to quickly use in a program (like a spreadsheet).
by kmike84 on 6/8/17, 11:53 PM
1) csv writer (and reader?) which takes care of all csv dialects crazyness; 2) a library which "flattens" nested objects/arrays?
(1) is not opinionated (besides a few API choices), it just has to be correct; it doesn't make much sense to re-implement (1) everywhere.
(2) can be more opinionated, it is easy to disagree with design choices, there is more room for personal preferences.
For example, in Python there is CSV stdlib module, and for (2) there are libraries like https://github.com/scrapinghub/flatson. Why put both to the same library? Is it something ideomatic in node.js world, with a deeper reason to design libraries this way (e.g. download size), or is it just an oversight?
by BrandiATMuhkuh on 6/8/17, 11:26 PM
by chid on 6/9/17, 4:01 AM
by freezer333 on 6/8/17, 9:15 PM
by madamelic on 6/8/17, 8:18 PM
Either way, neat addition.
by tambourine_man on 6/8/17, 9:42 PM