Question: .required vs required?

[ramiromagno]

Some tib_*() functions accept the parameter required, while others take .required. Why not all .required?

Thanks for this package, I'm loving it!

P.S. btw, is this package meant to offer equivalent functionality to that of {tidyjson}?

[mgirlich]

I basically follow the design principles of the tidyverse here. E.g. look at dplyr::slice(.data, ..., .by = NULL, .preserve = FALSE) vs dplyr::slice_head(.data, ..., n, prop, by = NULL).
I think it makes sense to follow these design principles but I'm also not quite sure in this case. Always having .required would make things a bit easier.

PS: I think that {tidyjson} has a different idea. It works a bit more like {tidyr} for JSON. {tibblify} on the other hand works on nested lists (that frequently come from JSON) and transforms them into a tibble. There is surely some overlap but the approach is quite different.
My motivation for this package was to transform JSON data from REST apis into a tibble. The tools available back then were too slow (from a computational perspective) and not comfortable to use. I think this package solves both aspects pretty nicely.

[ramiromagno]

Hi @mgirlich,

Thank you for your answer! A difficult of a tradeoff there indeed...

May I ask another question? Have you considered supporting the specifications in a declarative language, e.g. YAML, that could be compiled ahead of time and then used to transform the lists to tibbles even more efficiently? That would also allow to exchange specs more easily, or even create a data package of specs only.

I mean something like:

# `my_spec` would be an R object with an efficient representation of the "tibblification" required
my_spec <- read_spec(path = "foo_spec.yml")
tibblify(x, my_spec)

[mgirlich]

Some time ago I added a parser for an OpenAPI spec (parse_openapi_spec()). So this basically supports JSON schema. It surely makes sense to add proper support for JSON schema.