-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update channel subscription to match docs and fix doubles #21
base: master
Are you sure you want to change the base?
Update channel subscription to match docs and fix doubles #21
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to check the how the subscription works again to verify the rest of these changes..
@@ -158,16 +158,16 @@ func (c *Client) UnPinMessage(message *models.Message) error { | |||
// Returns a buffered channel | |||
// | |||
// https://rocket.chat/docs/developer-guides/realtime-api/subscriptions/stream-room-messages/ | |||
func (c *Client) SubscribeToMessageStream(channel *models.Channel, msgChannel chan models.Message) error { | |||
func (c *Client) SubscribeToMessageStream(channel *models.Channel) (chan models.Message, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Being able to pass the channel to use in is actually one of the benefits here. It would let you set up a loop to handle all messages.
Kinda like the example I sent in #golangsdk
ch := make(chan models.Message)
for _, channel := range channels {
_ = client.SubscribeToMessageStream(&channel, ch)
fmt.Println("Started listening channel: " + channel.ID)
}
go func () {
for msg := range ch {
fmt.Printf("Message [%s]: %+v\n", msg.RoomID, msg)
}
}()
Here that loop handles all messages from all channels. Of course you could choose to divide it up and handle different rooms separately if you wished.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd personally be fine with this either way, because it's no great task to merge channels anyway, it's just that returning channel seemed ergonomically better and also matched function documentation.
If the other change (to the extractor part) makes sense to you I can resubmit these changes without returning channel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think the better thing here is to keep passing it in so we don't break existing that are using it this way
Currently update extractor does not match eventName (which is channel ID) so if you subscribe to two channel every message in either one will register in both channels.
Also documentation mentions returning channel, which would better agree with
Sub
function returning channel.