Document Emitter trait method panics

[sftse]

Almost all methods of the Listener and Emitter traits take an event name and will panic if that name does not satisfy some preconditions. This is not documented and this PR fixes this. This PR also moves the panic locations closer to the user-facing code, making it immediately clear what has gone wrong and what methods were responsible for the panic. Prior to this change, the panic pointed to a location of little use to a user of tauri unless he reverse engineers how that code was called within tauri.

As a drive-by improvement, it was a bit unclear that the Emitter trait is purely defined based on methods on the AppManager. This PR makes all methods on the Emitter trait default methods and saves boilerplate. This change should not have any downsides because Emitter is a sealed trait that can only be implemented inside tauri.

[amrbashir]

Thank you, this LGTM, could you add a change file in .changes directory?

This PR makes all methods on the Emitter trait default methods and saves boilerplate

This was done intentionally to customize the documentation example based on the used type, but I guess it is fine to remove.

[github-actions]

Package Changes Through 5126966

There are 3 changes which include tauri-bundler with patch, tauri-cli with patch, @tauri-apps/cli with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
tauri-bundler	2.2.2	2.2.3
@tauri-apps/cli	2.2.5	2.2.6
tauri-cli	2.2.5	2.2.6

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[FabianLars]

Should we even panic here? It may be good for development for most cases but what if devs use dynamic event names that are derived from some http request for example?

idk panicking in a gui library just always sounds awaful to me

[amrbashir]

yeah maybe returning an Error here is better, the methods already return Result type

[sftse]

I've added some changes that inch closer in that direction, replacing the assert with a checked EventName constructor along with some internal refactors, no longer passing &str and String but EventName<&str> and EventName<String>. I think the code structure benefits from these changes regardless of whether the panic should be removed or not. If the changes are not palatable (they're a bit larger than I originally set out to do with this PR) I can revert.

While Emitter does return an error, Listener does not, and will also panic when given bad event names. So I think it is not possible to get rid of the panics without breaking stable api.

[sftse]

This is tangentially related, but I really think the Emitter trait methods should take &S instead of S, a breaking change for the future. Using S prevents the compiler from being as helpful as it can be, and will suggest to clone if a non-copy S is passed, not realizing that &S also implements the trait bounds.

[amrbashir]

Thank you