[Problem/Question]
Hi all! I followed the Vue tutorial and got it to work, but not entirely. The main issue is that sendbirdSelectors.getSdk(props) / getSdk(props) returns undefined, therefore no currentUser and the rest of the code doesn’t get executed.
To give more context, I am trying to configure the UserEventHandler.onTotalUnreadMessageCountUpdated() in order to implement a badge in the UI, showing the unread messages count. Not sure if this is the right approach, I was looking for an event that gets triggered when the current user receives a new message (to implement notifications), however I couldn’t find any. I also tried using the JS SDK’s sb.addUserEventHandler(), but it doesn’t seem to work if the app is already initialised via UI Kit. Is there anyway to make them work together?
I would appreciate any recommendations on how to tackle this. Thanks in advance!
[Version 3.3.7]
[Reproduction Steps]
[Current impact]
The usefulness of the chat without notifications is significantly reduced.
Works like a charm now, thanks @Tyler ! I also got the event handler to work.
The only limitation, which makes sense, is that if I’m on another page and refresh / close & reopen tab, I need to navigate back to the chat page to get the listener working again. Is there anyway to add the listener without loading the whole react component, maybe via the JS SDK?
You may be able to install the Core SDK along side it to access the instance outside of the react component but to be honest, we’re getting into a grey area there so it’s hard to provide specific support there.
I think if you initialize the core SDK somewhere, and register the handlers earlier in your rendering process you should be okay. Just be cautious on whether or not you call sb.connect() as it could cause your MAU/PC counts to increase more than you anticipate.
That’s what I had in mind. I’m more concerned about PCC, though. I assume MAUs are calculated per unique users, but each sb.connect() translates to a PCC++, even if it’s the same user?
That is correct. PC is determined by the number of active websocket connections and it does not care whether one user is connected multiple times (multiple browsers/tab).
It worked! I still have to do the connection check the other way around (e.g. if connected from SDK, don’t connect in the UI Kit). Since that doesn’t look feasible, should I just sb.disconnect()?
The SDK internally should handle the connection state between the Core and UIKit since the UIKit is using the core SDK underneath.
That being said, you can actually register the channelHandlers without calling connect. So if all you’re doing is looking to register those outside of your React component, then don’t consider calling connect the core SDK.
Sorry, I passed out on Friday, it was a long night.
The SDK internally should handle the connection state between the Core and UIKit since the UIKit is using the core SDK underneath.
Makes sense. In this case, can I safely assume that the UIKit will not create a new connection, but reuse the existing connection created by Core SDK (i.e. no need to call sb.disconnect())?
That being said, you can actually register the channelHandlers without calling connect. So if all you’re doing is looking to register those outside of your React component, then don’t consider calling connect the core SDK.
Thanks for the sample! I tried this, but in order for the handlers to actually get triggered without navigating to the Chat page (i.e. where the react component lives), it seems that I need to also call sb.connect(). This also makes sense, since receiving chat updates without having a user connected would be a major security issue.
Makes sense. In this case, can I safely assume that the UIKit will not create a new connection, but reuse the existing connection created by Core SDK (i.e. no need to call sb.disconnect())?
This is correct.
Thanks for the sample! I tried this, but in order for the handlers to actually get triggered without navigating to the Chat page (i.e. where the react component lives), it seems that I need to also call sb.connect(). This also makes sense, since receiving chat updates without having a user connected would be a major security issue.
Ah yes, this is a bit of an oversight on my part. I think I was merely thinking about the act of registering a handler and less about when its triggered.
@Tyler sorry to bother again, but apparently I missed testing out the chat options sidebar. It seems it doesn’t open anymore (i.e. see your stackblitz example).
Oh, I thought since the button is there, it doesn’t need any implementation. So I assume Channel.onChatHeaderActionClick() to show it and ChannelSettings.onCloseClick() to hide it?
I still have to do the connection check the other way around (e.g. if connected from SDK, don’t connect in the UI Kit). Since that doesn’t look feasible, should I just sb.disconnect()?