Upgrading to Liveblocks config file

[nvie]

This is a feedback thread for when you run into problems with converting your app to the recommended Liveblocks config setup when upgrading to 0.17. Please tell us if anything is unclear, and we're happy to help! 🙏

[talksik]

One issue I have with the react sdk is that I need to reactively join and leave a room. The RoomProvider context provider requires an id and autojoins it, which means that if at the top of my component tree, for branches I don't want to connect to a room, I don't render the RoomProvider...however, then child components using hooks like useOthers error out. I would want them to return null instead if not connected.

Any ideas on this pattern when the use case is multiple rooms?

[talksik]

okay nevermind, joining the same roomId via client.enter doesn't work as it doesn't update the data used in the react hooks

is there some workaround here?

[nvie]

You can find the documentation on shouldInitiallyConnect here: https://liveblocks.io/docs/api-reference/liveblocks-react#RoomProvider

However, I think you raise a fair point: what is the best way to reactively join/leave a room using just props? I don't think our current API makes this easy.

I would offer the following suggestion:

const roomId = 'my-room-id';
const connected = false;  // Initially false

<RoomProvider
  key={`${roomId};${connected}`}   // 👈 Could you try adding this?
  id={roomId}
  shouldInitiallyConnect={connected}
  >
  ...
</RoomProvider>

This approach will unmount/remount your RoomProvider whenever your room ID or desired connected state changes, effectively leaving/joining your room, and re-rendering the entire component tree below it.

Does that approach work for you as a workaround?

[talksik]

Thanks for the workaround! @nvie

This is quite nifty, I will try it out! Our current design does quite a bit of work on mounts within child components, so a remount might cause some issues, but I will keep you updated once I try it!

[talksik]

I believe it works out? It's quite thorny and buggy.

Because there is no useConnectionState hook, I created my own

export const useConnectionState = () => {
  const [connectionState, setConnectionState] = useState<ConnectionState>('closed')
  const room = useRoom()

  useEffect(() => {
    const unsub = room.subscribe('connection', (connectionState) => {
      setConnectionState(connectionState)
    })

    return () => {
      unsub()
    }
  }, [room])

  return connectionState
}

And this causes the room to connect a split second after the connect key turns to false. So connect is false and it doesn't connect, then I trigger connect to be true, so the whole thing remounts and connects, then I trigger it to disconnect by turning connect false, which disconnects it, but then a second later it connects again.

It reminds of me that presence issue, as I see two things firing off unexpectedly. The right action is taken first, and then there is some followup action that takes place which is the faulty one.

I'm not sure what is going on, but I believe the use of the subscribe doesn't work well with the react hooks. The shouldInitiallyConnect seems to be non-deterministic in its behavior.

I think the js sdk is more stable.

[taylorpwhipp]

Hi @talksik , I'll try to prioritize looking into this this week/ testing it out. I can't promise that I will have a solution for you by Friday, but it is on our radar and something we will try to address and troubleshoot further.