Based on repository activity, growth velocity and community engagement.
29
Growth6/30
Activity1/25
Popularity12/25
Trust11/20
655
Stars
High
Sentiment
Votes
655
README.md
Flutter Clean Architecture with Riverpod
A Flutter app that uses the "Dummy Json" api.
Features
Login
Fetch products
Search products
Pagination
What is used in this project?
Riverpod
Used for state management
Freezed
Code generation
Dartz
Functional Programming Either<Left,Right>
Auto Route
Navigation package that uses code generation to simplify route setup
Dio
Http client for dart. Supports interceptors and global configurations
Shared Preferences
Persistent storage for simple data
Flutter and Dart
And obviously flutter and dart š
Project Description
Data
The data layer is the outermost layer of the application and is responsible for communicating with the server-side or a local database and data management logic. It also contains repository implementations.
a. Data Source
Describes the process of acquiring and updating the data.
Consist of remote and local Data Sources. Remote Data Source will perform HTTP requests on the API. At the same time, local Data sources will cache or persist data.
b. Repository
The bridge between the Data layer and the Domain layer.
Actual implementations of the repositories in the Domain layer. Repositories are responsible for coordinating data from the different Data Sources.
Domain
The domain layer is responsible for all the business logic. It is written purely in Dart without flutter elements because the domain should only be concerned with the business logic of the application, not with the implementation details.
a. Providers
Describes the logic processing required for the application.
Communicates directly with the repositories.
b. Repositories
Abstract classes that define the expected functionality of outer layers.
Presentation
The presentation layer is the most framework-dependent layer. It is responsible for all the UI and handling the events in the UI. It does not contain any business logic.
a. Widget (Screens/Views)
Widgets notify the events and listen to the states emitted from the StateNotifierProvider.
b. Providers
Describes the logic processing required for the presentation.
Communicates directly with the Providers from the domain layer.
Project Description
main.dart file has services initialization code and wraps the root MyApp with a ProviderScope
main/app.dart has the root MaterialApp and initializes AppRouter to handle the route throughout the application.
services abstract app-level services with their implementations.
The shared folder contains code shared across features
theme contains general styles (colors, themes & text styles)
model contains all the Data models needed in the application.
http is implemented with Dio.
storage is implemented with SharedPreferences.
Service locator pattern and Riverpod are used to abstract services when used in other layers.
The features folder: the repository pattern is used to decouple logic required to access data sources from the domain layer. For example, the DashboardRepository abstracts and centralizes the various functionality required to fetch the Product from the remote.
abstract class DashboardRepository {
Future<Either<AppException, PaginatedResponse>> fetchProducts({required int skip});
Future<Either<AppException, PaginatedResponse>> searchProducts({required int skip, required String query});
}
The repository implementation with the DashboardDatasource:
class DashboardRepositoryImpl extends DashboardRepository {
final DashboardDatasource dashboardDatasource;
DashboardRepositoryImpl(this.dashboardDatasource);
@override
Future<Either<AppException, PaginatedResponse>> fetchProducts(
{required int skip}) {
return dashboardDatasource.fetchPaginatedProducts(skip: skip);
}
@override
Future<Either<AppException, PaginatedResponse>> searchProducts(
{required int skip, required String query}) {
return dashboardDatasource.searchPaginatedProducts(
skip: skip, query: query);
}
}
Using Riverpod Provider to access this implementation:
final dashboardRepositoryProvider = Provider<DashboardRepository>((ref) {
final datasource = ref.watch(dashboardDatasourceProvider(networkService));
return DashboardRepositoryImpl(datasource);
});
And finally accessing the repository implementation from the Presentation layer using a Riverpod StateNotifierProvider:
final dashboardNotifierProvider =
StateNotifierProvider<DashboardNotifier, DashboardState>((ref) {
final repository = ref.watch(dashboardRepositoryProvider);
return DashboardNotifier(repository)..fetchProducts();
});
Notice how the abstract NetworkService is accessed from the repository implementation and then the abstract DashboardRepository is accessed from the DashboardNotifier and how each of these layers acheive separation and scalability by providing the ability to switch implementation and make changes and/or test each layer seaparately.
Testing
The test folder mirrors the lib folder in addition to some test utilities.
