Question: Tight coupling with Navigation
Opened this issue · 4 comments
Hey! Thanks for an amazing library, you did a tremendous job!
IMO Nivelir has one of the most well-designed APIs I've come across as an Apple platforms developer, especially given the amount of complexities it hides. Abstractions are well-thought and on-point. 🤌
I am considering to use Nivelir for my next project, because I found myself solving the same problems when doing the complex global routing, but one thing I am concerned about is tight coupling between ViewControllers/Views and Navigation by invoking navigation actions directly from ViewControllers/Views. Basically the problem that Coordinator pattern is intended to solve.
I do understand that this library is not opinionated about where to invoke navigation actions (which it makes it even more cool) and it can perfectly be abstracted and delegated away to Coordinator or other assisting entities.
The question is – what is your take on it? How are you dealing with your Presentation Layer (VC/View) "knowing too much" about Navigation? Or you simply don't focus on it and it works fine for you and you don't overstretch with abstractions here by introducing something like Coordinators?
Thanks!
Hello 👋
Thank you very much for your feedback. We are very glad that you liked Nivelir.
Regarding the issue of using Nivelir directly from ViewController, we do this only in simple modules of the demo project.
In our real project, we allocate a separate Router entity for each module, in which all navigation actions are performed.
There are no restrictions for using Nivelir with the Coordinator pattern, on the contrary, it will help you get rid of a lot of boilerplate code.
In our project, we do not use the Coordinator template, but we have "Logic" modules that can resemble them.
The difference between these approaches is that Logic modules do not own the container (UIViewController or UIWindow),
but receive it from the outside from regular (MVC, MVVM ) or other logic modules.
Also logic modules have no hierarchy and control only a small part of ephemeral navigation (for example, a sequence of authorization steps).
This allows us to decompose large Flows into small reusable stages.
Thanks!
Thanks for your thorough answer! It makes total sense. I now have even more questions😅
I hope that you don't mind me asking them.
Would you be able to provide simplified version of your "Logic" modules/Router entities?
I am especially curious about how you do the container passing between logic modules and how you wire all of these together.
Another big question is who creates/initiates – who creates screens, who creates logic modules/routers, how ViewController talk to these additional navigation entities?
We will try to prepare for you a mini-project that is similar in structure to ours 👌
Thanks man!! You really don't have to do that, you are too kind🙏