Programmatic scrolling of a datatable

[prubin]

I just went through 25 fruitless iterations with Shiny Assistant (I'm a glutton for punishment), and it was never able to solve the following coding problem. I want to create a Shiny app that displays the USArrests data set in a datatable. The table should have one page and allow sorting on columns. The app should also have a select input listing states, a text input, and an action button. When the action button is clicked, the value in the text input should be inserted in the "Murder" column of the table for the selected state. The table should maintain the sort order selected by the user, and the display should automatically scroll to the altered row. (This is actually a toy version of something I hope to embed in a much larger application.)

I think the fundamental problem is tied to the fact that if the user sorts the table on the Murder column and then alters the Murder value for one state, that state's row moves (assuming sort order is maintained after the change). The Shiny Assistant attempts exhibited all sorts of pathologies (error messages, loss of sort order, loss of the entire table display). The closest it came would result in sort order being preserved and the row updating correctly, but failure to scroll to its new location. In my more complex application, I too am stuck on that one point: scrolling to the altered row's new resting place. If the table's output ID is "A", what I see happening is that, after the edit to the table, the display updates correctly but input$A_rows_all, which is supposed to show the sorted order of the rows, fails to update. It continues to show the row order before the update.

Has anyone encountered this before, and more importantly does anyone have any suggestions?

[prubin]

I have found a solution (I think). The issue is one of synchronization. When I push a data change (using DT::replaceData() with a proxy for table A), changes may look immediate but they are not. So the function I used to change the data moves on to playing with row numbers before DT has finished the update and adjusted the row numbers.

The workaround I found is to follow replaceData() with observeEvent(input$A_rows_all, { ... }), where ... uses the rows_all vector to locate the altered record's position in the sort order of the table. This causes the function containing the call to replaceData() to wait until input$A_rows_all has caught up before continuing with processing.