-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(elements): add broadcast channel to sync icons with wc #14498
Conversation
ada18c9
to
e7b055f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can consider re-targeting to 18.1.x so this can be used with the next xplat releases, especially if we move the service to elements and it doesn't affect the main Angular project at all.
projects/igniteui-angular/src/lib/icon/icon.broadcast.service.ts
Outdated
Show resolved
Hide resolved
fb98273
to
cf75616
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides the usage/lifecycle comment that's not important right now, the rest LGTM.
], | ||
// bootstrap: [] | ||
}) | ||
export class AppModule { | ||
|
||
constructor(private injector: Injector) {} | ||
constructor(private injector: Injector, private _iconBroadcast: IgxIconBroadcastService) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, kind of better we're keeping this in Elements for now.
A bit awkward in terms of usability as it stands having to inject just to trigger the functionality. So it either doesn't need to go through the DI system or perhaps we should consider some API on it like start
& stop
basically - both to make sense as usage and to have a cleanup mechanism.
Alternatively, since this isn't root-provided it should be able to take advantage of ngOnDestroy
for cleanup.
Both of those things technically don't matter much for Elements, since this module will never destroy until the entre app does, but still should be noted.
|
||
if (message.actionType === ActionType.SyncState || | ||
message.actionType === ActionType.UpdateIconReference) { | ||
this.updateRefsFromCollection(message.references); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming it's the responsibility of the other side to only emit the icons that do need changing for UpdateIconReference
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. The other side sends the state of the collections and this side updates its own state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hehe, then it's not a "yes" answer :) The question was if "the other side to only emits the icons that do need changing".
If the other side sends the entire state of the collections, every API for change on that side will also cause the Angular side to re-register all previous icons for example, which is at least redundant if it doesn't affect performance much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nvm, checked the implementation, the other side creates a fresh collection for each change, so it is sending just the modified refs. No need to break-check me like that 😄
…en angular and wc.
Goes with: IgniteUI/igniteui-webcomponents#1295
Closes #
Additional information (check all that apply):
Checklist:
feature/README.MD
updates for the feature docsREADME.MD
CHANGELOG.MD
updates for newly added functionalityng update
migrations for the breaking changes (migrations guidelines)