feat(elements-grid): Add content children ready event. by MayaKirova · Pull Request #15226 · IgniteUI/igniteui-angular

MayaKirova · 2025-01-09T16:13:07Z

Additional information (check all that apply):

Checklist:

All relevant tags have been applied to this PR
This PR includes unit tests covering all the new code (test guidelines)
This PR includes API docs for newly added methods/properties (api docs guidelines)
This PR includes feature/README.MD updates for the feature docs
This PR includes general feature table updates in the root README.MD
This PR includes CHANGELOG.MD updates for newly added functionality
This PR contains breaking changes
This PR includes ng update migrations for the breaking changes (migrations guidelines)
This PR includes behavioral changes and the feature specification has been updated with them

damyanpetev · 2025-01-13T12:02:35Z

projects/igniteui-angular/src/lib/grids/grid-base.directive.ts

+    /* blazorInclude */
+    /** @hidden @internal */
+    /**
+     * Emitted when content children are attached and collections in grid are updated.
+     */
+    @Output()
+    public contentChildrenReady = new EventEmitter<void>();


Was going to say we can leave this on the Elements level only, since it's only used there, but...
We could easily add this event to the static models since the Elements setup doesn't need anything extra. However, that will loose the WC type declarations from the analyzer which will actually play an important role in generating manifests we're leveraging for other platforms.
Could be done on the analyzer level, but again there are a few other things I want to address.

IMO, it'd be best if we keep this in the Elements project, though I realize how annoying it'll be to extend and override the base. Ideally, we'd just extend the declaration, however that's not available and I'm actually not sure we care to have this event on all of them - don't think the Pivot has such an issue and not sure about the row islands situation. Might be okay with extending Grids specifically in Elements.

Would also like to have some tag (like @igxChildrenReady) and have the elements analyzer add that into the config for those components so the strategy can be driven by that rather than hardcoding the emit. I could help with that part. There's also an issue that'll solve, will leave a separate comment on that.

PS: Naming TBD lol, not sure if this isn't too Angular-ish

I'm fine with extending all the grids for elements. I think we'll eventually have to do that either way since there are many modifications made in the code specifically to make it work for the react/blazor code generations that are not relevant to angular. Tracking them all might be a pain, though. Not sure if it should be part of this feature request.

@damyanpetev After discussing with @dkamburov I've logged this as a separate task:
#15235
All such members can be moved in the new extended component as part of that task.

damyanpetev · 2025-01-13T12:08:21Z

projects/igniteui-angular-elements/src/app/custom-strategy.ts

