• v0.18.4
    v0.18.4

    All packages now provide an isReadOnly flag on user instances. It is available when getting self or others. isReadOnly is true when storage is read-only, see the room management guide for more information.

    const me = room.getSelf();
    me.isReadOnly; // boolean
    const others = room.getOthers();for (const other of others) { other.isReadOnly; // boolean}

    In @liveblocks/client:

    • Add a new option shouldInitiallyConnect to client.enter that let you control whether or not the room connects to Liveblocks servers. Default is true.

      Usually set to false when the client is used from the server to not call the authentication endpoint or connect via WebSocket.

    In @liveblocks/react:

    • Add a new property shouldInitiallyConnect to RoomProvider that let you control whether or not the room connects to Liveblocks servers. Default is true.

      By default equals to typeof window !== "undefined", meaning the RoomProvider tries to connect to Liveblocks servers only on the client side.

    • Internal package restructurings to increase code sharing. You may notice a new dependency show up in your dependency tree: @liveblocks/core. It contains private APIs that aren't intended for direct consumption.

  • v0.18.3
    v0.18.3
    • In @liveblocks/react:

      Fixes the "zombie-child" problem that can occur with React 17 or lower. If you’re on React 18: great, you can ignore this! If you’re using React 17 or lower with Liveblocks, we’ll now start to enforce that you pass the unstable_batchedUpdates prop to RoomProvider, so this problem can be circumvented. This small addition may save you hours of debugging time!

      // ⚠️  Only if you’re using React 17 or lowerimport { unstable_batchedUpdates } from "react-dom";  // 👈
      <RoomProvider id="my-room" initialPresence={...} initialStorage={...} unstable_batchedUpdates={unstable_batchedUpdates} // 👈> <App /></RoomProvider>

      To read more, see https://liveblocks.io/docs/guides/troubleshooting#stale-props-zombie-child

    • In @liveblocks/zustand:

      • Fix a confusing error message
  • v0.18.2
    v0.18.2
    • In @liveblocks/react:

      • Make sure that useOther will not rerender if tracked users already left the room, so that child components won't get rerendered before the parent got the chance to unmount them.
      • Disallow useOther without selector
  • v0.18.1
    v0.18.1
    • In @liveblocks/react:

      • Fix a bug that could cause an error when patching presence during local development. Not an issue in production builds. (#505)
  • v0.18.0
    v0.18.0

    For information, please read our Upgrade Guide for 0.18.

    New React hooks ✨

    Breaking changes

    • Remove support for directly importing hooks from @liveblocks/client (e.g. import { useMyPresence } from '@liveblocks/react'). If you’re still using these imports, see the Upgrade Guide for 0.17 for instructions.
    • Remove ClientProvider and useClient hook
    • Remove defaultPresence and defaultStorageRoot arguments. (Just use initialPresence and initialStorage arguments now.)
    • Remove second argument to useMap(), useList(), and useObject().
    • Remove new LiveMap(null) support. (Just use new LiveMap() or new LiveMap([]).)
  • v0.17.11
    v0.17.11

    General:

    • Fix a packaging bug

    In @liveblocks/react:

    • Deprecate an undocumented API
  • v0.17.9
    v0.17.9
    • Fix bug that could cause duplicate copies of @liveblocks/client to end up in final bundle, for certain bundler configurations.
    • Fix bug where in some conditions the initial presence for a new connection would not come through to all existing clients in the room
    • Various internal changes
  • v0.17.8
    v0.17.8

    New history APIs ↩️ ↪️

    • In @liveblocks/client:

      • Add canUndo() and canRedo() utilities to room.history
      • Add "history" event type to room.subscribe() to subscribe to the current user's history changes
    • In @liveblocks/react:

      • Add useCanUndo() and useCanRedo() hooks
  • v0.17.7
    v0.17.7
    • In @liveblocks/zustand:

      • Simplify zustand middleware integration with Typescript. TPresence, TStorage, TUserMeta, and TRoomEvent are now optional.

    Note that @liveblocks/zustand does not work with zustand > v4 because v3 and v4 have completely different type definitions. As soon as zustand v4 is out of the RC phase, we will consider updating our middleware to work with the latest version.

    Let's take a look at our To-do list example. Without our middleware, the store would look like this:

    import create from "zustand";
    type State = { draft: string; isTyping: boolean; todos: Todo[]; setDraft: (draft: string) => void; addTodo: () => void; deleteTodo: (index: number) => void;};
    create<State>(/* ... */);

    With our middleware, you simply need to move the State param at the middleware level:

    import create from "zustand";import { createClient } from "@liveblocks/client";import { middleware } from "@liveblocks/zustand";
    const client = createClient({ /*...*/ });
    type State = { draft: string; isTyping: boolean; todos: Todo[]; setDraft: (draft: string) => void; addTodo: () => void; deleteTodo: (index: number) => void;};
    create( middleware<State>(/* ... */, { client, presenceMapping: { isTyping: true }, storageMapping: { todos: true } }));

    If you want to type others presence, you can use the TPresence generic argument on the middleware.

    type Presence = {  isTyping: true;}
    const useStore = create( middleware<State, Presence>(/* ... */, { client, presenceMapping: { isTyping: true }, storageMapping: { todos: true } }));
    // In your componentuseStore(state => state.liveblocks.others[0].presence?.isTyping)
  • v0.17.6
    v0.17.6
    • In @liveblocks/react:

      • Expose RoomContext in the return value of createRoomContext()
Previous
Next