compatibility method for old generic Events
Gets the new value that just changed.
Generally speaking, if your widget can reasonably have a @property T value(); or @property bool checked(); method, it should probably emit this event when that value changes to inform its parents that they can now read a new value. Whether you emit it on each keystroke or other intermediate values or only when a value is committed (e.g. when the user leaves the field) is up to the widget. You might even make that a togglable property depending on your needs (emitting events can get expensive).
The delegate you pass to the constructor ought to be a handle to your getter property. If your widget has @property string value() for example, you emit ChangeEvent!string(&value);
Since it is emitted after the value has already changed, preventDefault is unlikely to do anything.
Added May 11, 2021. Prior to that, widgets would more likely just send new Event("change"). These typed ChangeEvents are still compatible with listeners subscribed to generic change events.
Single-value widgets (that is, ones with a programming interface that just expose a value that the user has control over) should emit this after their value changes.