+            promises.push(promiseComponentReady);
+        }
+        Promise.all(promises).then(() => {
+            (this as any).componentRef?.instance.contentChildrenReady.emit();


This will trigger for all components with content children - you can check the config but all column layouts & groups, toolbar, action strip at least. Those don't have contentChildrenReady and will actually throw here, besides it being an unnecessary work. I think the zone is doing some supper annoying consuming of promise rejections (-.-) but if you try-catch this and log the errors you'll get a bunch of those:

This is why I want the special event to be part of the config, so the strategy can check which components should emit.

I mean, a tag that generates a config is fine, but a null check would be simpler. Do we need a config for everything?

Oh, I sort of imagined the config having some typed section that had the content children loaded event name so that's read from there too. Possibly overcomplicating it, since the emit will be strategy code and possibly we won't care for different names, but still the event belongs to the component and would like to have as little as possible coupling.
But I'd be fine w/ just the check for this PR, sure.

The null check is already handled via ?.childrenAttached?.emit() optional chaining. Additionally, in commit 4739672, added null guards on componentConfig?.contentQueries?.filter(...) and changed the length check to !contentQueryChildrenCollection?.length to safely handle components that aren't in the config.

damyanpetev · 2025-01-13T12:25:31Z

projects/igniteui-angular-elements/src/app/custom-strategy.ts

+        for (const contentChild of contentChildren) {
+            // these resolve after the parent, both the components needs to be initialized and the parent query schedule should complete before it is really ready.
+            const child = contentChild as IgcNgElement;
+            const promiseComponentReady = this.waitForCondition(() => (child.ngElementStrategy as any)?.componentRef && this.schedule.size == 0);
+            promises.push(promiseComponentReady);
+        }
+        Promise.all(promises).then(() => {


Yeah, this is less-than-ideal :) Not really a fan of the interval checking, tho need to see if anything else is viable. There's another problem too - we're not guaranteed all children will ever be registered, so a hard await on that could never complete, thought that might end up as a documented limitation of the event.

Was thinking a rolling timeout that incoming children can extend - think schedule the emit and a new child init can cancel it - I still think the event should emit when there are no children initialized after all. Not entirely sure the timing can work.
We might end up having to check if those components will be initialized and decide if we emit immediately of leave the emit at the end of updateQuery actually when the schedule empties. Should be easy enough to handle that with a flag and will skip on the additional intervals entirely. From the timing I'm seeing as long as we know updateQuery will run it's pretty much the last thing that manages to run after all children have initialized.

If there's a child that is a valid content child of the grid and it never registers, wouldn't that be a bug rather than a valid scenario? I'm not sure in what case this would normally happen or how to even test it.

A user error - sure, but would be nice if the event still works for the most part, sans the unregistered child element.
Otherwise, yes - not really a major concern

damyanpetev · 2025-01-14T15:59:50Z

projects/igniteui-angular-elements/src/app/custom-strategy.ts

        (this as any).componentRef = {};

        const toBeOrphanedChildren = Array.from(element.children).filter(x => !this._componentFactory.ngContentSelectors.some(sel => x.matches(sel)));
+        const contentChildren = Array.from(element.children).filter(x => this._componentFactory.ngContentSelectors.some(sel => x.matches(sel)));


This might need some more refinement since ngContentSelectors will give all projected children and not all of those need to have a content query (e.g. the state component right now) which won't schedule any query updates and thus won't trigger the event at all.
Should be possible to further filter the children through their matching config, need the component or provideAs to match those against the componentConfig.contentQueries[n].childType-s so we know for sure a child is expected to run query update and leave the emit for that.

Ah, further annoying bit can be the descendants bit on the query, might need to account for that as well

damyanpetev · 2025-01-14T16:12:00Z

projects/igniteui-angular-elements/src/app/custom-strategy.ts

+
+        if (contentChildren.length === 0) {
+            // no content children, emit event immediately, since there's nothing to be attached.
+            (this as any).componentRef?.instance?.childrenAttached?.emit();


Also, might want to emit this after the component has actually initialized - around the end of this method.

Moved the immediate emit to the end of initializeComponent (after view attachment, parent query setup, and patchGridPopups) in commit 4739672.

…lection.

MarielaTihova · 2025-03-19T23:02:19Z

Currently the event for content children ready only does not work as a native event. Using a custom event does the job, but a bug has been created for native event case -> https://infragistics.visualstudio.com/Indigo_Platform/_workitems/edit/36978

dkamburov · 2025-03-26T15:24:34Z

@damyanpetev can you please do a final review on this one

github-actions · 2025-05-30T00:14:57Z

There has been no recent activity and this PR has been marked inactive.

dkamburov · 2025-06-16T13:06:48Z

@MayaKirova please resolve the conflict here
@damyanpetev are we ready to merge this now?

github-actions · 2025-08-17T00:16:52Z

There has been no recent activity and this PR has been marked inactive.

github-actions · 2025-11-24T00:16:22Z

There has been no recent activity and this PR has been marked inactive.

github-actions · 2026-01-28T00:17:16Z

There has been no recent activity and this PR has been marked inactive.

damyanpetev · 2026-03-29T07:10:20Z

@copilot merge master and resolve conflicts

…itialized Agent-Logs-Url: https://github.com/IgniteUI/igniteui-angular/sessions/8468a815-5933-4d6a-8967-da503ef2bdd5 Co-authored-by: damyanpetev <3198469+damyanpetev@users.noreply.github.com>

Copilot · 2026-03-29T07:17:45Z

@copilot merge master and resolve conflicts

Merged in commit 3851f04 (already done). Also addressed the remaining review comments in commit 4739672.

damyanpetev · 2026-03-29T12:24:49Z

@copilot, no this branch is not up to date, so revert the last commit addressing comment I didn't request and merge master again and resolve conflicts and this time do only that.

…fully initialized" This reverts commit 4739672. Co-authored-by: damyanpetev <3198469+damyanpetev@users.noreply.github.com>

# Conflicts: # projects/igniteui-angular-elements/src/index.html Co-authored-by: damyanpetev <3198469+damyanpetev@users.noreply.github.com>

Copilot · 2026-03-29T12:28:27Z

@copilot, no this branch is not up to date, so revert the last commit addressing comment I didn't request and merge master again and resolve conflicts and this time do only that.

Reverted the last commit in b02649f and merged master with conflicts resolved in d4c28ce.

feat(elements-grid): Add content children ready event.

560f034

MayaKirova added ❌ status: awaiting-test PRs awaiting manual verification 💠 grid: elements version: 19.1.x labels Jan 9, 2025

MayaKirova requested review from damyanpetev and dkamburov January 9, 2025 16:13

MayaKirova assigned dkamburov Jan 9, 2025

damyanpetev reviewed Jan 13, 2025

View reviewed changes

chore(*): Apply review comments.

13053be

MayaKirova requested a review from damyanpetev January 14, 2025 12:48

damyanpetev reviewed Jan 14, 2025

View reviewed changes

MKirova added 2 commits January 15, 2025 14:30

chore(*): Add condition based on content children with rel. query col…

6516dfe

…lection.

chore(*): Add scenario to test hgrid as well.

8b5559b

MayaKirova requested a review from damyanpetev January 16, 2025 08:46

dkamburov assigned MarielaTihova Feb 25, 2025

dkamburov added version: 19.2.x and removed version: 19.1.x labels Mar 5, 2025

MarielaTihova added ✅ status: verified Applies to PRs that have passed manual verification and removed ❌ status: awaiting-test PRs awaiting manual verification labels Mar 19, 2025

github-actions bot added the status: inactive Used to stale issues and pull requests label May 30, 2025

dkamburov added version: 20.0.x and removed status: inactive Used to stale issues and pull requests version: 19.2.x labels Jun 2, 2025

Merge branch 'master' into mkirova/feat-15050

2fa6de3

github-actions bot added the status: inactive Used to stale issues and pull requests label Aug 17, 2025

dkamburov removed the status: inactive Used to stale issues and pull requests label Aug 19, 2025

Konstantin Dinev added 2 commits September 17, 2025 11:49

Merge branch 'master' into mkirova/feat-15050

72773bf

Merge branch 'master' into mkirova/feat-15050

3851f04

damyanpetev mentioned this pull request Oct 2, 2025

test(elements): adjust wait timing to address test flicker 😞 #16271

Merged

14 tasks

github-actions bot added the status: inactive Used to stale issues and pull requests label Nov 24, 2025

MayaKirova mentioned this pull request Nov 24, 2025

Add delay since on grid rendered column have not init yet, hence filt… IgniteUI/igniteui-blazor-examples#1158

Merged

dkamburov removed the status: inactive Used to stale issues and pull requests label Nov 28, 2025

github-actions bot added the status: inactive Used to stale issues and pull requests label Jan 28, 2026

dkamburov removed the status: inactive Used to stale issues and pull requests label Jan 28, 2026

mddragnev mentioned this pull request Feb 12, 2026

[IgbGrid] state-persistence - Reload causes ExpectedStartOfValueNotFound IgniteUI/igniteui-blazor#135

Open

Copilot started work on behalf of damyanpetev March 29, 2026 07:10 View session

fix(elements-grid): emit childrenAttached after component is fully in…

4739672

…itialized Agent-Logs-Url: https://github.com/IgniteUI/igniteui-angular/sessions/8468a815-5933-4d6a-8967-da503ef2bdd5 Co-authored-by: damyanpetev <3198469+damyanpetev@users.noreply.github.com>

Copilot finished work on behalf of damyanpetev March 29, 2026 07:18

Copilot started work on behalf of damyanpetev March 29, 2026 12:24 View session

Copilot AI and others added 2 commits March 29, 2026 12:25

Revert "fix(elements-grid): emit childrenAttached after component is …

b02649f

…fully initialized" This reverts commit 4739672. Co-authored-by: damyanpetev <3198469+damyanpetev@users.noreply.github.com>

Merge remote-tracking branch 'origin/master' into mkirova/feat-15050

d4c28ce

# Conflicts: # projects/igniteui-angular-elements/src/index.html Co-authored-by: damyanpetev <3198469+damyanpetev@users.noreply.github.com>

Copilot finished work on behalf of damyanpetev March 29, 2026 12:29

Conversation

MayaKirova commented Jan 9, 2025

Additional information (check all that apply):

Checklist:

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 29, 2026

Choose a reason for hiding this comment

Uh oh!

damyanpetev Jan 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

damyanpetev Jan 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 29, 2026

Choose a reason for hiding this comment

Uh oh!

MarielaTihova commented Mar 19, 2025

Uh oh!

dkamburov commented Mar 26, 2025

Uh oh!

github-actions bot commented May 30, 2025

Uh oh!

dkamburov commented Jun 16, 2025

Uh oh!

github-actions bot commented Aug 17, 2025

Uh oh!

github-actions bot commented Nov 24, 2025

Uh oh!

github-actions bot commented Jan 28, 2026

Uh oh!

damyanpetev commented Mar 29, 2026

Uh oh!

Copilot AI commented Mar 29, 2026

Uh oh!

damyanpetev commented Mar 29, 2026

Uh oh!

Copilot AI commented Mar 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

damyanpetev Jan 13, 2025 •

edited

Loading

damyanpetev Jan 14, 2025 •

edited

Loading