@msflib/react-workspace¶
Standalone workspace module built on TanStack Query.
Install¶
pnpm add @msflib/react-workspace
Peer deps¶
- react >= 18
- @tanstack/react-query >= 5
Usage¶
Wrap your app with the module
| Prop | Type | Required | Description |
|---|---|---|---|
children |
React.ReactNode |
Yes | Child component tree. |
options |
object |
No | Configuration options for the provider. See below for details. |
options Configuration¶
| Key | Type | Default | Description |
|---|---|---|---|
isWorkspaceScoped |
boolean |
true |
If true, workspaces are isolated per workspace. |
requireAuth |
boolean |
false |
If true, workspaces will only be fetched when isAuthenticated is true. |
isAuthenticated |
boolean |
false |
The authentication status of the user (e.g. from useAuth().status). |
pathWorkspaceScope.available |
boolean |
true |
Whether the available workspaces query is workspace-scoped. Set to false if your backend serves GET /workspaces/available without a workspace prefix/header. |
In Next.js App Router, Provider must be in a client component (
"use client").
Per-endpoint workspace scoping¶
list, get, create, update, and delete are always workspace-scoped. available is configurable because some backends expose it as a global, cross-workspace listing rather than a per-workspace resource:
<WorkspaceProvider options={{ pathWorkspaceScope: { available: false } }}>
{children}
</WorkspaceProvider>
This relies on @msflib/core's workspace-scoping registry treating explicit opt-outs as an override, even when a broader path (like /workspaces) is already registered as scoped — see @msflib/core's resolveWorkspaceScopedEndpoint/isWorkspaceScopedEndpoint. It only affects the path tenancy strategy today; the header strategy (workspaceHookDecorator('header')) does not yet consult per-endpoint scoping and always attaches the workspace header when a workspace is active.