So your problem is the default/zero values of properties?
In Go the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties.
Also can't you build your own validator for that with the reflect package in the Add() method of your UI graph to prevent this sorta thing?
The Go std library, as well as practically all go library code, is full of things that don't fully initialize all properties and things that nil-pointer-panic if you hold them wrong, so no, no matter what you do you have to deal with this wart of Go.
The go type-system is simply incapable of enforcing nil-safety without being no longer able to compile the go stdlib nor most code in the wild, so it's a quite valid criticism of the go type-system and language, and your comment doesn't hit on a valid solution.
> the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties
But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}.
> can't you build your own validator for that with the reflect package in the Add() method of your UI graph
Besides the fact that that would almost certainly significantly hurt performance, how would you be able to differentiate between unitialized data and data that was intentionally set to the zero value?