GoPay is built in Monorepo. We focus on our North Star: Productivity and Robust. Separate folders / pods by team-led ownerships: - GoPay consumer Flutter app - Shared packages - Pod-owned folder - Pod-owned feature package Early days: Agree on conventions, architectures (e.g. state management) Melos to orchestrate. Fvm to standardize. GoPay Flutter App Shared infrastructures: - routes package - networking package - analytics package etc etc Pod A feature A package feature B package ... Pod B feature A package feature B package ... Pod C feature A package feature B package ...
a lot of code convention standards are set in the community. E.g. with Redux, you will always have 1 store and a root reducer in your main app. For each feature, 1 reducer and action. What about Flutter? BLOC vs Cubit vs Providers? Reusing blocs? Listeners? Scalable Code Conventions Redux official docs.
translates business logic into rendered UI. It parses data from Cubits, processes it, and controls the rendered UI. The goal here is to ensure the UI does not concern about logics, adhering to separation of concerns.
party dependencies (e.g. Service Locators), do not concern the rendering context, and are driven by constructor props. Their only concern should be to render what’s given from the View above. A button widget should not implement any external services, should not care where it is rendered, and should behave only according to the given props. 3. Widgets - Pure UI components