Simplify Command Matching

[parker-codes]

The Problem

The main.rs file gets pretty bulky. Yes, things can be split apart into simpler chunks, and that's what I'm proposing - I just think Tauri can assist with some "sugar".
This probably isn't a priority. I just think of how much simpler it could be, especially for beginners to Rust.

Specifically I'd like to point out:

• deserializing the command from a string
• matching commands inline
• move ||
• destructuring and passing along Tauri-specific values like the callback and error fields

Link to code

Preferred Solution

Describe the solution you'd like
A clear and concise description of what you want to happen.

I see a few options:

1. Create a macro that converts all variant matches into methods of the same name, like GetAllTodos into get_all_todos(). The problem then becomes passing the value into the method. If there are multiple fields in the variant, would they be passed in order? That doesn't seem right. It would be cleanest to pass the command itself, but enum variants aren't real types, so the value can't be destructured and passed in. Here's a playground example of how the command can be passed, but it still needs to be matched on the other end, which detracts from the desired cleanliness.
2. Deserialize the command into a tuple variant. I think the syntax is quite ugly and confusing, but all of the RFCs have been closed or slow moving. See Types for enum variants rust-lang/rfcs#1450 and Enum variant types rust-lang/rfcs#2593. Also see this Stack Overflow post for clarification on why this is ugly. Serde has some great features that may be able to deserialize this, like flatten. This way would probably be pretty simple.

Both of these together could look like:

#[derive(Deserialize)]
struct GetAllTodos {
    callback: String,
    error: String,
}

#[derive(Deserialize)]
struct CreateTodo {
    title: String,
    callback: String,
    error: String,
}

// some type of flatten?
#[derive(Deserialize)]
#[serde(tag = "cmd", rename_all = "camelCase", flatten)]
pub enum Cmd {
    GetAllTodos(GetAllTodos),

    CreateTodo(CreateTodo),

    // .. more
}

And then potentially an attribute or macro to generate this, if desired:

match command {
    Cmd::GetAllTodos(cmd) => get_all_todos(cmd),
    Cmd::CreateTodo(cmd) => create_todo(cmd),
}

And the usage could look like:

fn get_all_todos(cmd: GetAllTodos) {
    // stuff here
}

Another thing to think about here would be handling responses and return types like via tauri::execute_promise(). Is there any way for these methods and params to be abstracted or hidden as well (like success and error callbacks)? Perhaps the commands or functions could have an attribute like #[tauri(type = "execute_promise")] which acts like a decorator?

Conclusion

This is all to hopefully help simplify how people use it - not necessarily code cleanliness. If there is a "cleaner" structure that can be done without any API changes, perhaps it's worth showcasing that in the examples instead of the very straightforward examples that are there currently.

[parker-codes]

Here's a potential implementation moving the match into the Cmd enum: Playground Link

[nothingismagick]

This is a great idea, and would love to see this mainline before beta release. @lucasfernog - what do you think?

[parker-codes]

Question: What are the use cases for accessing the webview? Perhaps that could be passed into the command execution function - maybe even as dependency injection?

Because arg could be abstracted and potentially webview, that makes me think that people could utilize this new API by using something similar to invoke_handler like invoke_enum or bind_commands that takes the enum as a parameter.

[parker-codes]

I had another idea. I'll keep spitballing them here until something sounds good. 😄

The machine crate has a great API that I think could be copied here for some great benefit.

So essentially the API could be expressed how it currently is, but with a macro scoping it. Each of the structs generated would need to implement some Command trait (just a function) which is where the user would put what they normally put in the big match statement.

The generated match statement could potentially wrap the execute_promise/etc callbacks so the user only has to specify them via an attribute in the enum definition or something.

[lucasfernog]

That sounds perfect! Nice finding @parker-codes you have no idea how excited I was to read that.

[lucasfernog]

What if we do the reverse operation of the machine crate? The user writes the structs and the macro generates the enum with the pattern matching to call the structs Command impl

[parker-codes]

That would certainly give the users more control, and it probably wouldn't be as confusing/magical.

It would also allow for the API to be extended in the future to more than just a Command impl. Not sure what that could be, but it would be more straightforward.

[parker-codes]

So the changes I'm seeing:

• a trait that defines a command set (an enum with the method that handles matching each variant)
• a trait that defines a required method on a command struct, like execute(&self)
• a declarative macro to wrap the struct definitions, which produces an enum with variants for each as well as a method that matches each command (plus an error/NoMatch variant?). They will also need a way to specify the name of the new command group/enum for clarity and perhaps because they could have multiple sets?
  - [ ] a proc macro (as an attribute) to optionally decorate a particular command's execute() method to hide the various API around execute_promise, etc
• a new API method that takes an enum that impls the set trait and calls the method to match when a new event is passed through. This could also house the logic for deserializing so that's hidden as well

A POC could be made without any API changes because this could all technically be done in userland. The macro expansion could also be done by hand until the final API is decided on.

[lucasfernog]

@parker-codes I think you're on the right track with these changes. Do you think you can work on it? This would be amazing for Tauri. I can also see stuff like these extended to the events API, which would simplify stuff like autocomplete event names on JS side.

[parker-codes]

@lucasfernog Yes, of course!

[parker-codes]

I'll summarize our Discord discussion here.

We discussed making all communication async. The callback and error flags could be handled by the core layer, simplifying another thing for the end user!

We also talked about having the macro add another property to commands to house the webview so the execute function only needs to have access to &self. To avoid conflicting with user variable names, we could make this property tauri_webview and then access it with a self.webview() method.

[parker-codes]

@lucasfernog @chippers

If I'm understanding the code properly, context could be a second param, merging the two ideas we've been discussing:

1. &self would be only the command values, with no overlap/conflict with user-defined properties
2. the next param, context, could house the webview and any other app state they've set up.

This reminds me of the state pattern that Vuex (with VueJS) uses, as well as some Rust web and game frameworks.

If I misunderstood, I apologize. 😅 This is what I got out of it, which would be pretty cool since people will start adding some "global" stores.

[lucasfernog]

Yeah you're right. I think we can also make the command interface take self instead of &self.

[parker-codes]

Where would context come from? Wouldn't Tauri need a way to attach this global state? Perhaps it already does?

[lucasfernog]

I think it could be similar to what boscop/web-view does: https://github.com/Boscop/web-view/blob/abb0721829d9764d07d8df08c249de9b27cd7447/src/lib.rs#L236