Invoke handler delegation/adapter?

[stijnfrishert]

Hey everyone,

I have a crate that already has a bunch of functions under the api module. I feed these into an Lua interpreter, to enable changing my document through scripting. They're all of the form:

fn entry_point(editor: &mut Editor, args...);

I would like to expose these as Tauri commands well, providing the same API in my frontend through js/ts. In Tauri, the Editor is part of the App state (Mutex<Editor>), so the command would be something along the lines of:

#[tauri::command]
fn command(editor: tauri::State<'_, Mutex<Editor>>, args...) {
  let editor = editor.lock().unwrap();
  entry_point(&mut editor, args...);
}

I would very much like to avoid duplicating every API entry point like this. It's not only tedious, but also prone to copy/paste bugs or forgetting to do the work.

What is the best way to go about this? I was looking at the implementation of invoke handlers, but the code specifically states everything these is internal and subject to change.

Is there a way to write a set of command handlers that all have tauri::State<Mutex<Editor>>>, retrieve the editor and then delegate to my actual API functions?

[FabianLars]

I was looking at the implementation of invoke handlers, but the code specifically states everything these is internal and subject to change.

It is indeed subject to change, but so far it shouldn't have caused any problems for manual implementations (except v1 -> v2 migration).

The invoke_handler is basically an enum but you'll probably end up with more code than with all the command wrappers.

Is there a way to write a set of command handlers that all have tauri::State<Mutex>>, retrieve the editor and then delegate to my actual API functions?

Isn't that what you showed in the code example?