Hi, If I have a service A that needs service B and viceversa, would be better if I use forwardRef in both services and modules, or create a service C importing the other both services?
#circular dependency architecture
narrow glacier
rugged zodiac
Avoid the forwardRef whenever possible
I got a project with few of them. Sometimes I face circular deps errors that are hard to understand because of that. Sometimes even the position of the import line matters. So yeah, avoid it lol
tall tendon
This is the most recent discussion i could find on forwardRefs. Why are they considered a bad idea, avoid wherever possible, etc?
I have an app with 67 modules, and I'm using forwardRefs all over the place... most service classes are using them. For example, I have a CustomerService that might need to get Order details, so it has a forwardRef to OrderService, and OrderService might need to get Customer details, so there I have a forwardRef back to CustomerService.
What's a better solution?
tall tendon
Thank you @rugged zodiac -- this was very well written.
In the rare possibility that the above link is changed/removed/down in the future... for future me, and for others.. and with full credit to the author "Jay McDoniel", I'm leaving an unofficial copy here:
Why to Avoid Circular Dependencies
Okay, okay, we've talked about what they are, and how to find them, but let's talk about why they should be avoided:
Circular dependencies are usually a code smell that code is too tightly coupled together. This often happens when we get too caught up in DRYing the code and not remembering that WET (write everything twice) code is okay. Tightly coupled code is also often a lack of foresight and planning for the modules and features being created. Remember that usually a module should be able to be picked up from it's current application, dropped in another NestJS application, and be able to function as is.* with the possible exception of having to fix up database connections/tables.
(cont'd)