June ist eine leichte und moderne Zustandsverwaltungsbibliothek, die sich darauf konzentriert, ein Muster bereitzustellen, das dem nativen Zustandsverwaltungsmuster von Flutter sehr ähnlich ist.
Aus öffentlichen Paketdaten erstellte Orientierung.
June ist eine leichte, moderne State-Management-Bibliothek für Flutter, die die nativen Zustandsverwaltungs-Muster von Flutter nachahmt. Sie legt Wert auf Einfachheit und Lesbarkeit, wodurch das Verwalten von Zuständen reaktiv und ohne Boilerplate möglich wird. Mit dem Entwicklererlebnis im Fokus entworfen, integriert sich June nahtlos in bestehende Flutter-Projekte und unterstützt alle wichtigen Plattformen. Ihre API ist intuitiv und fördert saubere Code-Strukturen sowie effiziente Updates. June ist ideal für Entwickler, die eine minimale, aber leistungsstarke Alternative zu komplexeren Zustandslösungen suchen.
Anwendungsfälle
Einfache App-Zustandsverwaltung
Reaktive UI-Updates
Plattformübergreifende Flutter-Anwendungen
Leichte Zustandslösung
Einfache Integration in bestehende Codebasen
Hauptmerkmale
Minimales Boilerplate
Flutter-native-Muster-Ausrichtung
Reaktive Zustandsupdates
Platform-agnostic
Klare, lesbare API
Keine externen Abhängigkeiten
Geeignet für
Anfänger bis mittlere Flutter-Entwickler
Kleine bis mittelgroße Anwendungen
Projekte, die Einfachheit priorisieren
Teams, die eine schnelle Onboarding-Phase wünschen
Anwendungen für mehrere Plattformen
Hinweise
Eingeschränkte erweiterte Funktionen im Vergleich zu größeren Bibliotheken
Nicht ideal für sehr groß angelegte Zustandsanforderungen
Weniger Community-Support als etablierte Alternativen
Am besten geeignet für einfache Zustandsflüsse
Original-README
Originaler README-Schnappschuss aus dem verknüpften Quell-Repository. Aktuelle Inhalte finden Sie im Repository.
You learned Flutter. You learned setState. It clicked.
Then you added a library and suddenly you're learning a new framework inside your framework — providers, stores, atoms, streams, reducers.
June refuses to do that.
It gives you shared, reactive state that works exactly like Flutter's own state management — just without the widget tree dependency. That's it.
At a glance
Before June — state trapped in a widget
class_CounterStateextendsState<Counter> {
int count = 0; // 🔒 only this widget// can touch this@overrideWidgetbuild(BuildContext context) {
returnText('$count');
}
}
With June — state lives anywhere, rebuilds anything
classCounterVMextendsJuneState{
int count = 0; // ✅ any widget,// any file,
} // anywhere
Each widget holds its own isolated state. Navigating away and back creates a fresh instance — exactly what you want for forms, sliders, and single-use UI.
Theme toggle
JuneBuilder can wrap MaterialApp itself, rebuilding the entire app on state change.
JuneBuilder(
() => UserController(),
builder: (c) {
if (c.loading) returnconstCircularProgressIndicator();
if (c.user == null) returnconstText('No user loaded');
returnText('Hello, ${c.user!.name}');
},
)
Selective rebuilds with id
Trigger only specific JuneBuilder widgets inside a shared state, leaving others untouched.
classFeedStateextendsJuneState{
String header = 'Latest';
List<Post> posts = [];
voidupdateHeader(String value) {
header = value;
setState('header'); // only rebuilds builders with id: 'header'
}
voidrefreshPosts(List<Post> fresh) {
posts = fresh;
setState('posts'); // only rebuilds builders with id: 'posts'
}
}
// Rebuilds only when 'header' setState is calledJuneBuilder(
() => FeedState(),
id: 'header',
builder: (s) => Text(s.header),
)
// Rebuilds only when 'posts' setState is calledJuneBuilder(
() => FeedState(),
id: 'posts',
builder: (s) => PostList(posts: s.posts),
)
Core API
Symbol
Role
JuneState
Base class for all state objects. Extend it, add fields and methods, call setState() to rebuild.
JuneBuilder
Widget that subscribes to a JuneState and rebuilds when setState() fires.
June.getState()
Retrieves (or lazily creates) a global singleton of a state type. Thread-safe, no setup needed.
tag
Namespaces multiple global instances of the same type.
id
Enables partial rebuilds — only JuneBuilder widgets sharing the same id will rebuild.
global: false
Bypasses the global registry. The builder uses your provided instance directly.
tag vs id — when to use which
tag
id
Lives on
JuneBuilder & June.getState()
JuneBuilder & setState()
Purpose
Pick which stored instance to use
Pick which builders to rebuild
Use when
Same state type needed in multiple places independently
One shared state, but only some widgets should react to a given change
Migration
0.8.x → 1.0.0
The factory function is now passed as a closure rather than an evaluated instance:
// Before (0.8.x)June.getState(CounterVM());
// After (1.0.0+)June.getState(() => CounterVM());
Community
Questions, ideas, or just want to say hi?
Acknowledgements
June was shaped by the best ideas in the Flutter ecosystem. Gratitude to the teams and communities behind Provider, GetX, Bloc, and Riverpod, and to Svelte for proving that less really is more.