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 ?