How can I modularize command handler generation?

[TylerJMcLean]

As the title suggests, I am looking to modularize the creation of command handlers so that I don't bloat the Tauri builder setup with a potentially large amount of commands that need to be accessible from the front-end. I know you can't call invoke_handler more than once per a comment on a similar thread from Fabian but I don't want to call it multiple times anyways. I want to just have a way to split the creation of the handlers or a way to make a combination of the two. Ideally it would look something like the following
module_1.rs

pub fn create_module_handlers() -> CompatibleAndConcatableReturnType {
    //Manipulate this in a way that I can combine it with another
    generate_handler![
        function_1,
        function_2,
        ...
        function_15
    ]
} 

module_2.rs

pub fn create_module_handlers() -> CompatibleAndConcatableReturnType  {
    //Manipulate this in a way that I can combine it with another
    generate_handler![
        function_16,
        function_17,
        ...
        function_30
    ]
} 

lib.rs

pub fn run() {
    tauri::Builder::default()
        .invoke_handler(module_1::create_module_handlers() + module_2::create_module_handlers())
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
} 

Obviously I'm trivializing some details here for the sake of getting my point across but if anyone knows how to do something similar I'd be forever grateful!

[ewuillai]

Hi,
I'm also interested by the same requirement.
Having some commands all declared in the main.rs for a little application is manageable. But for large, modular applications, listing all commands for all modules is not a good solution.
I tried two different approach, without success :

• tauri::generate_handler![module1::handlers(), module2::handlers()]
• tauri::generate_handler![my_macro1!(), my_macro2!()] , with my_macro returning a list of commands per module

[FabianLars]

the closest thing currently are inlined plugins because each plugin can have their own invoke handler. not as nice in v2 as it was in v1 sadly.

[BigfootN]

Hello,

I am also in the same requirement. It would be nice to be able to modularize the commands in the tauri::Builder

[iurii-izman]

You cannot concatenate the values returned by generate_handler!. The application has one effective invoke_handler; the Tauri documentation explicitly notes that calling it multiple times replaces the previous handler.

For an application-internal module boundary, I would keep the command implementations split by domain and move only the central registry out of lib.rs:

// src-tauri/src/commands/mod.rs
pub mod module_1;
pub mod module_2;

pub fn handler()
    -> impl Fn(tauri::ipc::Invoke<tauri::Wry>) -> bool + Send + Sync + 'static
{
    tauri::generate_handler![
        module_1::function_1,
        module_1::function_2,
        module_2::function_16,
        module_2::function_17,
    ]
}

// src-tauri/src/lib.rs
mod commands;

pub fn run() {
    tauri::Builder::default()
        .invoke_handler(commands::handler())
        .run(tauri::generate_context!())
        .expect("error while running Tauri application");
}

The command functions in the child modules need to be pub. Their frontend command names still need to be globally unique because application commands are not scoped by their Rust module.

This leaves one registry, which Tauri requires, but removes the large list from the builder setup and keeps implementation ownership in the domain modules.

If the modules are genuinely independent subsystems and you want each one to own its own handler registry, model each subsystem as a Tauri plugin instead. tauri::plugin::Builder has its own invoke_handler(...), so each plugin can register its commands independently. That changes the frontend command namespace and, in Tauri v2, requires plugin permissions, so I would use it only for a real architectural boundary rather than just to shorten lib.rs.

References:

• Application commands and the single-handler rule: https://v2.tauri.app/develop/calling-rust/#creating-multiple-commands
• Plugin command registration: https://v2.tauri.app/develop/plugins/#adding-commands