-
Notifications
You must be signed in to change notification settings - Fork 720
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modular Architecture Support #34
Comments
Hey @faris-mobile89 If you need to access the AppState from the UI layer - you use @Environment injection of DI container, which carries the reference to the AppState. The business logic layer has access to the AppState by design - AppState is injected as part of the module initialization. The same applies to the Data layer - you can inject App State as needed. You can check out this part in the code where AppState is supplied to all the modules that need access to it. I hope this answers your question. |
The question is different, let me explain more. to scale the project for multiple teams we need multiple targets & frameworks. we will breakdown the features as frameworks using Cocoapods or Carthage. Hence, the classes and protocols will be abstract and private for other frameworks. Let's say we want to break down this demo to Modular architecture, The AppState and main dependency container will be embedded inside the core framework. the problem here is how the other frameworks can read the App State and how they can change the app state. the attached diagram shows the Modular Architecture. This demo seems good for small projects, but for a large scale project, many problems will come up and needs to be solved. |
This is hard to advise having just this diagram on hands. In my experience, when we had to break down the project into frameworks, it'd grow horizontally, not vertically. I understand each of the layers you have will be growing horizontally too, although I don't understand the motivation of having that many vertical layers. The core frameworks should not change too often, otherwise, you'd need to keep recompiling them and possibly other layers too often. And the AppState, as it comes from Redux, is designed to contain all the state from the app, thus it'll be changing all the time. Redux's approach may not be the best choice in your case, or at least you'd need to split the AppState into several containers that would reside in different layers in your architecture. This would make the team's work more independent. |
I like the architecture. But I'm wondering how we can share the App State through other modules and how other modules can change that state. If you have some thoughts on this please advise.
The text was updated successfully, but these errors were encountered: