hadilq/rust-flutter-reactive

This system is a cross-platform application framework that manages state using a Redux-style unidirectional data flow. It exposes a thread-safe entry point for dispatching actions and subscribing to state updates, while utilizing FlatBuffers for code generation between Rust and Dart. The architecture separates domain logic and presentation concerns into distinct crates, supported by a Nix-based build environment for Rust and mobile platforms.

The project now includes a Nix development environment (shell.nix) that automatically provisions Rust, Android SDK/NDK, and other build dependencies, allowing developers to enter a pre-configured shell for building shared libraries. Additionally, the build configuration was updated to produce cdylib (dynamic) shared libraries instead of rlib (static) libraries for non-Apple platforms, facilitating direct linking with the Flutter bridge.

(repo-wide) · high confidence

The application now uses a unidirectional data flow pattern with a central store that manages state and dispatches actions through reducers. This introduces a new \Application\ trait and \App\ struct that wrap a \Store\ to handle state updates and subscriptions. The \RootReducer\ and specific page/user reducers define how state changes in response to actions like button clicks or user name changes. This change replaces the previous, unspecified application logic with a structured, testable state management system.

(repo-wide) · high confidence

The domain's implementation code has been moved from the root domain crate to a new 'domain/implement' crate, while the corresponding interface (the Successor trait) has been moved to a new 'domain/interface' crate. This change separates the domain's internal implementation from its public contracts, with the implementation now depending on the interface crate.

domain/implement, domain/interface · medium confidence

The build script now dynamically calculates the absolute paths for the FlatBuffers schema files (actions.fbs and states.fbs) and their respective output directories for Rust and Dart code generation. Previously, these paths were hardcoded relative to the build script's location, which could be fragile or incorrect depending on the build environment. The new logic traverses up the directory tree to find the 'target' directory, then derives the correct root, schema, and output paths. This ensures that the code generation step correctly locates the .fbs files and writes the generated Rust and Dart models to the intended locations, regardless of where the build is triggered from.

state-action · medium confidence

The application now exposes a thread-safe entry point via \ThreadSafeApp\, which provides methods to dispatch actions, subscribe to state updates, and receive log messages. Internally, a global static \APP\ instance is created using a dependency injection pattern, wiring together the root, main page, and user reducers. This change consolidates the application's core logic and state management into a single, accessible interface for the rest of the system.

root · medium confidence

The bridge-ffi module has been reorganized: the \app\ module has been renamed to \adapter\, moving \action\_adapter.rs\ and \state\_adapter.rs\ into a new \adapter\ directory. The \test\ module has been removed from \bridge-ffi/src/test/mod.rs\ and its tests have been moved into \bridge-ffi/src/adapter/state\_adapter.rs\ as a \\#\[cfg(test)\]\ module. The \lib.rs\ entry points have been updated to reflect these changes, including renaming \state()\ to \dispatch\_state()\ and updating imports to use \presentation\_interface\ instead of \presentation\ for action and state types. The \ThreadSafeApp\ is now used instead of \App\ for handling actions and state updates.

bridge-ffi · medium confidence

The \application\ crate's \app\ module, which previously managed the global \App\ state and dispatched actions via a Redux-like store, has been deleted. This removal includes the associated unit tests that verified button click actions and state updates, indicating a significant architectural shift away from this specific implementation.

application · high confidence

The presentation module's internal structure has been removed, including all files related to state management, action definitions, and reducer logic. This eliminates the previous implementation of the presentation layer's state machine, meaning the application no longer manages UI state (such as user name and page type) through these specific Rust modules.

presentation · high confidence

The Rust workspace has been restructured to separate interface and implementation crates for the application, domain, and presentation layers, with corresponding updates to each crate's Cargo.toml. The root package was renamed from 'application' to 'root', and the workspace members were updated to reflect the new directory structure. Additionally, the 'flatbuffers' dependency was upgraded from version 0.6.1 to 2.0.0 across multiple crates, and the Rust edition was updated from 2018 to 2021 in several packages.

(dependencies) · medium confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 59 → 58 (-0.7)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 100 (+0.0)
• Architecture 100 → 95 (-4.7)
• Maturity 80 → 80 (+0.0)
• Readiness 22 → 22 (+0.0)
• Security 100 → 100 (+0.0)
• Domain Modelling 100 → 100 (+0.0)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• No exposed public API
• Test reliability not included
• early-stage repository — too little history to judge knowledge freshness
• git history depth insufficient
• git history depth insufficient
• single-maintainer — knowledge-concentration (bus factor) risk

• Dependency hygiene PARTLY measured — Maven/Gradle declarations read, no dependency graph resolved
• Documentation: no contributor guidance (README.md)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Semantic overlap: Both methods accept a RootAction and trigger state updates, but use different verbs ('dispatch' vs 'act'). 'Act' is ambiguous compared to the standard Redux-like 'dispatch'.
• Semantic overlap: Both methods appear to trigger the immediate processing or flushing of pending subscriptions/state updates. The naming is inconsistent ('dispatch_subscriptions' vs 'dispatch_current_state') and unclear about what is actually being dispatched.
• Semantic overlap: Both methods register a callback for logging events. Similar to above, 'subscribe_for_logger' is verbose while 'logger' is ambiguous (is it a getter or a setter?).
• Semantic overlap: Both methods register a callback for state change notifications. 'subscribe_for_updates' is verbose while 'updates' is a noun used as a verb, creating inconsistency in naming style and clarity.

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

hadilq/rust-flutter-reactive was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.