Request: Allow custom event types

[drew-512]

Currently, Nova has a flexible and potent event handling system that appears to be flexible due the nature of IEvent. However, there appears no way to inject one's own event struct and have it travel like other events up the hierarchy, etc.

Request: allow developers to define their own event types and inject them into UIBlocks such that Nova processes handles them as other events. This would be quite useful -- and the functionality is basically already there and ready to go but private / protected. This pattern of making everything private is counterproductive to devs trying to leverage the advantage of Nova but do not want to maintain mods on the Nova codebase for requests such as this possible. So it would be great to start being more relaxed with that -- consider how many pieces of software have become bis specifically because they can be easily extended.

Thanks and keep up the great work! :D

[marc-antoine-girard]

I haven't tried, so you can tell me if I'm wrong, but can't you just create a struct that implement IGestureEvent? And then, you could have some code that fires the event on the UIBlock. Something like:

public struct MyCustomGesture : IGestureEvent // missing IEquatable<MyCustomGesture> cuz I'm lazy
{
    public UIBlock Target { get; set; }
    public UIBlock Receiver { get; set; }
    public int ID { get; set; }
    public Interaction.Update Interaction { get; set; }
}

// Register to the gesture
UIBlock.AddGestureHandler<MyCustomGesture>(evt => { });

// Fire the gesture
UIBlock.FireGestureEvent(new MyCustomGesture());

Sorry if I misunderstood 😃

[drew-512]

Many thanks brother. Will try this out and report back.

[drew-512]

Yeah this works. I see the under construction tag, so hopefully that means this will be cleanup up a bit so it's not as much of a tacky misnomer / hack.

If I try to just use IEvent, FireEvent() is not exposed.

[marc-antoine-girard]

I can't remember where, but I actually know how to do that because one of the devs showed it to someone else here, who were trying to fake an event (like simulate a click on a UIBlock), so it's not really a hack. In fact, IEvent has really no use for us. It's more of a common interface for what describes any events in Nova. For instance, I'm not sure why you would want to fire an OnBind<T> event (which implements IEvent) since it doesn't do much on it's own. All other events (Navigations and Gestures) implement IGestureEvent.

Also, the under consideration tag pretty much means "waiting for more engagement / interest from the community". But it would be nice if they can chime in and give us some input about the matter 😄

[adgray1]

@marc-antoine-girard is rather on point here. Thank you for chiming in!

Creating and firing custom IGestureEvent types is fully supported through the public API - so not a "hack" by any means for anything input related.

However, IGestureEvent does incur some input-related property "bloat" in scenarios where the desired custom event type has nothing to do with input/gestures/etc. - in which case IEvent would technically be the slightly "cleaner" interface to implement, as @drew-512 suggests. Which is why we marked the request as Under Consideration because it does seem like a valid request for a currently unsupported feature (through the public API, at least) - but yes, Under Consideration is different than In Progress in terms of our categorization.

@drew-512, we appreciate the feedback and can understand your questioning as to why many seemingly-useful utilities within the Nova codebase are protected/private/internal. Just to provide some context on that "internal by default" approach, the reality is there's a much higher cost to any public feature than internal utilities. It's not just a matter of "how long it takes us to implement feature X", though of course that's a factor as well. Public-facing features require more test coverage, documentation, customer support, etc. If a given feature is a utility we use internally, then, by making it public, we also lose almost all flexibility to make changes to it in the future, potentially impacting development of other new features. So it's not that we don't want to provide certain functionality or existing solutions for everyone to use, but there are practical limits to the volume of code we can ship (and support) at the quality bar we aim for with Nova.

And just as @marc-antoine-girard also pointed out, the only built-in non-gesture events using IEvent are the bind/unbind events, which we haven't found particularly useful to fire manually - hence opting to initially scope the set of user-triggerable events to IGestureEvent.

All that said, most of the functionality to support custom IEvent types is already there and has test coverage, so we'll see where we can try to slot this in within the relatively near future :)