specta-rs / tauri-specta

Completely typesafe Tauri commands
MIT License
368 stars 40 forks source link

what's the best way to generate binding for non plugin commands / events in v2? #80

Closed anatawa12 closed 6 months ago

anatawa12 commented 7 months ago

I heard #77 has solved in v2 so I tried to use v2 but I could not find the option to not include "plugin:tauri-specta|" prefix in command names.

oscartbeaumont commented 7 months ago

I'm curious to hear more about your usecase that requires this. Don't the Tauri Specta Typescript bindings that are generated take care of the prefix for you?

anatawa12 commented 7 months ago

The generated binding always includes "plugin:tauri-specta|" and I think it's not needed for my use case since my project is not a tauri plugin. I'm sorry if my understanding for tauri is not enough.

anatawa12 commented 7 months ago

In other words, I do not want to include tauri-specta in runtime build as a plugin, I want to use tauri-specta as just a typescript generator as in v1.

Brendonovich commented 7 months ago

The generated binding always includes "plugin:tauri-specta|" and I think it's not needed for my use case since my project is not a tauri plugin

The relevant difference here is that v2 tauri-specta handles your commands and sets up the invoke handler, not your application. Even though they're your app's commands, the invoke handler belongs to a plugin so they have to be invoked via the plugin's prefix.

Maybe this is a bad design, but it's required for event support + imo provides a nicer experience than adding the invoke handler yourself, though I'd be open to providing an API for pulling out the invoke handler + exporting the types without mounting the plugin, provided that no events have been registered yet.

oscartbeaumont commented 6 months ago

This is fixed now. You can see how it works here.