Aman-Mittal opened a new issue, #168: URL: https://github.com/apache/fineract-consumer-facing/issues/168
In the Angular client, stores, core services and some components inject the generated `@bff/client` services and Ionic's `ToastController` directly. Each call site also repeats transport details: the `X-Device-Fingerprint` argument, the loan `withdraw` command segment, and defaults for absent paging fields. A change in what the generator emits therefore lands on every one of those files. The only thing keeping components off the generated client is a convention in `state-management.adoc`; nothing enforces it. apache/fineract-backoffice-ui solved the same problem with an adapter boundary (its ADR 0003 and ADR 0006): - ports in `core/adapters`, each an interface plus an `InjectionToken` with a default implementation; - adapters that are the only code importing the generated client or Ionic's controllers; - an ESLint rule that holds the boundary, with specs that mock the contract. **Proposal:** adopt the same structure here, so the two Angular clients are organized alike: - **Ports and adapters:** one port per BFF domain (`<domain>.api.ts`, with a `bff-<domain>.api.ts` adapter), plus an `OVERLAY` adapter for toasts. - **Enforcement:** a local `no-generated-api-import` ESLint rule, and `no-restricted-imports` for Ionic's controllers. - **Migration:** move every existing call site and spec over, so the boundary starts with no exceptions. - **Constraint:** no behavioural change. Requests, responses and toasts stay exactly as they are. Wrapping ngx-translate in an `I18N` adapter, as the back-office UI also does, is left as a follow-up because it touches every template. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
