tauri-specta doesn't export any errors as interfaces in TS

[kiryasolod]

For example if I take this code #[tauri::command] #[specta::specta] pub fn license_check( window: tauri::Window, machine_id: tauri::State<Option<states::StateMachineId>>, ) -> std::result::Result<states::StateLicense, errors::XmlDosTracedError> { let info = dto::states::StateLicense::check_license(&machine_id)?; window.manage(info.clone()); Ok(info) }

It's OK about states::StateLicense but I cannot get my XmlDosTracedError along with the other functions and interfaces in TS

My XmlDosTracedError is a struct: #[derive(Debug, Serialize, Deserialize, Type)] pub struct XmlDosTracedError { pub file: String, pub line: u32, pub column: u32, pub version: String, pub error: String, }

[Brendonovich]

Specta should probably require that Result error types implement Type too, the only problem is how to accurately type errors since JavaScript uses exceptions. We could provide an option for an api like https://trytm.vercel.app/

[kiryasolod]

Yes, It would be a very good idea! I like this way to return a tuple of the data and the error! The problem is not only with JavaScript and how it uses exceptions. Now I have to write my XmlDosTracedError in TS manually because it's not enough for tauri-specta just to add #[derive(Type)] for some type to see it generated in TS. It must be used in some tauri commands for that and it actually makes sense. Why to export anything if it's not used in commands. There is an opened issue here about tauri events, so I won't duplicate it. So, only errors left to be mentioned

[oscartbeaumont]

It's worth noting that Specta itself allows exporting arbitrary types so you could use that to export your error type for you even though it wouldn't be integrated with tauri-specta for now. You could use Automatic Export or Manual Export.

I think not handling error types was an oversight of the initial design of tauri-specta and I'm not really sure of the best path forward but I think the error enum might be it.

[Brendonovich]

The main problem with error exporting is that we don't actually capture the types of errors, that will have to be changed in Specta itself with either an additional trait bound on SpectaFunctionReturn or a dedicated impl Type for Result.

[kiryasolod]

Ok, I'll try to follow your advises. I didn't see this automatic an manual export features in the docs, so I thought that it was impossible. The issue is closed then. Thank you

[oscartbeaumont]

I am reopening because I do still see this as a problem we should have an official fix for. My previous message was intending to point out that Specta can be used directly as a temporary alternative until we can get a better solution as part of specta-tauri.

This will probs end up being a Specta v2 thing cause it might need breaking changes in Specta but I will keep it in mind.

@kiryasolod great spot on this because this is something we probably shouldn't have missed in the initial design.

[kiryasolod]

Ok, thank you for noticing! I'm glad I could help =)

[Suyashtnt]

The PR was merged. Shouldn't this be closed?

[oscartbeaumont]

21 was merged onto the v2 branch not main so, although it's working, I think it still needs some work and documentation before I would call it complete. Especially right now typing error types is pretty annoying and something I want to investigate better solutions before we document it.

[Suyashtnt]

21 was merged onto the v2 branch not main so, although it's working, I think it still needs some work and documentation before I would call it complete. Especially right now typing error types is pretty annoying and something I want to investigate better solutions before we document it.

I'm planning to use this in conjunction with https://effect.website/ which does have built-in error types. Maybe allow the generator to support this along with other libraries error types? I know @mobily/ts-belt has its own error handling type as well

[oscartbeaumont]

That is a Specta thing (or at least it will be in the final implementation of error handling) but will open an issue to track it. https://github.com/oscartbeaumont/specta/issues/119

[dam5h]

@oscartbeaumont is this expected to work in v1 or only v2?

I would love to use Result in our application but we are on v1.

I created this ticket over in tauri repo which was before I found this.

In order to use v2 specta, I assume we need to migrate to tauri v2?

[oscartbeaumont]

Looking at the commit history the PR for result handling landed prior to Tauri Specta 1.0.2 so I assume it would work but I actually can't remember the exact order of events.

Specta v1 internally translates fn todo() -> Result<A, B> to A which is what it looks like your hitting. This was a bug in the initial design.

Although, checking the original result handling PR for Tauri Specta it looks like we would hack around this by doing a match on the tokens from the macro so we could avoid Specta's result handling being used. This would theoretically make it work but it's possible i'm missing something else that's breaking it.

If it doesn't work there is not really much we can do as we are not currently backporting changes to Specta v1.

It's possible you could try Tauri Specta v2.0.0-rc.4 which is not Tauri v2 but it does require Specta v2.