feat: add resource type

[JonasKruckenberg]

This finally fixes the implementation of the resource type.

Details

Take the following wit file:

interface has_resource {
   func constructor_a () -> a

   resource a {
      func f1()
   }
}

It translates into this host code:

use tauri_bindgen_host::{ResourceTable, ResourceId};

// resources are represented by their own structs, allowing them to keep their own state.
struct ResourceA;

impl has_resource::A for ResourceA {
    fn f1(&self) {
        println!("called resource method!!")
    }
}

struct Ctx {
    // there is no centrally managed resource table as with wasmtime or deno
    // instead callers manage their own resource tables.
    // While this is more verbose it's both much simpler and reduces lock contention (by splitting one big lock into multiple small ones)
    a: ResourceTable,
}

impl has_resource::HasResource for Ctx {
    type A = ResourceA;

    // this is required under the hood so the dispatcher can get the resource
    fn get_a(&self, id: ResourceId) -> ::tauri_bindgen_host::Result<Arc<Self::A>> {
        self.a.get::<Self::A>(id)
    }

    // this is the regular interface function
    fn construct_a(&self) -> ResourceId {
        self.a.push(Arc::new(ResourceA)).unwrap()
    }
}

TODO list

• Host implementation
• Guest JS implementation
• Guest TS implementation
• Guest Rust implementation
• Markdown implementation

[netlify]

✅ Deploy Preview for tauri-bindgen canceled.

Name	Link
🔨 Latest commit	dd85e41
🔍 Latest deploy log	https://app.netlify.com/sites/tauri-bindgen/deploys/6502d90fd591e600086ab0a4

[JonasKruckenberg]

Requested a review from @tauri-apps/wg-webview bc you are probably the most appropriate for this field, not really sure though

[amrbashir]

I think @tauri-apps/wg-tauri is better suited for this, however I have not been following the tauri-bindgen closely so I am not sure what I should be looking at to review.

I should not that I needed to have a resource table in tauri-apps/tauri#7709 so I used deno's implementation (but with Arc instead of Rc because of tauri's Send + Sync requirements) so this PR would replace that implementation, right?

struct Ctx {
    // there is no centrally managed resource table as with wasmtime or deno
    // instead callers manage their own resource tables.
    // While this is more verbose it's both much simpler and reduces lock contention (by splitting one big lock into multiple small ones)
    a: ResourceTable,
}

How would this struct look like if I have multiple resources? would it look like this?

struct Ctx {
    a: ResourceTable,
    b: ResourceTable,
    c: ResourceTable,
}

If so, it seems unnecessary, if applying to the menu PR I linked above, where I usually need to use 2~4 different menu types (aka resources), I will have to lock 2~4, instead of just one lock with a central resource table.

[JonasKruckenberg]

Yeah so I slapped this ResourceTable impl together just to have something that works. But you're not forced to use it at all, the idea is that the generated trait forces you to implement a method called get_<resource ident>(&self, id: ResourceId) and that will be used under the hook to determine which resource's mehthods will be called.

It doesn't really matter what structure you use to store the resources as long as you can produce a reference to it when asked.