1private async void Button_Click(object sender, RoutedEventArgs e)
2{
3    var text = await client.GetStringAsync(url);
4    Output.Text = text;
5}

1open System
2open System.Net.Http
3open System.Windows
4
5let client = new HttpClient()
6
7let fetchTextAsync url =
8    async {
9        let! response = client.GetStringAsync(url) |> Async.AwaitTask
10        return response
11    }

1button.Click.Add(fun _ ->
2    async {
3        statusText.Text <- "Loading..."
4        let! text = fetchTextAsync "https://example.com"
5        statusText.Text <- text
6    }
7|> Async.StartImmediate ) ``` `Async.StartImmediate` is useful here because it starts on the current thread and cooperates well with the UI context. ## Why `Async.AwaitTask` Matters Many .NET APIs now return `Task`. F# async workflows can still use them, but you need a bridge: ```fsharp let! text = client.GetStringAsync(url) |> Async.AwaitTask ``` That is the rough equivalent of `await` in C#. Without it, you are mixing two async models without telling F# how to convert between them. ## Updating the UI Safely WPF controls must be updated on the UI thread. If you stay in a UI-started async workflow and use `Async.StartImmediate`, simple UI updates usually stay straightforward. But if you hop to background threads manually, marshal back through the dispatcher before touching controls. Example: ```fsharp window.Dispatcher.Invoke(fun () -> statusText.Text <- "Done" ) ``` Do not assume every async callback resumes on the thread you want unless the workflow structure guarantees it. ## Using `task` in Modern F# F# also supports task-based code that looks closer to modern C#. ```fsharp open System.Net.Http open FSharp.Control.Tasks let client = new HttpClient() let buttonClickHandler () = task { statusText.Text <- "Loading..." let! text = client.GetStringAsync("https://example.com") statusText.Text <- text } ``` If your codebase is already task-centric because of ASP.NET Core or modern .NET libraries, using `task` can reduce friction. But classic F# async workflows are still common and perfectly valid. ## Error Handling Asynchronous UI code needs explicit error handling. Otherwise, failed network or file operations can vanish into event-driven code paths and become hard to diagnose. ```fsharp button.Click.Add(fun _ -> async { try statusText.Text <- "Loading..." let! text = fetchTextAsync "https://example.com" statusText.Text <- text with ex -> statusText.Text <- "Failed" MessageBox.Show(ex.Message) |> ignore } |> Async.StartImmediate ) ``` This is the F# equivalent of wrapping `await` logic in `try` and `catch`. ## Choosing Between `async` and `task` Use F# `async` when: - the codebase already uses async workflows, - you want idiomatic classic F# composition, - you need lightweight workflow operators. Use `task` when: - most surrounding APIs are task-based, - the team prefers syntax closer to C#, - interop with task-returning .NET libraries dominates the code. The important thing is consistency. Mixing both styles casually can make the code harder to follow. ## Common Pitfalls - Blocking the UI thread with synchronous work inside a WPF event handler and assuming the code is “async enough.” - Forgetting to convert `Task` values with `Async.AwaitTask` inside classic F# async workflows. - Updating WPF controls from the wrong thread after background work completes. - Using fire-and-forget async code without error handling and then losing exceptions. - Mixing `async` workflows and `task` computation expressions inconsistently across the same UI feature. ## Summary - F# supports WPF asynchronous event handling through async workflows and task computation expressions. - '`Async.StartImmediate` and `Async.AwaitTask` are key tools in classic F# UI async code.' - Keep the UI responsive by moving slow I/O work off the immediate event path. - Update WPF controls only from the correct UI context. - Choose either `async` or `task` intentionally based on the surrounding codebase and interop needs.