You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it make sense to provide constants for the actions exposes via the public API as event types? while modifying the names I realized that this actually requires a couple of changes to events that the user of the SDK might listen for.
This means that we are actually exposing internal implementation to the users. Constants as an alternative, only for the public exposed events would mean that in case of rename the user of the SDK would not need to do much, unlike now that they need to go and rename any type filtering.
I'd say not, the action's type is already a literal, so it IS the constant. At most, to avoid the user needing to import the actions as it's too internal, we could aggregate the public events tags in some public const object or enum, to be exported/imported by the users and used where events are needed, but I'd say we still need to figure out how the events will look like before doing this.
Description
On #806 , with async actions, we introduced a new naming schema for actions, which looks like paths in a domain driven structure
example:
Before:
channelOpen
(request)channelOpened
(success)channelOpenFailed
(failure)After:
channel/open/request
channel/open/success
channel/open/failure
We want to be consistent with this tagging schema for the rest of the actions as well.
Examples:
block/new
token/monitor
iou/clear
These literals should also be used only on the definition of the actions, and anywhere else,
action.type
should be used instead of the string.Acceptance criteria
Tasks
The text was updated successfully, but these errors were encountered: