Update bundled DataTable.js; deprecate `dataTableOutput()`

[hadley]

The bundled datatables.js is getting flagged by various customer CVE tools. I think it's worth updating the currently bundled script (it looks like there's a bundled script to do so) and move dataTableOutput() towards more aggressive deprecation so the JS can be removed all together.

(Oh the script exists but says that DataTables won't get updated again 😬)

[wch]

We could do the following:

• Change dataTableOutput and renderDataTable to emit a deprecation message (perhaps one which mentions CVE)
• Remove the .js file from the Shiny package, and instead point to a CDN
• Eventually (in a couple of years) have these functions call out to the DT versions? Or maybe remove them?

[gadenbuie]

Three more thoughts:

1. Write a blog post for current shiny::dataTableOutput() users with a clear roadmap for updating to using DT. We can link to this post from the deprecation message.
2. Provide a user-settable option that switches shiny::dataTableOutput() and related to use DT-provided functions and avoids the deprecation warning.
3. Eventually we can remove the option and use DT by default or throw an error if not installed.

[gadenbuie]

From @jcheng5 in #3627 (comment)

@wch Incredibly, shiny::renderDataTable and DT::renderDataTable are not compatible. Although I think the vast majority of cases can be automatically converted from the former to the latter without much trouble.

It would be helpful for someone to recall or investigate which features are incompatible.

[jcheng5]

In shiny::renderDataTable, the object you return is a data frame. You pass DataTables JS options via the options argument to renderDataTable.

In DT::renderDT, I think you can also return a data frame but if you want to specify options you need to return a DT::datatable() and you pass that function your options. It makes sense, because DT is an htmlwidget and this is how htmlwidgets work; while shiny::renderDataTable predates htmlwidgets.

(OOOHHHH... I just realized (after writing all of the below) that DT::renderDT takes ... that is "ignored when expr returns a table widget, and passed as additional arguments to datatable() when expr returns a data object". Perfect.)

The other arguments from shiny::renderDataTable:

searchDelay - The delay for searching, in milliseconds (to avoid too frequent search requests).

Probably just ignore with a warning.

callback - A JavaScript function to be applied to the DataTable object. This is useful for DataTables plug-ins, which often require the DataTable instance to be available.

A little adapting needs to happen, the shiny version looks like shiny::renderDataFrame(..., callback = "function(table) { alert(table); })" while the equivalent in DT is DT::datatable(..., callback = JS("alert(table)")).

escape - Whether to escape HTML entities in the table: TRUE means to escape the whole table, and FALSE means not to escape it. Alternatively, you can specify numeric column indices or column names to indicate which columns to escape, e.g. 1:5 (the first 5 columns), c(1, 3, 4), or c(-1, -3) (all columns except the first and third), or c('Species', 'Sepal.Length').

DT::datatable() has the same argument with the same semantics. It adds the sentence "since the row names take the first column to display, you should add the numeric column indices by one when using rownames"--I'm not sure what this means but I have a feeling it doesn't apply since there's a rownames argument on DT::datatable but not shiny::renderDataTable.

env / quoted

These exist on DT::renderDT and have the same semantics.

outputArgs - A list of arguments to be passed through to the implicit call to dataTableOutput() when renderDataTable() is used in an interactive R Markdown document.

I'd be slightly surprised if this didn't work in DT already.
(Update: it doesn't work. It'd be an easy thing to add to DT if we felt like it.)
(Update 2: the shiny::dataTableOutput doesn't take any additional args, so we can be sure nobody is using this today.)
(Update 3: Why not... rstudio/DT#1128)