@fonderie/vue-workspaces
@fonderie/vue-workspaces
Vue 3 composables for Fonderie workspaces — useWorkspaces,
useCreateWorkspace, useMembers, useRemoveMember, useInvitations,
useAcceptInvitation, useWorkspaceSettings, and role management
(useRoles, useUpdateRole, useSetRolePermissions, useMemberRoles —
@fonderie/permissions has no HTTP API of its own; role CRUD lives under
@fonderie/workspaces' routes). Thin bindings over
@fonderie/client:
reactive refs for loading/error/data state and the request itself, nothing
else. Bring your own UI.
Install
npm install @fonderie/vue-workspaces
One client at the root (recommended)
Install the plugin from @fonderie/vue once (or call
provideFonderie(client) in a root setup()) and every composable resolves
the client by injection — no client argument at call sites:
import { FonderiePlugin } from "@fonderie/vue";
createApp(App).use(FonderiePlugin, client).mount("#app");
// in any component setup():
const { ...state } = useWorkspaces();
Passing a client explicitly (as below) still works everywhere and takes precedence over injection — handy in tests and multi-client apps.
Use
<script setup>
import { FonderieClient } from '@fonderie/client';
import { useWorkspaces, useMembers } from '@fonderie/vue-workspaces';
const client = new FonderieClient({ baseUrl: 'https://api.example.com/v1' });
const { workspaces } = useWorkspaces(client.workspaces);
const { members } = useMembers(client.workspaces);
</script>
<template>
<select @change="(e) => client.workspaces.setWorkspaceId(e.target.value)">
<option v-for="ws in workspaces" :key="ws.id" :value="ws.id">{{ ws.name }}</option>
</select>
<ul>
<li v-for="m in members" :key="m.userId">{{ m.userId }} — {{ m.roleName }}</li>
</ul>
</template>
Each composable takes the same WorkspacesClient instance
(client.workspaces) — construct one FonderieClient at the app root and
pass it down (provide/inject or a prop). The client's access token is shared
with client.auth automatically, so signing in via
@fonderie/vue-auth
is enough to authenticate workspace requests too. Requests default to the
caller's personal workspace until you call
client.workspaces.setWorkspaceId(id) to scope them to a team.
Want pre-built screens instead of wiring your own team list?
See @fonderie/vue-workspaces-screens.
Why this exists
You've shipped this plumbing before — auth, teams, billing, messaging —
and the next project will ask for it again. Fonderie packages it once:
plain TypeScript modules for
@fonderie/core,
PostgreSQL-backed, self-hosted, MIT. No external control plane, no
per-seat anything. Register the modules you need; skip the ones you don't.
This package owns the Vue binding for workspaces — reactive state
management around @fonderie/client, nothing more. No business logic lives
here; it lives in @fonderie/workspaces on the server.
Browse the whole set at fonderiejs/fonderie · follow @fonderiejs
License
MIT © Fonderie, Inc.
Related Packages
Pre-built Vue workspaces screens for Fonderie — team members, invitations.
Vue 3 composables for Fonderie's outgoing webhooks — thin bindings over @fonderi...
Vue 3 composables for Fonderie's customers module — thin bindings over @fonderie...
Vue 3 composables for Fonderie billing — thin bindings over @fonderie/client.
Version History
| Version | Released | License |
|---|---|---|
| 0.16.0 | MIT | |
| 0.15.0 | MIT | |
| 0.14.0 | MIT | |
| 0.13.0 | MIT | |
| 0.12.0 | MIT | |
| 0.11.0 | MIT | |
| 0.10.2 | MIT | |
| 0.10.1 | MIT | |
| 0.10.0 | MIT | |
| 0.9.0 | MIT | |
| 0.8.1 | MIT | |
| 0.8.0 | MIT | |
| 0.7.5 | MIT | |
| 0.7.4 | MIT | |
| 0.7.3 | MIT | |
| 0.7.2 | MIT | |
| 0.7.1 | MIT | |
| 0.7.0 | MIT | |
| 0.6.0 | MIT | |
| 0.5.0 | MIT | |
| 0.4.0 | MIT | |
| 0.3.0 | MIT | |
| 0.2.0 | MIT | |
| 0.1.0 | MIT |