feat(project): modularization docs

docs/modularization.md

@@ -0,0 +1,82 @@
+# Architecture
+
+In order to implement a more structural approach of organizing the code and to reduce coupling we decided to add Dependency Injection (DI) and Inversion of Control (IOC) patterns support for services and controllers present in the application. We expect these patterns to be even more effective when working with different OTT platforms where JS code can be reused.
+
+## DI library
+
+InversifyJS is used to provide IOC container and to perform DI for both services and controllers. Injection happens automatically with the help of the reflect-metadata package (by adding `injectable` decorators to the necessary services / controllers).
+
+> **Important:** The type of the service / controller defined in the constructor should be used as a value, without the `type` keyword.
+
+Won't work:
+
+```
+import type {CleengService} from './cleeng.service';
+
+@injectable()
+export default class CleengAccountService extends AccountService {
+  private readonly cleengService: CleengService;
+
+  constructor(cleengService: CleengService) {
+    ...
+  }
+}
+```
+
+Will work:
+
+```
+import CleengService from './cleeng.service';
+
+@injectable()
+export default class CleengAccountService extends AccountService {
+  private readonly cleengService: CleengService;
+
+  constructor(cleengService: CleengService) {
+    ...
+  }
+}
+```
+
+This is the price we need to pay to remove `inject` decorators from the constructor to avoid boilerplate code.
+
+## Initialization
+
+We use [register](src/modules/register.ts) function to initialize services and controllers. Some services don't depend on any integration provider (like `ConfigService` or `EpgService`), while such services as `CleengAccountService` or `InplayerAccountService` depend on the provider and get injected into controllers conditionally based on the `INTEGRATION_TYPE` dynamic value (`JWP` or `CLEENG`).
+
+Initialization starts in the [index.tsx](src/index.tsx) file where we register services. We do it outside of the react component to make services available in different parts of the application.
+
+The app is loaded in the [useBootstrapApp](src/hooks/useBootstrapApp.ts) hook with the help of the `AppController` which is responsible for retrieving data from the Config and Settings services, initializing the initial state of the application and hitting init methods of the base app's controllers.
+
+## Controllers and Services
+
+### Services
+
+Controllers and Services can both be used to provide services (objects) that can be injectable into parts of the application.
+
+Services - domain related entities. Business should be mostly stored there. We use services to communicate with the back-end, to process the data we receive. Services help to manage different dependencies.
+
+For example, we can use them to support several streaming schedule providers or integration providers. If this is the case we should also create a common interface and make dependant entities use the interface instead of the actual implementation. This is how inversion of control principle can be respected. Then when we inject services into controllers we use interfaces types instead of the implementation classes.
+
+- They contain the actual business logic to perform the use case;
+- They can be injected into controllers which orchestrate different services or into other services;
+- We should avoid using services in the View part of the application and prefer controllers instead. However, it is still possible to do in case controllers fully duplicate service's methods. In this case we can use a hook and get access to the service there.
+- One service can use different implementation. For example, we can split it into Cleeng and JWP implementation (account, checkout and so on).
+
+### Controllers
+
+Controllers - binding different parts of the application. Controllers use services, store and provide methods to operate with business logic in the UI and in the App. If we need to share code across controllers then it is better to promote the code to the next level (AppController). Then it is possible to modify both controllers to call the same (now shared) code.
+
+- They can be called from the View part of the application;
+- They can use a Store to find the necessary data;
+- They use the data from the Store and from the UI to operate different injected services;
+- They use a Store to persist the entities again;
+- They return data back to the UI if needed.
+
+> **Important:** We should try to avoid controllers calling each other because it leads to circular dependencies and makes the code messy. However now they do it sometimes.
+
+### Controllers / Services retrieval
+
+To get access to the service / controller [getModule](src/modules/container.ts) utility can be used. It also accepts and optional `required` param which can be used in case the presence of the service is optional. If `required` is provided but service itself is not bound then the error will be thrown.
+
+`getNamedModule` function is mostly use in controllers to retrieve integration-specific services, like AccountService or CheckoutService.

src/modules/register.ts

@@ -52,7 +52,7 @@ container.bind(AppController).toSelf();
 container.bind(WatchHistoryController).toSelf();
 container.bind(FavoritesController).toSelf();
 
-// Integration controllers (conditionally register?)
+// Integration controllers
 container.bind(AccountController).toSelf();
 container.bind(CheckoutController).toSelf();
 container.bind(ProfileController).toSelf();