After restructuring my angular app from a monolithic shared feature module to smaller ones, I faced a challenge with what appears to be a cyclic dependency. The issue arises when I have components such as triggerA
, modalA
, triggerB
, and modalB
interacting in a loop of imports across modules.
The design may seem flawed at first glance, but let me explain the practical scenario:
Imagine a modal displaying details about an event, including information about its participants. From this modal, I should be able to access a participant's profile. However, within that same modal, there is also a list of all events involving that participant, creating a chain of dependencies. This structure allowed for component reuse and adhered to the DRY principle, but keeping all components in one module felt unorganized.
A runnable example can be found here.
The setup functions properly until comments are removed on line 12 in trigger-a.module.ts
, causing a recursive dependency error. Is it possible to maintain the module import to avoid schema errors?
This situation raises some questions:
- Why does importing the modal module alone work without listing it in the
imports
section of the trigger module? - If both modals are imported in the main
apps.module
, breaking the cycle becomes feasible by excluding one modal from the triggers import - but is this the recommended solution?
What would be the best approach to resolve this issue? Omitting the module import seems like a temporary fix, while directly importing modules with cross-dependencies in the apps module contradicts the concept of modularization. It feels unconventional, yet necessary to achieve functionality.
Although uncertain about the correctness of my method, I believe the use-case remains valid. Any insights or suggestions on how to improve this design would be greatly appreciated.