flatten_df strips POSIXct class in top-level variables (related to #358 ?)

[jemus42]

When using flatten_df on a list, I expect the top-level variables in the output to have the same classes as before, yet this is not the case:

my_list <- list(a = lubridate::now(),
                b = list(f = 1, g = 2))

purrr::flatten_df(my_list)
#> # A tibble: 1 x 3
#>             a     f     g
#>         <dbl> <dbl> <dbl>
#> 1 1551127440.     1     2

# Expected output:
tibble::tibble(a = lubridate::now(), f = 1, g = 2)
#> # A tibble: 1 x 3
#>   a                       f     g
#>   <dttm>              <dbl> <dbl>
#> 1 2019-02-25 21:44:00     1     2

(Tested in purrr 0.3.0 and also the current dev version from GitHub)
^{Created on 2019-02-25 by the reprex package (v0.2.1)}

I tried to find out if this is documented / intended behavior, but going by related issue #358, this is not intended, yet apparently fixed as the issue has been closed for a few months now and the thread indicates a successful PR.

Edit: Looking at the discussion of said PR, it looks like the implementation of flatten_* was not touched, so it makes sense that this issue is still present.

[hadley]

@jemus42 do you recall how you got to this point? It's a bit weird that f and g are wrapped in a list(), but a is not, and you want the outer name for a but the inner names for f and g. I'm fairly sceptical that purrr can resolve your problem with a single function call, and I'm leaning towards deprecating flatten_df() all together.

[jemus42]

Oh wow, it's been a while.

I don't recall the context specifically, but odds are I was trying to wrangle some API results that tend to come in uncomfortably nested JSON.
I often found myself trying to flatten that JSON output (parsed to a list of lists) without having to do too much manual restructuring via pluck since the output was often quite large and cumbersome, hoping that flatten_df would just magically get me 95% of the way to some usable data structure.
The issue here seemed like unintended behavior, so I thought that aspect could be worked around.

More specifically, I was probably wrangling trakt.tv API results (movies, tv shows, associated people, ...) in my hobby/procrastination package with some... adventurous "this has to be a tibble!" efforts I mildly regret.. Looking back, it's kind of a mess, but oh well.
That's what I got for wanting to go from API request to ggplot() in two steps.

[hadley]

Ok, if it's a JSON rectangling problem, the chances are it's now better solved with tidyr::unnest_wider() and tidyr::unnest_longer() and we don't need to worry about hammering the semantics of flatten out for this case.