Suggestion- Websocket Subscription Handlers - static 'SubscriptionType'

[WrithemTwine]

Recommendation to add or update INotificationHandler 'SubscriptionType' to static.

e.g.

TwitchLib.EventSub.Websockets/TwitchLib.EventSub.Websockets/Handler/Stream/StreamOnlineHandler.cs

Line 17 in 129f195

public string SubscriptionType => "stream.online";

We could use the static object for reference in the Helix create subscription, instead of either an instance (see below code example) or manual typed subscription.

Helix.EventSub.CreateEventSubSubscriptionAsync( new StreamOnlineHandler().SubscriptionType, "1", conditions, EventSubTransportMethod.Websocket, _eventSubWebsocketClient.SessionId );

Or am I missing a dictionary table somewhere with all of the subscription types accessible by key/value?

(I can understand code logistical issues and trying to keep things as minimal footprint can override this suggestion).

[AoshiW]

I like your idea, but it can't be done the way you suggest:

1. The handlers have been removed (even if the handlers weren't removed, we couldn't do it because there would be other problems: We can't change SubscriptionType to a static property because we have to access it through the interface; I started making the handlers private so they can be changed without breaking)
2. It is not a good idea to implement this feature in .Websockets because if it is implemented here, there is a chance that someone who uses .Webhooks will want it too. So in the end it would have to be maintained in two places(== extra work)

A better solution is to implement this feature in the .Core project. It would probably be implemented something like this:

namespace TwitchLib.EventSub.Core; // maybe a differentnamespace?

public class Subscription 
{
    public string Type { get; }    // or Name
    public string Version { get; }

    public Subscription(string type, string version)
    {
        Type = type;
        Version = version;
    }

    public static Subscription AutomodMessageHold = new("automod.message.hold", "1");
    public static Subscription AutomodMessageHoldV2 = new("automod.message.hold", "2");
    ...
}

and it would be used like this:

// before
Helix.EventSub.CreateEventSubSubscriptionAsync("stream.online", "1", conditions, EventSubTransportMethod.Websocket, _eventSubWebsocketClient.SessionId);
// after
Helix.EventSub.CreateEventSubSubscriptionAsync(Subscription.StreamOnline.Type, TempName.StreamOnline.Version, conditions, EventSubTransportMethod.Websocket, _eventSubWebsocketClient.SessionId);

[WrithemTwine]

Ok. I wasn't strictly suggesting it for use only here, rather overall (I'm just using the websocket version). The premise was when using the Helix create subscription, the arguments duplicated text otherwise already available elsewhere in the library.

As for maintainability and usage, I'm all for picking the right code pattern. I don't involve myself directly in the library as a way to stay arms-length when making suggestions.

From the Twitch Docs, my understanding is the event subscription types and version numbers always increment up and the last version is always used. So, there is no reason to maintain older version subscription types.

I can see for maintainability, have the 'subscription' and 'version' strings out in some Dictionary object; can update all of those to the latest Twitch documentation at one time, as compared to reviewing each handler. Then, the dictionary can be visible inside & outside the library. That way, as you say, the handlers can go completely private and we can still get the info from the Dictionary.

I just found it clunky to maintain my own code that needed otherwise string inputs to match the event handler values. What may be good to maintain inside the library might not always be friendly to the outside code.

[AoshiW]

Sorry for the late reply.
We cannot create a "dictionary" where only the latest version of 'SubscriptionType' would be used, because it would not fit with how the library is currently written.

When a new version of the existing SubscriptionType is released, instead of modifying the existing model, a new model is created. This allows us to avoid releasing a new major version, and users can consider it a safe update that does not contain any breaking changes.

On top of that, Twitch keeps versions 1 and 2 for some SubscriptionTypes for some reason.