Add CancellationToken overloads.

[S-Luiten]

Fixes #76

[ADefWebserver]

Looks good, but, I don't understand why the Interop class has to be changed to internal. This would cause a breaking change. Yes, I know developers should not reference it, but, for those that are, I never want to introduce a breaking change to add a feature.

[ADefWebserver]

Why is this required?

[S-Luiten]

Looks good, but, I don't understand why the Interop class has to be changed to internal. This would cause a breaking change. Yes, I know developers should not reference it, but, for those that are, I never want to introduce a breaking change to add a feature.

I just noticed the class only contains internal members so it might as well be internal itself, but you're right it would be a breaking change. I reverted this change.

[ADefWebserver]

Can you add examples on the Server project and the Client project that shows how this would be used?

[S-Luiten]

I have updated the example projects to show how to use the cancellationToken parameter. You can trigger it by adding a large image or simply a lot of text to the editor. The default size limit is 32kB, if you go over this limit the method will never complete, so a timeout is used to force the method to cancel.

I also changed all async void to async Task, by doing this you no longer need to manually invoke StateHasChanged.

[ADefWebserver]

Ok I asked ChatGPT about this one...

In most cases, yes—changing a public async void method to public async Task is considered a breaking change from an API/contract standpoint because you have changed the method’s return type. Any consumer code that depends on the signature being void (for example, storing the method in a Action delegate instead of a Func<Task>, or using reflection to find a method that returns void) could break at compile-time or runtime.

That said, if your consumers are simply calling InsertText() and do not rely on its return type, then they likely will not notice a difference (i.e., calling InsertText() will still compile and work as before). However, strictly speaking, changing a public method’s return type is considered a breaking change, and should be treated as such when versioning or communicating changes in your library.

---

Why switching from async void to async Task is typically recommended:

1. Error Handling:
   Exceptions thrown in an async void method cannot be caught by the caller, making error handling more difficult and potentially allowing unhandled exceptions to crash the application. With an async Task method, the caller can await it, catch exceptions, and handle them.

2. Composition:
   async Task methods can be composed (e.g., awaited or used in Task.WhenAll, etc.). async void methods cannot.

3. API Consistency:
   Returning Task for asynchronous operations is the more common pattern in .NET libraries and helps signal to consumers that the method is asynchronous and should be awaited if they want to ensure it completes before proceeding.

So while there is a technical breaking change in the signature, it is usually a net positive change in terms of best practices and correctness.