stateful rust best practice

[dikatok]

@fzyzcjy hey man, again thanks for the remarkable commitment on this toolkit, I want to ask about stateful rust, what is the best practice when user is able to create multiple instances of my library (eg: database connection)? My current approach is to keep the connection in rust side inside a hashmap of uuid->connection and have the dart side keep the uuid. So every time access to certain connection is needed, I just pull the connection based on the uuid. What do you think of this approach, do you have better alternatives?

[dikatok]

@fzyzcjy is rust opaque the way to go?

[fzyzcjy]

Yes I think so. Just do it as if using pure Rust (or pure Dart). For example

pub struct MyDatabaseConnection {
  your_fields: ...
}

impl MyDatabaseConnection {
  pub fn new() { ... }
  pub fn whatever_method_that_is_on_connection() {}
}

pub fn whatever_function_that_needs_connection(a: &MyDatabaseConnection) {}

[dikatok]

@fzyzcjy ok cool, brb reading the issues mentioned in https://cjycode.com/flutter_rust_bridge/guides/types/arbitrary/rust-auto-opaque/dispose

[dikatok]

@fzyzcjy can you have third party types for the opaque fields?

eg.

#[flutter_rust_bridge::frb(opaque)]
pub struct MyConnection {
    pub connection: RustAutoOpaqueNom<ThirdPartyConnection>,
}

[fzyzcjy]

For opaque, everything inside is not visible in dart, so you can have anything

[dikatok]

hmmm update on this: I successfully migrated to using rust opaque to some degree, but keeps getting Null check operator used on a null value during flutter_rust_bridge_codegen generate which weirdly enough does not affect the compiled result, also some parts are complaining about methods not existing in guard result, eg.

let rows_affected = self
                .transaction
                .try_read()
                .unwrap()
                .execute(&sql, params)
                .await
                .unwrap();

will complains about execute does not exist in RwLockReadGuard. @fzyzcjy do you have any pointers?

[dikatok]

@fzyzcjy question, given this struct

#[frb(opaque)]
pub struct Statement {
    inner: RustAutoOpaqueNom<InnerStatement>,
}

if I am not exposing inner in dart side, do I still have to wrap the type with RustAutoOpaqueNom?

[fzyzcjy]

Happy to see it is fixed!

if I am not exposing inner in dart side, do I still have to wrap the type with RustAutoOpaqueNom?

No

[dikatok]

cool, the refactored code is much cleaner than using lazy static lol, thanks

[dikatok]

@fzyzcjy sorry for reviving the discussion, if I am to remove RustAutoOpaqueNom, I should still wrap it in a locking mechanism right?

[fzyzcjy]

No need for that for frb. But anyway if you need a lock for your code's case then you can add it.