action-table
action-table copied to clipboard
Force update action table
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
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.
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:
- 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. - 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.
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.
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.
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!