Source generators are often introduced as a way to remove boilerplate. In a Unity UI project, I think their more useful role is to make a binding contract visible before Play Mode.
A ViewModel can state its intent directly:
[ObservableProperty]
[Bind("Title", nameof(TextElement.Content))]
string title = "Settings";
[Command("Close", nameof(ButtonElement.OnClick))]
public void Close() { }
From that metadata, a generator can create binding and command code, and an analyzer can report invalid Element names, component types, members, duplicated contracts, or incomplete declarations. A field rename is no longer just a change to one C# identifier; there is enough information for tooling to tell that the UI contract has changed too.
But C# compilation cannot inspect a prefab. That is the half that gets missed when people talk about compile-time binding. The asset might no longer contain Title, the object might have the wrong component, or a duplicate name might have appeared in the hierarchy.
My approach in FUI is to pair source generation with prefab-side validation. The editor validates Elements, types, names, nesting boundaries, and page structure when a prefab is saved. The same checks run before a build. The generator and the editor are checking different sides of the same contract.
The generator also creates typed Route entries. Each route keeps the asset key, ViewModel, Presenter, binding factory, and page policy together, so a project does not need a separate string registry to keep those parts aligned.
The goal is not to claim that every UI error can be caught statically. It is to move the errors that can be described into a place where a refactor can expose them early.
I put the implementation and a small Settings Sample here:
Top comments (0)