Aus öffentlichen Paketdaten erstellte Orientierung.
Eine Codegenerierungsbibliothek für den Brick Offline-First-Domain, die mit GraphQL integriert ist und eine nahtlose Daten-Synchronisierung zwischen lokaler Speicherung und Remote-APIs ermöglicht. Sie generiert Dart-Modelle und Repository-Logik basierend auf GraphQL-Schemata und vereinfacht die Entwicklung von Apps mit Fokus auf Offline-First. Das Paket unterstützt mehrere Plattformen und beschleunigt die Erstellung sicherer, wartbarer Datenebenen. Durch die Nutzung der Codegenerierung wird Boilerplate reduziert und die Produktivität der Entwickler gesteigert.
Anwendungsfälle
Offline-first-Mobile-Anwendungen erstellen
Synchronisieren von Daten zwischen lokalen und remote GraphQL-Endpunkten
Automatisierung der Modell- und Repository-Erstellung
Erstellen sicherer Datenzugriffsschichten mit Typsicherheit
Echtzeit-Datenaktualisierungen in Apps aktivieren
Reduzierung manueller Boilerplate bei der Implementierung der Datenebene
Hauptmerkmale
Generiert Dart-Klassen aus GraphQL-Schemata
Unterstützt Offline-first-Datenpersistenz
Integriert sich in die Domain-Architektur von Brick
Erzeugt Repository-Implementierungen
Stellt Typsicherheit bei Datenoperationen sicher
Ermöglicht die automatische Synchronisierung zwischen lokalen und remote-Daten
Geeignet für
Entwickler, die Brick für Offline-zuerst-Anwendungen verwenden
Teams, die mobile Apps mit GraphQL erstellen
Projekte, die eine robuste lokale Datenverarbeitung erfordern
Apps, die eine automatische Daten-Synchronisierung benötigen
Dart-Entwickler, die Codegenerierungswerkzeuge suchen
Projekte, die eine wartbare Datenlagendesign priorisieren
Hinweise
Erfahrung mit Brick und GraphQL erforderlich
Erforderliche korrekte Schema-Definition für die Codegenerierung
Kann die Build-Zeit aufgrund der Codegenerierung erhöhen
Abhängig von externer Tooling für die Schema-Verwaltung
Am besten geeignet für größere Projekte mit komplexen Datenanforderungen
Eingeschränkte Dokumentation im Vergleich zu Mainstream-Paketen
Original-README
Originaler README-Schnappschuss aus dem verknüpften Quell-Repository. Aktuelle Inhalte finden Sie im Repository.
An intuitive way to work with persistent data in Dart.
Brick is an extensible query interface for Dart applications. It's an all-in-one solution responsible for representing business data in the application, regardless of where your data comes from. Using Brick, developers can focus on implementing the application, without concern for where the data lives. Brick was inspired by the need for applications to work offline first, even if an API represents your source of truth.
Quick Start
Add the packages:
dependencies:# Or brick_offline_first_with_graphql# Or brick_offline_first_with_supabasebrick_offline_first_with_rest:sqflite:# optionaldev_dependencies:# Or brick_offline_first_with_graphql_build: any# Or brick_offline_first_with_supabase_build: anybrick_offline_first_with_rest_build:build_runner:
Configure your app directory structure to match Brick's expectations:
mkdir -p lib/brick/adapters lib/brick/db;
Add models that contain your app logic. Models must be saved with the .model.dart suffix (i.e. lib/brick/models/person.model.dart).
Run dart run build_runner build to generate your models and sometimes migrations. Rerun after every new model change or dart run build_runner watch for automatic generations. You'll need to run this again after your first migration.
And generate (de)serializing code to fetch to and from multiple providers:
$ (flutter) pub run build_runner build
Fetching Data
A repository fetches and returns data across multiple providers. It's the single access point for data in your app:
classMyRepositoryextendsOfflineFirstWithRestRepository{
MyRepository();
}
final repository = MyRepository();
// Now the models can be queried:final users = await repository.get<User>();
Behind the scenes, this repository could poll a memory cache, then SQLite, then a REST API. The repository intelligently determines how and when to use each of the providers to return the fastest, most reliable data.
// Queries can be general:final query = Query(where: [Where('lastName').contains('Muster')]);
final users = await repository.get<User>(query: query);
// Or singular:final query = Query.where('email', 'user@example.com', limit1: true);
final user = await repository.get<User>(query: query);
Queries can also receive reactive updates. The subscribed stream receives all models from its query whenever the local copy is updated (e.g. when the data is hydrated in another part of the app):
final users = repository.subscribe<User>().listen((users) {})
Mutating Data
Once a model has been created, it's sent to the repository and back out to each provider:
final user = User();
await repository.upsert<User>(user);
Associating Data
Repositories can support associations and automatic (de)serialization of child models.
classHatextendsOfflineFirstWithRestModel{
finalString color;
Hat({this.color});
}
classUserextendsOfflineFirstWithRestModel{
// user has many hatsfinalList<Hat> hats;
}
final query = Query.where('hats', Where('color').isExactly('brown'));
final usersWithBrownHats = repository.get<User>(query: query);