Reviving #14491 - Can't inject environmentInjector into dialog opened by DialogService

[axos88]

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

[rd-waymark]

+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.

[abhijit-chikane]

I have provided the dependencies on the route level
and moving the dialogService to this provider doesn't solve this issue
so above mention workaround is not working for me
is there any other workaround for this scenario?

[mertsincan]

Hi,

So sorry for the delayed response! Improvements have been made to many components recently, both in terms of performance and enhancement. Therefore, this improvement may have been developed in another issue ticket without realizing it. You can check this in the documentation and try the latest PrimeNG version(v19). If there is no improvement on this, can you open a new issue so we can include it in our roadmap?

Thanks a lot for your understanding!
Best Regards,