Feat: streaming functions

[JonasKruckenberg]

This adds the initial implementation of streaming responses of functions aka the stream pseudo-type.

It's a pseudo to type because while it looks like any regular type: stream<t> the only valid position where it may appear is as the sole return type of a function like so

interface streams {
   func streaming_bytes() -> stream<list<u8>>
}

(This restriction might be gradually lifted at some point)

The primary motivation for this new addition is to model sequences of asynchronously produced data such as events, log streams, or just streaming bytes from e.g. the disk.
With this addition the tauri-bindgen system can finally replace the current IPC system as this allows us to model events (in an IMO type-safer and more ergonomically way)

Details

The generated guest rust code look like this:

pub async fn streaming_bytes() -> ::tauri_bindgen_guest_rust::Streaming<Vec<u8>>;

where ::tauri_bindgen_guest_rust::Streaming<T> takes care of the underlying raw http stream and deserialisation of the incoming data. It in turn implements Stream<Item = T>.
It's worth noting that currently the implementation relies on ReadableStreams returned by fetch, and so performs no additional buffering (everything follows the rust pull-based model here which is nice).

Streaming<T> doesn't implement framing yet though it probably should.

The generated host code looks like this:

pub trait Streams: Sized {
    type StreamingBytesStream: ::tauri_bindgen_host::Stream<Item = Vec<u8>>
        + Send
        + 'static;
    ///A function that returns a stream of strings
    fn streaming_bytes(&self) -> Self::StreamingBytesStream;
}

So an implementation would need to give a specific type for StreamingBytesStream (most likely some wrapper type)

struct Ctx {
   // a list of handles so we can send events to all open channels
   // this emulates a broadcast channel
   txs: Arc<Mutex<Vec<mpsc::Sender<Bytes>>>>
}


impl Streams for Ctx {
   type StreamingBytesStream = tokio_stream::wrappers::ReceiverStream<Bytes>;

   fn streaming_bytes(&self) -> Self::StreamingBytesStream {
      let (tx, rx) = mpsc::channel(250);

      // this can of course be refactored to not require locking
      let txs = self.txs.lock().unwrap();
      txs.push(tx);

      Self::StreamingBytesStream::new(rx)
   }
}

The above example also showcases how a similar DX to the classical tauri events can be achieved, by essentially passing around mpsc::Sender handles.

Note

This PR is currently blocked by the fact that wry's event handler doesn't allow for streaming responses back to the webview tauri-apps/wry#1022

TODO list

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

This closes #180

[netlify]

✅ Deploy Preview for tauri-bindgen ready!

Name	Link
🔨 Latest commit	4731e0b
🔍 Latest deploy log	https://app.netlify.com/sites/tauri-bindgen/deploys/64fe1750416be600081fc4fc
😎 Deploy Preview	https://deploy-preview-190--tauri-bindgen.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[jquesada2016]

I love this!

Since stream can only appear in the output of the function, how is the guest supposed to mimic the event emitter pattern the host has?