Reactive Architecture
The philosophy behind Fluxy's reactivity and state management.
Reactive Architecture
The core philosophy of Fluxy is to minimize re-renders and make data flow explicit.
The Reactive Graph
Fluxy uses a Signal Graph to track dependencies. Every Signal, Computed, and Effect is a node in this graph.
This is different from traditional setState() which rebuilds entire widget subtrees.
When a Signal updates, it notifies only its direct dependents. If a Computed value depends on that signal, it recalculates. If an Effect uses that signal, it re-runs. This ensures that only the necessary parts of your UI update.
Single Engine Philosophy
Instead of relying on multiple disjointed state management solutions, navigation libraries, and theme extensions, everything in Fluxy is unified under a single Engine instance. This engine coordinates:
- State Updates: Automatic batching and dependency tracking.
- Routing: Managing the navigation stack and history.
- Theming: Applying global styles and responsive breakpoints.
- OTA Updates: Handling remote manifest downloads and hot-swaps.
This unification reduces complexity and ensures that all parts of your application work together seamlessly.
Performance First
Performance is built-in, not an afterthought.
- Fine-Grained Updates: Only change the specific text node or style property that needs to update.
- Lazy Evaluation:
Computedvalues are only calculated when accessed. - Zero Overhead: While the developer experience is rich, the runtime cost is minimal.
Flat Widget Tree (Attribute Accumulation)
Fluxy v0.1.6 optimizes UI performance through a Flat Widget Tree. Unlike traditional modifier-based frameworks that wrap widgets in nested layers (Padding > DecoratedBox > Opacity), Fluxy uses an Attribute Accumulation pattern.
When you chain modifiers:
Fx.box()
.p(16)
.bg(Colors.blue)
.rounded(12)
.shadow.lgThe engine accumulates these attributes into a single internal style object. This results in far fewer widgets in the element tree, leading to better memory usage and faster layout passes.
Structural Recursion (ParentData Preservation)
Fluxy's engine is designed to be "layout aware." It uses Structural Recursion to correctly handle Flutter's ParentData requirements.
If you apply modifiers to widgets like Expanded, Flexible, or Positioned, Fluxy "peers through" these wrappers to apply styles to the inner child without breaking the communication between the layout widget and its parent (like a Row or Stack). This eliminates the common "Incorrect use of ParentDataWidget" errors.