Hi all. I’m trying to build a ModalPage to create a Contact. This Contact has a List of related Contacts wich can be created from inside the Modal. As soon as I try to Open the Modal from inside the Modal I get a “Circular dependency detected”. Does anyone know how I can prevent this?
Do you have an example already built out? It can help us figure out what the issue is
I created one. It can be found here.
It produces the following WARNING:
[ng] WARNING in Circular dependency detected:
[ng] src\app\modal-relation\modal-relation.page.ts -> src\app\modal\modal.page.ts -> src\app\modal-relation\modal-relation.page.ts
[ng] WARNING in Circular dependency detected:
[ng] src\app\modal\modal.page.ts -> src\app\modal-relation\modal-relation.page.ts -> src\app\modal\modal.page.ts
The only instance of “modal” I see in that repo are in string constants. Are you sure everything is included?
You’re right. Somehow one commit was missing. Now everthing should be there.
I was hoping to see a real-world use case, because I’m having a really hard time envisioning a situation where this would happen. Modals are supposed to be only for situations where the user’s ordinary workflow must be disrupted in order to take immediate action, after which they should be able to resume what they were previously doing. So I would consider any modal nesting a fairly large red flag indicating that the UI design may be a bit infected with rabbit holes.
That being said, you could look into using forwardRef to break the cycle.
The real-world use case in my case is a list of contacts. I’m using a modal to let the user edit those contacts. Now each contact can have a number of related contacts which can be added/removed to a list in this modal. To add a contact to this list I first present a modal where the user can search for an existing contact. In case no contact is found I want the user to be able to create a new contact and add it to the list. Therefore I open another contact modal.
So in my opinion this is indeed a case where the users ordinary workflow must be disrupted and resumed afterwards.
What would be an alternative way (the better way) to implement such a scenario?
Hmm, not 100% the best way to move forward here.
I would just try to find a way to not have this all together. While technically things will work and the warning is just a warning, might be good to either rethink the UI as proper pages, or limited the modals to only one level deep
1 Like
So you are saying that it is generally a bad practice to nest modals and everything that is more than one level deep should be implemented as pages? Right?
In that case I guess I should switch to pages. The thing I dislike about pages is that it is much harder to make them reusable in different locations in my app. Or maybe I just didn’t find the correct way to do it yet.
Not that’s bad practices to nest things, just doing so in a circular way could be problematic.
Might it be possible to think of components as the building block that gets reused in different places, and pages more as structural hosts for these components? I would much prefer a heavy component / light page structure than a snarl of nested modals, and that should also melt away your circular reference problem.
Yes. That might actually be a good solution which is worth looking into. Thanks