From Plug-and-Play to Fully Custom
summary
A reusable Flutter SDK is refactored into five override layers (facade, theme/UI factory, DI, parts, scopes) that let apps swap implementations without forking; DI uses either service locator or inherited widget (get_it or Provider) so repositories can be global or context-scoped; a demo UserCard SDK shows auto-namespaced parts (avatar, container) replaced by ID, ValueListenableBuilder for state, and scope IDs that produce distinct instances — examples and a GitLab gist exist and run.
AI-written summary · about
chapters (12)
- 0:00Flexible feature development
- 3:37Five levels of customization
- 7:09Facade pattern for APIs
- 9:00Theme extensions and UI factories
- 11:09Dependency injection strategies
- 13:17Merge config for settings
- 15:07Contextual override system
- 17:15Parts system for nesting
- 20:08Scoped features for customization
- 25:18Summary of approaches
- 27:47Examples and implementation
- 33:54Q&A
related talks
13mBuilding platform adaptive apps
29mSimplify app development by building widgets in isolation
34mModular Flutter App Architecture Answering the What, When and How
40mArchitecture: The LeanCode Guide
46mHow to Cook Flutter Properly
34mBuild reactive mobile apps with Flutter
45mBuilding Products Full-Stack with Dart and Flutter
37mPragmatic crafting
