@lockerverse/react 0.2.156 → 0.2.157

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,100 @@
1
+ # Lockerverse events guide
2
+
3
+ Package: @lockerverse/react@0.2.157
4
+
5
+ Generated from this release's maintained documentation. Do not edit this copy.
6
+
7
+ Read [the shared integration guide](integration.md) first.
8
+
9
+ ## Public event listings
10
+
11
+ Connect the existing Events section instead of adding a duplicate list. Keep the
12
+ host's page structure and light/dark theme. Import only the public Events entry
13
+ and its CSS. The SDK owns loading, retry, empty states, paging, image cards, and
14
+ sharing. Keep event links as supplied. Do not add ticket checkout or registration
15
+ controls unless separately requested. Configure dates and sorting through the
16
+ hook; do not fetch and sort Events in separate page code.
17
+
18
+ ## Public event listings
19
+
20
+ Use the public Events entry to show publicly listed Events that are happening
21
+ now, start in the future, or have ended. It does not load ticket or payment UI.
22
+
23
+ ```tsx
24
+ import {
25
+ LockerversePublicEvents,
26
+ useLockerversePublicEvents,
27
+ } from "@lockerverse/react/public-events";
28
+ import "@lockerverse/react/public-events.css";
29
+
30
+ function CommunityEvents() {
31
+ const events = useLockerversePublicEvents({ communitySlug: "auburn" });
32
+ return <LockerversePublicEvents events={events} title="Events" theme="light" />;
33
+ }
34
+ ```
35
+
36
+ The hook returns `client`, `events`, `loading`, `error`, and `refresh`. The
37
+ component takes the full hook result so it can show loading, empty, and retry
38
+ states. `title` sets the visible heading, `showHeading` can hide it, and
39
+ `timeZone` controls date display. The default time zone is
40
+ `America/New_York`. Use `style` with `LockerverseStyle` tokens or `className`
41
+ to match the host site. Links open in a new tab when they use HTTP or HTTPS.
42
+ Events can include an optional `imageUrl`. The list uses image cards when an
43
+ image is present and a date tile when it is absent. The default view groups
44
+ events into "Happening now" and "Upcoming". The "Past Events" view loads on
45
+ demand and offers "Load more" for older events. Each card has a share action.
46
+ Sharing uses the event link when one exists; otherwise it uses a link to the
47
+ event card on the host page. For a one-list view, a card link can load up to
48
+ five more pages to find its Event. The visitor can still use Load more.
49
+
50
+ Pass one configuration object to the hook for a different list. The component
51
+ reads that configuration from the hook result. With `showTabs: false`, it shows
52
+ one full-width list; `includePast` selects whether that list includes ended
53
+ Events. `from`, `to`, and `sort` set the server-side date range and order.
54
+ Without `from` or `to`, a one-list view reads all publicly listed Event
55
+ history. It includes past Events by default and sorts by descending start
56
+ time, so newer Events appear first. With `includePast: false`, the default is
57
+ ascending start time for current and future Events. Each page has 20 Events.
58
+
59
+ ```tsx
60
+ const config = {
61
+ showTabs: false,
62
+ includePast: true,
63
+ from: "2026-09-01T00:00:00.000Z",
64
+ to: "2026-10-01T00:00:00.000Z",
65
+ sort: "startAtAsc",
66
+ } as const;
67
+ const events = useLockerversePublicEvents(
68
+ { communitySlug: "auburn" },
69
+ { config, initialPage }
70
+ );
71
+ return <LockerversePublicEvents events={events} />;
72
+ ```
73
+
74
+ For server rendering, obtain `initialPage` with the SDK client's `search()`
75
+ and the same date, scope, sort, and page size. Without this configuration,
76
+ `initialEvents` from `list()` keeps the original Upcoming and Past views.
77
+
78
+
79
+ Date bounds are ISO instants. An Event is included when its time overlaps the
80
+ range: `from` is inclusive and `to` is exclusive. Omit either bound when it is
81
+ not needed. `showTabs` and `includePast` are independent. Match an SSR seed to
82
+ the same community, date range, sort, and page size. Keep available data visible
83
+ when a browser refresh fails. Use the shared integration guide for static-site
84
+ limits and verification.
85
+
86
+ ## Public attendee lists
87
+
88
+ Add an attendee list only when the resource prompt requests it and public
89
+ listing is enabled. Use `createLockerversePublicApiClient` and
90
+ `getPublicEventAttendees` from `@lockerverse/sdk`; do not build the API endpoint.
91
+ The generated client takes the API **origin**, without `/api`. Use `publicApiOrigin` when supplied; otherwise derive it with
92
+ `new URL(apiBaseUrl).origin` for the supplied standard Lockerverse API URL.
93
+ Pass that client, `path: { communitySlug, eventId }`, and `throwOnError: true`
94
+ to each request. Read `data` only after success inside `try`; show a retry action
95
+ in `catch`. Pass each `data.nextCursor` as `query.cursor` until it is null.
96
+
97
+ Display only attendee names from `data.registrations`. Do not display party
98
+ size, total counts, email addresses, or other registration values. Match the
99
+ existing page and include loading, empty, and error states. The generated
100
+ public API types and the installed Core SDK README define the response.
@@ -0,0 +1,259 @@
1
+ # Lockerverse integration guide
2
+
3
+ Package: @lockerverse/react@0.2.157
4
+
5
+ Generated from this release's maintained documentation. Do not edit this copy.
6
+
7
+ ## Installed SDK integration guides
8
+
9
+ ## Read the installed contract first
10
+
11
+ For an installed project, read `node_modules/@lockerverse/react/guides/integration.md`
12
+ and the guide for the requested resource:
13
+
14
+ - `node_modules/@lockerverse/react/guides/auctions.md`
15
+ - `node_modules/@lockerverse/react/guides/payment-widgets.md`
16
+ - `node_modules/@lockerverse/react/guides/events.md`
17
+ - `node_modules/@lockerverse/react/guides/signup.md`
18
+
19
+ These files ship with each release. Their contract matches that installed
20
+ release. Also read its `README.md`, `package.json` exports, peer dependencies,
21
+ and public `.d.ts` declarations. Do not import private `dist` modules. Online
22
+ examples can describe a newer release. These guides are generated from the same
23
+ maintained documentation as the website; do not edit generated guide copies.
24
+
25
+ ## Install or upgrade without downgrading
26
+
27
+ Inspect the package manager, lockfile, and installed versions first. Treat a
28
+ version in the admin prompt as the minimum supported stable release, not a
29
+ request to replace an existing newer release. Keep `@lockerverse/react` and
30
+ `@lockerverse/sdk` on the same exact stable version. If both are already on a
31
+ newer matching stable version, keep them and read their installed guides. If the
32
+ pair is missing, older, mismatched, or lacks the required guide, select a
33
+ published matching stable release that meets the prompt minimum and is not
34
+ older than either installed stable package. Verify that both versions exist
35
+ before installing. Do not choose a development dist-tag or downgrade a package.
36
+ Use the existing package manager and update its lockfile.
37
+
38
+ Keep compatible React and React DOM versions. The current SDK supports
39
+ `^18.2.0 || ^19.2.0`; check the selected release's manifest. Do not upgrade a
40
+ compatible React 18 site to React 19. If an upgrade is needed, update React and
41
+ React DOM together without replacing the framework or router. Native payment
42
+ and auction checkout need the optional `@stripe/react-stripe-js` and
43
+ `@stripe/stripe-js` peers specified by the installed manifest. Catalog, Events,
44
+ and signup code must use their narrow imports and must not load Stripe.
45
+
46
+ ## Preserve the existing host and saved resource
47
+
48
+ Use the existing framework, router, page structure, components, and theme.
49
+ Connect the matching existing section and controls. Add one section only when
50
+ none exists. Do not create a second application, backend, router, or duplicate
51
+ interface. Change only files needed for this integration; do not edit generated
52
+ route trees. Match light/dark theme to the host and use supported props and
53
+ `--lockerverse-*` tokens with complete valid CSS values. Do not override private
54
+ SDK selectors or rebuild the supplied auction, checkout, or signup controls.
55
+
56
+ The admin prompt supplies public resource identity and requested behavior.
57
+ Load current settings from Lockerverse on each page load or refresh. Do not
58
+ copy item names, prices, order, images, dates, quantities, availability, fees,
59
+ shipping rules, or form definitions into permanent local configuration. Use
60
+ only the requested community and saved resource. Encode route values and keep
61
+ host search parameters. A URL must not select a different configured community
62
+ or resource. A mounted hook keeps one identity; remount deliberately when the
63
+ resource changes, never during an unresolved submission.
64
+
65
+ Use the supplied `apiBaseUrl` and `environment` exactly. API base URLs include
66
+ `/api`. Production is the default when neither is supplied. Do not infer the
67
+ environment from the host domain or silently use development. Lockerverse
68
+ supplies Stripe publishable keys and connected-account options. Do not add
69
+ secret keys, an unrelated Stripe account, Supabase payment tables, guessed
70
+ endpoints, or an independent payment flow.
71
+
72
+ ## Server rendering and static sites
73
+
74
+ On an existing SSR host, load public data with the matching SDK client in the
75
+ framework's server route or server function. Seed the matching React hook and
76
+ keep available content visible during refresh. Render public text, images,
77
+ links, and metadata in the first HTTP response. Keep Stripe initialization and
78
+ browser-storage access in the browser. Use the product guide for exact seed
79
+ arguments and loading behavior.
80
+
81
+ On an existing static Vite site, preserve its client-loaded flow. Explain that
82
+ current item-specific first-response content and metadata require an SSR
83
+ response or another static build. Do not add a per-site server or replace the
84
+ framework solely for this integration. A browser-only title change is not
85
+ server-rendered metadata. The host owns canonical URLs, document metadata,
86
+ sitemaps, robots rules, and its indexing policy.
87
+
88
+ ## Private data and submission state
89
+
90
+ Never put contact details, payment tokens, or recovery records in URLs, public
91
+ loader data, metadata, analytics, or logs. Use public read data only in SSR
92
+ responses. Do not submit live payments, bids, or signup records during an
93
+ implementation check. Use the product's completion callback as documented;
94
+ navigation, dialog closure, and receipt amounts are not proof of payment.
95
+
96
+ Payment-widget recovery and auction recovery have different contracts. Payment
97
+ widget recovery contains a payment reference and connected account and can be
98
+ stored as specified in its guide. Auction purchase recovery includes buyer data
99
+ and a Stripe token: keep it private and in memory by default. Do not persist it
100
+ merely because widget recovery can be persisted. Never replace an unresolved
101
+ operation with a fresh payment or automatically retry an uncertain bid.
102
+
103
+ ## Verify the integration
104
+
105
+ Build with the host's existing commands. Check desktop and 390 by 844 mobile
106
+ layouts for overflow, readable content, and reachable controls. Check loading,
107
+ empty, error, retry, unavailable, and ready states as applicable. Check route
108
+ direct entry, reload, Back/Forward, and native new-tab links. For SSR, inspect
109
+ the raw first HTTP response, then check hydration and live refresh. Open
110
+ checkout only to inspect saved settings; do not submit a transaction. Use SDK
111
+ simulation pages for result layouts. Report verified checks and any limits.
112
+
113
+ ## Configuration and environment
114
+
115
+ Production is the default. Payment, signup, auction, and Events hooks accept
116
+ `apiBaseUrl` and `environment` together. A custom URL requires an explicit
117
+ environment; `environment: "development"` also requires a URL. Include `/api`
118
+ in the API base URL. Do not infer the environment from the host website's URL.
119
+ Use the public community and resource slugs from the intended integration.
120
+ Signup uses `signupSlug`; payment uses `widgetSlug`.
121
+
122
+ The backend supplies the Stripe publishable key and connected account. Do not
123
+ hard-code either value or pass a secret key. The default Stripe loader handles
124
+ initialization. If a host supplies `stripeLoader={loadStripe}`, preserve all
125
+ loader arguments, including the connected-account options.
126
+
127
+ ```tsx
128
+ const widget = useLockerverseWidget({
129
+ apiBaseUrl: "https://portal-dev.lockerverse.com/api",
130
+ communitySlug: "luis-c",
131
+ environment: "development",
132
+ widgetSlug: "new-payment-widget",
133
+ });
134
+
135
+ <LockerversePayment
136
+ selection={[{ productSlug: "adult", quantity: 1 }]}
137
+ widget={widget}
138
+ />
139
+ ```
140
+
141
+ ## Server rendering
142
+
143
+ Load public data with the matching core SDK client in a server route or loader,
144
+ then pass that validated snapshot to the React hook. The second argument is
145
+ optional; without it, the hook keeps its loading state until the browser read
146
+ completes. The seed is read once on mount and is retained if revalidation
147
+ fails. A later seed prop change does not replace live data. Remount with a new
148
+ React `key` when the resource identity changes.
149
+
150
+ ```tsx
151
+ import { createLockerversePublicEventsClient } from "@lockerverse/sdk/public-events";
152
+
153
+ // Call this from a server route or loader.
154
+ export async function loadPublicEvents() {
155
+ return createLockerversePublicEventsClient({ communitySlug: "auburn" }).list();
156
+ }
157
+ ```
158
+
159
+ ```tsx
160
+ import type { LockerversePublicEvent } from "@lockerverse/sdk/public-events";
161
+ import { useLockerversePublicEvents } from "@lockerverse/react/public-events";
162
+
163
+ export function CommunityEvents({ initialEvents }: { initialEvents: LockerversePublicEvent[] }) {
164
+ const events = useLockerversePublicEvents(
165
+ { communitySlug: "auburn" },
166
+ { initialEvents }
167
+ );
168
+ return <h1>{events.events?.[0]?.name ?? "Events"}</h1>;
169
+ }
170
+ ```
171
+
172
+ Payment uses `createLockerverseCheckoutClient(options).load()` on the server
173
+ and `useLockerverseWidget(options, { initialCatalog })` in the React component.
174
+ Signup uses `createLockerverseSignupClient(options).load()` and
175
+ `useLockerverseSignup(options, { initialSignup })`. Use matching options on
176
+ both sides. An empty `initialEvents: []` is valid. Use the exact public SDK
177
+ client result, not unvalidated server JSON or a stored payment quote. Do not
178
+ put personal information, secret keys, or payment recovery data in the seed.
179
+ The browser still requests current public data after mount. A failed refresh
180
+ retains the last good snapshot and exposes `error` and `refresh`; loading means
181
+ a read is in progress, not that the snapshot is unavailable. Signup and event
182
+ content remain visible during refresh. Payment shows the seeded catalog heading
183
+ and public base product prices, but keeps submit controls behind a loading state
184
+ until the catalog refresh finishes. Payment quotes remain authoritative from
185
+ the checkout client. A refreshed signup definition removes obsolete custom
186
+ field choices from the form and submission while preserving valid answers.
187
+
188
+ In Next.js, use a request-local server loader (for example, `React.cache`) to
189
+ avoid duplicate reads in one request. Use `no-store` for changing public
190
+ auction data and allow the auction hook to refresh after mount. A static site
191
+ can refresh after hydration but cannot produce item-specific first-response
192
+ metadata without a build or server response for each item.
193
+
194
+ Keep browser storage and payment recovery behind a client-only boundary where
195
+ the host needs one. Keep those accesses in effects, not at module scope or
196
+ during server rendering. For TanStack Router, import `ClientOnly` from
197
+ `@tanstack/react-router` and put the recovery owner and checkout interaction
198
+ inside it:
199
+
200
+ ```tsx
201
+ import { ClientOnly } from "@tanstack/react-router";
202
+
203
+ <ClientOnly fallback={<p>Loading checkout...</p>}>
204
+ <Checkout />
205
+ </ClientOnly>
206
+ ```
207
+
208
+ The host supplies this boundary; TanStack Router is not an SDK dependency.
209
+ Public catalog and item content can remain outside it. Wait for saved recovery
210
+ state to load before mounting payment. Remount the recovery owner when its
211
+ resource or recovery key changes.
212
+
213
+ ## Resource identity
214
+
215
+ A mounted hook or widget keeps one resource identity. Do not change its API,
216
+ environment, community slug, widget slug, or signup slug. To show a different
217
+ resource, remount the owning component with a new React `key`:
218
+
219
+ ```tsx
220
+ <Checkout
221
+ key={`${communitySlug}:${widgetSlug}`}
222
+ communitySlug={communitySlug}
223
+ widgetSlug={widgetSlug}
224
+ />
225
+ ```
226
+
227
+ Selection, theme, callbacks, and other view properties can change without a
228
+ remount. `refresh()` reloads the same resource.
229
+
230
+ ## Styling
231
+
232
+ Auction checkout, payment, and signup use common email, phone, field-error, and checkbox controls. Payment and signup share the custom-field renderer. Phone fields use the lightweight payment/signup country list, normalization, and Valibot format validation. The shared phone control is imported directly, with no separate phone chunk or metadata library. Each flow keeps its existing field configuration and backend rules.
233
+
234
+ Payment and auction Stripe forms resolve the rendered SDK font and theme tokens before passing them to Stripe. Custom font files are not loaded into Stripe by a font family name alone. See [the shared form foundation](https://github.com/Lockerverse/lockerverse-sdk/blob/main/docs/shared-form-foundation.md) for module boundaries and bundle measurement.
235
+
236
+ Use `theme="dark"` or `theme="light"` to match the host background. The outer payment, signup, auction, and Events widgets are transparent, so the host controls their canvas. Lockerverse applies the community branding returned by the widget API. Pass the same `LockerverseStyle` object to payment, signup, and donate launcher components.
237
+
238
+ ```tsx
239
+ import type { LockerverseStyle } from "@lockerverse/react";
240
+
241
+ const lockerverseStyle = {
242
+ "--lockerverse-accent": "#ff6b35",
243
+ "--lockerverse-bg": "#fffaf0",
244
+ "--lockerverse-control": "#f5eddf",
245
+ "--lockerverse-radius": "14px",
246
+ "--lockerverse-text": "#211c17",
247
+ } satisfies LockerverseStyle;
248
+
249
+ <LockerversePayment
250
+ selection={selection}
251
+ style={lockerverseStyle}
252
+ widget={widget}
253
+ />
254
+ ```
255
+
256
+ The canonical `--lockerverse-*` tokens control every component. Existing
257
+ `--lockerverse-signup-*` tokens remain supported as signup-only aliases.
258
+
259
+ The package keeps React, React DOM, and Stripe's React libraries as peer dependencies so it does not ship duplicate framework code. `LockerversePayment` leaves product selection to its host. `LockerverseDonateLauncher` provides selection from the existing widget catalog. Neither component depends on Lockerverse's Next.js application components.