Bad priority handler in dataEditServer

[earnaud]

Hi,

thanks you for this amazing package.
I came across a bug when I tried to use your package, and think I grabbed its cause.

Bug description

I use a shinytree with two node levels: first one is data table names, and second one (leaves) are the different rows of the data table. A button lets the user access the selected data table (whatever is the selected row) and edit it in a modal. The currently selected table has a matching reactive (selected_table) which is given to dataEditServer as its data argument.
When testing my feature, I click on an item of the first table (5 rows), and clicks the button to display the modal. Everythnig is fine.
Then I click on an item of the second table (20 rows) and clicks the button to display the modal. Everything is fine again.
Then, I click back on an item of the first table, and clicks the button to display the modal. And there, the table is a 20-rows table containing the actual table repeated 4 times.

My investigation

I used R.utils::reassignInPackage() to customize dataEditServer() and added a browser() at the beginning of the observeEvent(input$x) (line 279 of https://github.com/DillonHammill/DataEditR/blob/master/R/dataEdit.R). This allowed me to inspect variables while the bug is occurring:

• hot_to_r(input$x) returns the table 2 while I expected the table 1.
• values$x returns the table 1 (not sure what has to be expected).
• data_to_edit() returns the table 1 as expected.
  As far as I understand dataEditServer documentation, I shall expect the dataEditUI to be updated before its value is handled. This does not seem to be the case here.

I couldn't get to write a reproducible example of my case, so let me know if there are other pieces of information you would need.

[DillonHammill]

Sounds like a namespacing issue. Are you using unique ids for each table? Do you have a simple reproducible example or code snippet you can share?

[earnaud]

A namespacing issue would result in a non-reactivity. Here, the table reacts but does not update correctly.

I will try to work on a reproducible example.

Also, do you plan to add a updateDataEdit function?

[DillonHammill]

Thanks @earnaud, this will go a long way in improving my understanding of the problem. What would updateDataEdit do?

[earnaud]

It would be a way to provide a non-reactive data.table in the data argument of dataEditServer, and have a fine control on the way the table widget updates.

[earnaud]

Well, here is a first reprex. I did not meet the described bug, but I had another issue before this: the data seems to send bug although it is a common 10-rows data table.
The app refers to two files (linked in the zip) that shall be taken into account if the app.R is sourced.

20220810_DataEditR.zip

[yvanlebras]

is it possible to have feedback on this issue ?

[DillonHammill]

Thanks for reporting this issue. I believe the issue occurs when dataEditServer receives reactive data that changes (e.g., user switches between tables in a modal), input$x fires with stale data from the previous rhandsontable before the widget re-renders. The stale observeEvent(input$x) overwrites values$x, causing the old table to appear (e.g., a 5-row table repeated 4× to fill a prior 20-row layout).

I've made the following changes to DataEditR v1.0.0 to address this:

• data_loading flag in reactiveValues — set TRUE when data_to_edit() updates values$x, cleared on next input$x event.
• early return guard in observeEvent(input$x) — skips processing when data_loading is TRUE, preventing stale widget data from overwriting the freshly loaded table.
  -rReset row_index on data switch — avoids carrying over stale row indices from the previous table.

Please let me know if this fixes the issue you observed. Otherwise, I'm happy to take another look.