onWidgetLoad and onSessionUpdate data schemas do not match.

[ryanbarr]

The documentation for onSessionUpdate says that the schema for the data that comes through for a session on onSessionUpdate matches the data that comes through on onWidgetLoad. See here: https://github.com/StreamElements/widgets/blob/master/CustomCode.md#on-session-update

However, upon attempting to use subscriber-points (along with various other subscriber-specific properties), the data does not match.

For example:

• onWidgetLoad session data has subscriber-points with a value like { amount: 1 }
• onSessionUpdate session data has subscriber-points with a value that represents the latest subscriber, such as { type: "subscriber", name: "Joscelin", ... }

[ryanbarr]

@justlx, would you mind taking a look at this when you get a chance? It would be incredibly useful to have onSessionUpdate have accurate data.

[justlx]

Testing events create different data than real ones (they add more stuff to different endpoints as it doesn't matter there). The reason behind that is to allow user checking their scripts with emulation. Data structure onWidgetLoad and onSessionUpdate stays the same for real events.

[ryanbarr]

@justlx Thanks for the response and clarity on the decision that was made. I'd like to take this opportunity to present a use case that would defend keeping the integrity of the schema intact.

Scenario: Create a widget which shows a progress bar towards a goal, where the goal is a choice between subscribers/subscriber points/etc.

Implementation:

1. onWidgetLoad, take the current target value (subs, points, etc.) and render the progress bar with its value.
2. onSessionUpdate, take the current target value (subs, points, etc.) and render the progress bar with its value.

Concerns:

1. In the scenario described, when emulating the event the schema of the data given to onSessionUpdate is not consistent with the data given to onWidgetLoad, which results in a developer not being able to reliably test the functionality of their widget that depends on the subscriber data in onSessionUpdate. This would result in requiring live data to test, which is not feasible due to the financial nature of a subscription event.
2. While I could reasonably say, "onSessionUpdate suggests a new subscriber has been created" and then increment subs by one (or sub points based on tier), what this does not account for is the loss of subs since the last event. It is feasible that the numbers can be decremented even when this incremental action occurs, due to not having a hook that watches for "negative transactions" (loss of subscription, unfollow, etc.).

Suggestions:

1. Preferred: Update the onSessionUpdate data object to match the schema that onWidgetLoad has, as it is documented in the CustomCode docs. Ensure the session data is the latest data, so loss of followers, subs, sub points, etc. is reflected. OR
2. Update the onSessionUpdate data object as is described in the first option, but use a cached response for emulated events. This would prevent the need for expensive pulls of session data, while still maintaining a consistent schema that can be developed against. OR
3. Provide a new, alternative way of being able to pull the latest data-point from the API via the widgets on-demand, either through rate-limited polling, throttled pre-defined methods, etc.

--

As an aside: my understanding is that there are three events broadcast on window: onWidgetLoad, onEventReceived, onSessionUpdate.

From the looks of it, onEventReceived and onSessionUpdate have become almost identical. However, I think there needs to be a clear differentiation between the three events as they each provide explicit and differing functionality:

• onWidgetLoad: Instantiation of the widget; should receive data in the context of both the latest session data and the most recent event data.
• onEventReceived: Event has been received, take action upon it (alert, effect, etc.); should receive only the most recent event data.
• onSessionUpdate: Session has been updated, take action upon it (progress bars, counters, etc.); should receive only the most recent session data.

By making sure each serve an explicit purpose, the handlers bound to each event become more clear in their purpose. While a subscription event will trigger both onEventReceived and onSessionUpdate, it should be acceptable to handle that event with both handlers. For onEventReceived I expect immediate feedback, bound to a specific action a user has taken. For onSessionUpdate, I expect data-heavy information regarding the session to be provided to me, even if its not in true real-time or its behind a 5, 10, 30, 60 minute TTL from a cache because of the nature of the data.

[SanlarisDev]

Please, its necesary:

Preferred: Update the onSessionUpdate data object to match the schema that onWidgetLoad has, as it is documented in the CustomCode docs. Ensure the session data is the latest data, so loss of followers, subs, sub points, etc. is reflected