@liveblocks/core
Advanced tools
Changelog
v0.19.1
Fixes an issue where import
s from Liveblocks packages could not be resolved
correctly in certain build environments.
Changelog
v0.19.0
This release brings Zustand v4 support. This is a breaking change only if you’re using @liveblocks/zustand.
In @liveblocks/zustand:
To migrate, make the following code changes:
npm install zustand@latest
npm install @liveblocks/zustand@latest
-import { middleware } from "@liveblocks/zustand";
+import { liveblocks } from "@liveblocks/zustand";
and
-import type { LiveblocksState } from "@liveblocks/zustand";
+import type { WithLiveblocks } from "@liveblocks/zustand";
and rename accordingly.create(liveblocks<MyState, ...>(...))
to the Zustand v4 recommended pattern:
create<WithLiveblocks<MyState, ...>>()(liveblocks(...))
To be clear:
liveblocks
middleware
call, and onto the create
call.MyState
type in a WithLiveblocks<...>
wrapper. This
will make sure the injected liveblocks
property on your Zustand state
will be correctly typed.()
wrapper, needed by Zustand
v4 now:
create<WithLiveblocks<MyState, ...>>()(liveblocks(...))
// ^^ Not a typo
state.liveblocks.enterRoom()
: it no longer
takes an explicit initial state. Instead, it's automatically be populated from
your Zustand state.In @liveblocks/redux:
-import { enhancer } from "@liveblocks/redux";
+import { liveblocksEnhancer } from "@liveblocks/redux";
state.liveblocks.enterRoom()
to send in an explicit
initial state is no longer supported. It will use the state in your Redux
store, for consistency and ease of use.Changelog
v0.18.5
Bug fix:
scopes
was removed from
BaseUserMeta
.Internal updates:
Changelog
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.
Changelog
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 lower
import { 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: