fix(action-strip): Assign parent to not destroy on DOM move. #16270
Conversation
MayaKirova
added
❌ status: awaiting-test
| * ``` | ||
| */ | ||
| public show(context?: any): void { | ||
| if(!this._originalParent) { |
There was a problem hiding this comment.
Hm, if every workflow goes through show we might even move the caching of the original parent here ngAfterViewInit where it was originally, so both cache and return are on the show/hide pair.
Anyway, I'm assuming this fixes the disappearing strip if it inits in some case as detached, but still is attached before showing.
| const grid = context.grid; | ||
| grid.deleteRow(context.key); | ||
|
|
||
| this.grid.cdr.detectChanges(); |
There was a problem hiding this comment.
Okay, the original parent bit I get, but do we really need this? Any context why a full grid change detection is needed/doing?
There was a problem hiding this comment.
Surely the deletion and CRUD service will also do that if needed, so this one would be extra even.
There was a problem hiding this comment.
deleteRow removes the record from the data, but the actual removal of the DOM element happens on the next change detection. This creates a bit of a timing issue.
I no longer remember the details, since it has been a while, however I can confirm that the code does not work without the change detection (the issue reproduces without the change detection and is fixed with the change detection).
There was a problem hiding this comment.
@damyanpetev Here are a few observation.
The issue is specifically when you delete the last row and there's no next row in the grid, for example you have a grid with only 2 rows and you delete the second one. So this means that the RowComponent associated with the row will be destroyed. The issue happens when the moment the row is destroyed the action strip is still inside it:
Hence the destroy and removal of the row, also removes and destroys the action strip.
To me it seems that the logic that moves the action strip back to the root of the grid, the one inside the hide API:
this.renderer.appendChild(this._originalParent, this._viewContainer.element.nativeElement);
Happens asynchronously - so it does not immediately move it to the root in time, before angular goes and destroys the parent. So regardless of the order:
this.strip.hide();
grid.deleteRow(context.key);
or
grid.deleteRow(context.key);
this.strip.hide();
It never manages to move the strip out of the row in time.
Also another fun observation - if you debug the deleteRowHandler code or the one inside the hide method, the issue stops reproducing as then the code executes synchronously and moves the strip to the root just fine.
Adding a change detection somewhere in the deleteRowHandler (doesn't matter where - before, between or after the other actions) seems to force it to resolve the operation and causes it work again.
There was a problem hiding this comment.
@MayaKirova you're right to suspect something async happening, sure, except it's not the appendChild being async (that one is very much synchronous for the dom version). The The actual delete calls markForCheck and the actual re-render happens on next cycle so order of calls in that location doesn't change the outcome.
What I'm actually observing is quite interesting:
this.strip.hide();
works exactly as it should and moves the strip back to the grid element (can confirm with a simple log to avoid messing with timing during debug). Except something else moves the strip back to the row and gets it deleted permanently from the DOM by destroying the row. That's why the detectChanges() helps, cuz it forces the deletion to happen first, so the return to DOM on hide() sticks.
Logpoint at the end of hide like so
and one on renderer.removeChild yields the following when I hit the delete on a single row:
So the actual issue which I haven't dug out yet - why on earth is the action strip returning to its row just before it gets destroyed so it can deleted along with its DOM host.
There was a problem hiding this comment.
@damyanpetev It seems to me that the show gets called after the hide, so it moves it back:
Probably because the row is not yet deleted and the mouse is still over it.
There was a problem hiding this comment.
Yeah, was just going to note that there's a secondary show()
projects/igniteui-angular/src/lib/action-strip/grid-actions/grid-editing-actions.component.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Okay, this is way more logical than a forced change detection :)
Would still love to prevent the extra show in this scenario, though that'd be much more involved of a fix for another time, and the destroy cleanup still makes sense regardless.
PS: Also wouldn't mind an Angular/Elements test at some point covering this.
3 participants
Closes #15768
Closes #15911
Closes IgniteUI/igniteui-webcomponents#1861
Additional information (check all that apply):
Checklist:
feature/README.MDupdates for the feature docsREADME.MDCHANGELOG.MDupdates for newly added functionalityng updatemigrations for the breaking changes (migrations guidelines)