action-table icon indicating copy to clipboard operation
action-table copied to clipboard

Force update action table

Open EclipseKnight opened this issue 1 year ago • 4 comments

Hi again,

I recently began using the action-table wrapped around a table being dynamically updated with JS. It goes as far as removing and appending new

and to the table node at a button click. It appears to occur to any appended columns and rows being added after the page is already loaded and the action-table is applied to an existing table.

When checking the DOM after appending new columns and rows, the existing colgroup from the action-table event firing remains, but fails to fire again for the newly appended elements.

I'm wondering if there is anyway to force the action-table component to scan and re-apply itself to the updated table.

EclipseKnight avatar Mar 29 '24 21:03 EclipseKnight

Ah I see you are pushing the bounds of what I developed this for. I'll add this as an enhancement request but it's not a simple addition so no promises that I can get to it soon.

Possible workarounds:

  1. Have the extra columns there from the start but hidden by CSS. You just need the columns with headers at the start with the columns set to display: none. The JS will still use that to set up the colgroup and sort buttons. You can then have the extra you have JS show the column and dynamically load the data in the cells of the tbody for that column.
  2. When you add the new columns remove the wrapper and then add it back. This should trigger the connectedCallback() which will basically reinitialize the component getting column headers and table content. (This is definitely kludgely and not the fastest).

Reasons why it's not quick to add this:

Right now the mutation observer only runs on the tbody. So it won't update with new appended column headers. I'd need to expand the mutation observer to cover the thead with additional functionality to update the cols variable, colgroup, and header buttons. I won't want to rerun the entire initialization whenever a new column is added so I'd need to refactor and modularize that code to just update the new columns. Doable but definitely more work and QA time than I have time for right now.

colinaut avatar Apr 02 '24 22:04 colinaut

Noticed that you also mentioned adding new rows. This doesn't work either due to how the mutation observer is set up. It's currently designed to only watch for mutations where the target is a td in the tbody. When you add a row, the mutation target is the tbody. And when you add a td or th to a column, the mutation target is the tr.

There is an issue with expanding the mutation observer to cover tbody, which is that sort itself causes a mutation on the tbody because it is moving rows around. I would need to somehow have the mutation observer know if it was a new row verses and old row that has been sorted. Again possible. I can think of a couple ways to handle this but it isn't a quick fix.

colinaut avatar Apr 03 '24 16:04 colinaut

Oh yeah and if I add the functionality to detect when new rows or columns are added then that assumes that it should be able to handle removing columns and rows. Another wrinkle which makes this more complicated.

colinaut avatar Apr 03 '24 16:04 colinaut

Apologies for the late response.

I definitely could tell when I submitted this that it may be beyond the initial design of the component so I completely understand it would require a good bit of work to implement these features.

I did attempt to trigger connectedCallBack again but failed to do so after the table was generated. That being said your approach is different from what I had attempted and makes more sense so I'll see how that fairs.

Thank you very much for the assistance!

EclipseKnight avatar Apr 05 '24 12:04 EclipseKnight