.NETpad 2025: Data Binding First Steps (Premium)

Whether I move forward with WPF, WinUI 3, or both, it's clear that I need to figure out data binding if I want this app to work properly. And that's not great: Data binding is f#$%ing difficult. So I'm trying to learn how to implement it reliably. Emphasis on the word trying.

Because this is so early on, I figured it made sense to stick with a single document version of the app first. And because I'm also trying to figure out WinUI 3--meaning, the Windows App SDK--I decided to do this work in that environment and not WPF. But I believe the basics are extremely similar, if not identical.
Data binding 101
If you look at the official documentation, you'll see that data binding is a way to display data in an app user interface in a way that can be automated, meaning that the value of the data is synced between the data source and a bound UI control: If the underlying data changes, the UI can change automatically. Among other things, this functionality is ideal for the document state management that .NETpad requires. It's also worth pointing out that the separation of data and UI is good practice, whether it's an informally structured app like mine or a more formal app design pattern like Model-View-ViewModel (MVVM).

Also, none of this is new. In Programming WPF, which was first published in 2005, Microsoft's Chris Sells writes that data binding is the act of registering two properties with the data binding engine and letting the engine keep them synchronized, converting types as appropriate. And in WPF Unleashed, which was first published in 2006, author Adam Nathan writes that data binding is about tying together arbitrary .NET objects with a binding that you set up once and then have it do all the synchronization work for the remainder of the app's lifetime.

It sounds so simple. And the examples one runs into online do lean heavily on the simple. For example, you might have two text boxes in a window, with the second text box being bound to the first so that whenever you edit or overwrite the text in the first text box, the text in the second one changes instantly to match. That kind of data binding is simple, of course. But even my very simple app has more complicated needs.

In .NETpad, I have a class for documents (DocumentTab previously, Document in more recent versions), for example, that has properties related to the state of an actual document--an instance of the Document class--like FileName, Contents, TextHasChanged, DocumentIsSaved, and so on. With an eye towards a future in which this app supports multiple tabs and documents, I've tried to manually keep the state of a document up-to-date. This isn't too difficult with a single document. But it gets problematic when you introduce multiple tabs and documents. So I would like to automate this work as much as possible. And that's why I'm trying to figure out data binding.
Basic app structure
To test data binding, I've been creating simplifying versions of .NETpad in WinUI...