Should Rinf be mixed with Bloc or Riverpod? #669
-
|
I love the project, but as I progressed, I became curious about this, because Rinf should be used to handle business logic. In my case, I tried it to manage the theme, colors, and language of the app. Although it works, I feel that not knowing in code when it arrives or guaranteeing that it is loaded before loading the first frame of the application made me wonder if it would be better to use a state manager like bloc for these tasks, since it is the most similar (thanks to rinf, I understood bloc and I like both projects better) and I would have easy access to the theme types. In my app, I need rust because it is the easiest way to communicate with a specific dbus of a service in Linux. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
Great question! Rinf is specifically for Rust-Dart interop—exposing Rust functions to Dart. For app state (theme, language, etc.), it's better to use a dedicated state manager like Bloc or Riverpod. Those tools give you predictable lifecycle, dependency injection, and rebuilds. Mixing Rinf for app state works but you lose the ecosystem and type safety that Bloc/Riverpod provide. The typical pattern: Rinf handles DBus calls and heavy computations; Bloc/Riverpod manages UI state and configuration. They can coexist nicely—just keep responsibilities separate. |
Beta Was this translation helpful? Give feedback.
Great question! Rinf is specifically for Rust-Dart interop—exposing Rust functions to Dart. For app state (theme, language, etc.), it's better to use a dedicated state manager like Bloc or Riverpod. Those tools give you predictable lifecycle, dependency injection, and rebuilds. Mixing Rinf for app state works but you lose the ecosystem and type safety that Bloc/Riverpod provide. The typical pattern: Rinf handles DBus calls and heavy computations; Bloc/Riverpod manages UI state and configuration. They can coexist nicely—just keep responsibilities separate.