primefaces
Reviving #14491 - Can't inject environmentInjector into dialog opened by DialogService
Describe the bug
Link: #14491
Sorry I got busy with renovations, reiterating on this one now.
Unforutunately the workaround proposed (provide the service in an upper level) is not feasible for me, since I wish to keep the available services to a minimum, and moving stuff to an upper layer would violate that principle.
The issue can be reproduced with a small modification to the stackblitz provided in the original issue, by moving the DialogService provider down a layer, here: https://stackblitz.com/edit/7qkchf-9jk9cd
Logically it should still be able to access the providers in its parent, but it doesn't.
The current layout looks like this:
Demo Module:
- provides the Demo Service
- declares the DynamicDialogExampleDemo
- which provides the DialogService
- declares AnotherComponent
The goal is for AnotherComponent to be unable to access the DialogService, since it has no concern for it. My assumption and expectation is that the Dialog created by DynamicDialogExampleDemo should be able to inject DemoService, since the Dialog is created below that injector. This is not the case.
The proposed fix can be made an optional parameter of course.
Environment
angular 17
Reproducer
https://stackblitz.com/edit/7qkchf-9jk9cd
Angular version
17
PrimeNG version
master
Build / Runtime
Angular CLI App
Language
TypeScript
Node version (for AoT issues node --version)
18
Browser(s)
No response
Steps to reproduce the behavior
Click on select a product Observe null injector error on console.
Expected behavior
No response
+1 for this. Not being able to propagate instances is such a headache. Angular Material has this ability with their viewContainerRef:
Where the attached component should live in Angular's logical component tree. This affects what is available for injection and the change detection order for the component instantiated inside of the dialog. This does not affect where the dialog content will be rendered.
We're in a similar situation where we are providing the DialogService at the root level, but stores/services at a feature level. I.E, scoping things appropriately. The current functionality of dynamic dialog doesn't make this easy, at all, due to the issues mentioned in the OP.
Sad to see that this hasn't had any response. Can we have some thoughts on this one, @cetincakiroglu? Much appreciated.
