CRAN status R-CMD-check codecov CRAN downloads

editbl allows you to do exactly what is says: ‘edit tibbles’. Meaning you can explore and modify any kind of tabular data, independently of where it is stored, in a spreadsheet-like fashion.

The package builds around DT as light weight as possible to provide you with a nice interface to edit your data, while still keeping as much flexibility as possible to customize the table yourself.

Main features by which it distinguishes itself from other CRUD (create, read, update, delete) packages:


remotes::install_github("", ref = "main", subdir = "editbl")

Get started

Choose a dataset of your liking and use eDT to interactively explore and modify it!

modifiedData <- editbl::eDT(mtcars)

Run some demo apps


More examples can be found here

Switching from DT

Let’s say you already use DT::datatable to display your data, but want to switch to editbl::eDT to be able to edit it. What should you look out for?

Foreign tables

Sometimes you want to restrict certain columns of your table to only contain specific values. Many of these restrictions would be implemented at database level through the use of foreign keys to other tables.

Editbl allows you to specify similar rules through the use of foreignTbls as an argument to eDT. Note that you can additionally hide surrogate keys by the use of naturalKey and columnDefs if you wish to.

a <- tibble::tibble(
    first_name = c("Albert","Donald","Mickey"),
    last_name_id = c(1,2,2)

b <-  foreignTbl(
      last_name = c("Einstein", "Duck", "Mouse"),
      last_name_id = c(1,2,3)
  by = "last_name_id",
  naturalKey = "last_name"

  foreignTbls = list(b),
  options = list(columnDefs = list(list(visible=FALSE, targets="last_name_id")))

Support for different backends

dplyr code is used for all needed data manipulations and it is recommended to pass on your data as a tbl. This allows editbl to support multiple backends through the usage of other packages like dtplyr, dbplyr etc.

In case you pass on other tabular objects like data.frame or data.table the function will internally automatically cast back and forth to tbl. Small side effects may occur because of this (like loosing rownames), so it might be better to cast yourself to tbl explicitly before passing on data to be in full control.

# tibble support
modifiedData <- editbl::eDT(tibble::as_tibble(mtcars))

# data.frame support
modifiedData <- editbl::eDT(mtcars)

# data.table support
modifiedData <- editbl::eDT(data.table::data.table(mtcars))

# database support
tmpFile <- tempfile(fileext = ".sqlite")
file.copy(system.file("extdata", "chinook.sqlite", package = 'editbl'), tmpFile)
conn <- editbl::connectDB(dbname = tmpFile)
modifiedData <- editbl::eDT(dplyr::tbl(conn, "Artist"), in_place = TRUE)

# excel integration
xlsx_file <- system.file("extdata",
xlsx_tbl <- tibble::as_tibble(
modified <- eDT(xlsx_tbl)
openxlsx::write.xlsx(modified, xlsx_file)

Note that there are some custom methods in the package itself for rows_update / rows_delete / rows_insert. The goal would be to fully rely on dplyr once these functions are not experimental anymore and support all needed requirements. These functions also explain the high amount of ‘suggested’ packages, while the core functionality of editbl has few dependencies.

Concurrent updates

editbl does not attempt to detect/give notifications on concurrent updates by other users to the same data, nor does it ‘lock’ the rows you are updating. It just sends its updates to the backend by matching on the keys of a row. If other users have in the meantime made conflicting adjustements, the changes you made might not be executed correctly or errors might be thrown.


General future goals for this package



These are other popular CRUD packages in R. Depending on your needs, they might be better alternatives.







CRAN tibble

Blogpost buttons in DT

Blogpost shiny vs excel

Generic CRUD application

Example SQLite databse