Open damianobarbati opened 6 years ago
Thank you for the suggestion @damianobarbati 🙂 The reason we added explicit typing is due to potential expansion in the future. Since JSON doesn't natively support the more advanced types, e.g. dates.
I think it's very application specific what data structure you have to start, so I don't know if it's a good idea to change it in our lib, but I appreciate any arguments against this notion 🙂
Then it's a smart choice :) I'd say it would be probably better "battery included" if it did automatic type and header detection as mentioned anyway, but allowing further customisations (i.e: parser/getter on properties) in the future once they get supported.
OT: do you think the reverse (parsing xlsx/xls single sheet) would be something doable in this very same project? Maybe supporting just xls and xlsx file types. xlsx
is really an overkill.
Wouldn't the following be much easier to use?
Object.keys
on first row or an array can be given into config to consider just specific set of properties in arrayThis way no processing on the dataset would be required to developer at all, since typically we'd have an array of objects.
Great library man 👍🏻