datamgmt::create_attributes_table goes buggy after entering ~10 attributes

[jagoldstein]

The Shiny UI opened from datamgmt::create_attributes_table() stops letting users populate/edit cells after ~10 attributes are entered.

[dmullen17]

It works for me if right-click and click either "Insert row above" or "Insert row below"

[jagoldstein]

that works for a few attributes for me and the interns, but then breaks before the 20th attribute. @dmullen17 how many rows did you try adding and filling in?

[dmullen17]

I just did 34, could've kept going but I think the function is fine. To scroll down you need to move your cursor all the way over to scroll bar on the right - it won't automatically scroll down to the next row when it's created.

[jagoldstein]

No, the issue does not have to do with scrolling. More rows can be added. The bug has to do with not being able to populate the cells. I'll show you in-person.

[dmullen17]

Ah I see. I was able to populate attribute names up to those 34 rows, but when I tried to add domain it bugged out

[dmullen17]

I'm able to edit rows past the 10th row as long as I pre-populate them with some dummy data before I run the shiny app.

x <- data.frame(matrix(NA, 1, 45))
shiny_attributes(x)

So now i'm curious as to whether this ever worked. It's possible that we've always had some sort of PI-generated metadata, whether it's a csv or an EML attributes table, that we pass as an input to create_attributes_table, thereby not triggering this bug. That would make this the first attributes table with > 10 attributes that we've generated 100% by hand.

[jagoldstein]

That's interesting. Let's meet with Noelle this afternoon to inquire, but on Friday she claimed that she's been using this same workflow for a while (opening blank tables and adding attributes manually for NetCDF files with ~46 attributes). She said that it worked fine as recently as the morning of May 29, 2019 (last week). So that would mean it broke sometime between then and 2pm PDT May 31, 2019.

[dmullen17]

I think it's worth leaving this open as a bug, but given that I've found a viable workaround (just populate the table with as many dummy rows as you need), it's going to be pretty low on my priorities right now. I read through the underlying code and read through some related stackoverflow issues but didn't find anything thus far.