Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: list_rbind - keep 0-row tibbles if in named list #1116

Closed
werkstattcodes opened this issue Jan 24, 2024 · 1 comment
Closed

FR: list_rbind - keep 0-row tibbles if in named list #1116

werkstattcodes opened this issue Jan 24, 2024 · 1 comment

Comments

@werkstattcodes
Copy link

First, once again many thanks for all the wonderful packages you've been contributing.

I was wondering whether an option like keep_empty=T would make sense for list_rbind.

The use case is the following:

Let's say I have a list with named elements. The elements are tibbles.
I would like to convert the list into one single tibble. purrr's list_rbind works, with the critical shortcoming (at least for my purpose) that it drops the element which is a 0-row tibble (although it is a named element).

library(tidyverse)

li <- list("a"=tibble(x=1), "b"=tibble(x=2), "c"=tibble(x=NULL))
li
#> $a
#> # A tibble: 1 × 1
#>       x
#>   <dbl>
#> 1     1
#> 
#> $b
#> # A tibble: 1 × 1
#>       x
#>   <dbl>
#> 1     2
#> 
#> $c
#> # A tibble: 0 × 0


li %>% purrr::list_rbind(., names_to="element_names")

#> # A tibble: 2 × 2
#>   element_names     x
#>   <chr>         <dbl>
#> 1 a                 1
#> 2 b                 2

The outcome I am looking for would be

#>   element_names     x
#>   <chr>         <dbl>
#> 1 a                 1
#> 2 b                 2
#> 3 c                 NA

I am aware that there are several ways to achieve this result (I had a pertaining question on SO here), but think a keep_empty argument would make the entire procedure more elegant and less prone to the unintended loss of rows.

In my mental model it's a bit like with unnest_longer. I see that there is already a somewhat related FR here.

Many thanks.

@hadley
Copy link
Member

hadley commented Jul 15, 2024

Yeah, agreed. I'm going to merge this with #1096 since I think it'll be easiest to fix both at once.

@hadley hadley closed this as completed Jul 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants