@worthai/onboarding-sdk 3.0.0-beta.0 → 3.0.0-beta.2.12.7

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.
package/README.md CHANGED
@@ -1,293 +1,165 @@
1
- # Onboarding Application
1
+ # Worth Onboarding SDK
2
2
 
3
- ## Install
3
+ The Worth Onboarding SDK embeds onboarding experiences directly into your website's DOM.
4
+ Rather than managing an iframe separately, you provide a mount point and lifecycle callbacks,
5
+ and the SDK handles rendering, execution, and teardown.
4
6
 
5
- This project uses [pnpm](https://pnpm.io) for dependency management. See
6
- [pnpm vs npm](https://pnpm.io/pnpm-vs-npm) for how pnpm differs from npm.
7
+ SDK 3 delivers improved performance, greater configurability, and seamless host application
8
+ integration compared to its predecessor (SDK 2).
7
9
 
8
- ```bash
9
- pnpm install
10
- ```
11
-
12
- ## Run Locally
13
-
14
- ### Development
10
+ > "Instead of managing an iframe, you give the SDK a mount point and a set of lifecycle callbacks."
15
11
 
16
- Start the development server:
17
-
18
- ```bash
19
- pnpm dev
20
- ```
12
+ ## Key Benefits
21
13
 
22
- Then open
14
+ - **Faster integration**: Minimize custom development and deploy Worth's onboarding quickly
15
+ - **Branded experience**: Preserve your brand while leveraging Worth's core capabilities
16
+ - **Flexible embedding**: Mount the flow into any DOM element you control
17
+ - **Type-safe communication**: Built-in TypeScript support with type-safe messaging
23
18
 
24
- ➜ Local: [http://localhost:5180](http://localhost:5180)
25
-
26
- ➜ Network: shown in your terminal output, if needed
27
-
28
- ### Optimized Build + Serve
29
-
30
- To test an optimized production build locally:
31
-
32
- ```bash
33
- pnpm build
34
- pnpm start
35
- ```
19
+ ## Scope
36
20
 
37
- Then open
38
-
39
- ➜ Local: [http://localhost:4173](http://localhost:4173)
40
-
41
- ➜ Network: shown in your terminal output, if needed
21
+ **In scope**: Applicant onboarding embedded in host DOM, JavaScript/TypeScript web SDK,
22
+ modern browser support (last 2 versions of Chrome, Firefox, Safari, Edge), client-side
23
+ rendering.
42
24
 
43
- ## Test
25
+ **Out of scope**: Non-onboarding products, mobile native SDKs, server-side rendering,
26
+ offline functionality, legacy browser support.
44
27
 
45
- Run the test suite:
28
+ ## Installation
46
29
 
47
30
  ```bash
48
- pnpm test
31
+ npm install @worthai/onboarding-sdk
49
32
  ```
50
33
 
51
- `vitest` starts in watch mode by default, which is useful during local
52
- development because it reruns tests as files change. `vitest run` runs the test
53
- suite once and exits, good for single run checks before putting a PR up for review.
34
+ ## Quick Start
54
35
 
55
- Run tests with coverage:
36
+ ### 1. Add a mount target to your page
56
37
 
57
- ```bash
58
- pnpm test:coverage
59
- ```
60
-
61
- Open the Vitest UI:
62
-
63
- ```bash
64
- pnpm test:ui
65
- ```
66
-
67
- ## Check
68
-
69
- Run quality checks:
70
-
71
- ```bash
72
- pnpm check
38
+ ```html
39
+ <div id="worth-onboarding"></div>
73
40
  ```
74
41
 
75
- PRs going into `main` will be required to pass both quality and test checks before
76
- they can be merged. Before requesting a PR into `main`, run both the quality check and the test suite locally.
42
+ ### 2. Create an instance
77
43
 
78
- ## SDK 3 Package Boundary
44
+ Initialize with your invite token and lifecycle callbacks:
79
45
 
80
- This repository is the source for the SDK 3 onboarding package surface. The SDK
81
- entrypoint is isolated from the app entrypoint so the existing `/onboarding` app
82
- build remains deployable.
46
+ - `onStepSubmit` — fires when applicants submit each step
47
+ - `onComplete` — fires upon finishing the flow
48
+ - `onError` — handles SDK or runtime errors
83
49
 
84
- ```ts
50
+ ```typescript
85
51
  import { createWorthOnboarding } from '@worthai/onboarding-sdk';
86
52
 
87
53
  const onboarding = createWorthOnboarding({
88
- apiBaseUrl: 'https://api.example.com',
89
- inviteToken: 'INVITE_TOKEN'
54
+ inviteToken: '{{YOUR_INVITE_TOKEN}}',
55
+ onStepSubmit: ({ stepId, values }) => {
56
+ console.log('Step submitted:', stepId, values);
57
+ },
58
+ onComplete: ({ values }) => {
59
+ console.log('Onboarding completed:', values);
60
+ },
61
+ onError: (error) => {
62
+ console.error('Onboarding error:', error);
63
+ },
90
64
  });
91
-
92
- await onboarding.mount('#worth-onboarding');
93
65
  ```
94
66
 
95
- The SDK owns an in-memory router for the mounted onboarding flow so customer
96
- pages do not need to serve or navigate under `/onboarding`.
97
-
98
- Production SDK usage does not require service path configuration. The SDK owns
99
- the auth, case, and integration service prefixes used by the embedded runtime.
100
- Use the optional `apiBaseUrl` option only for local, staging, or other non-default
101
- API origins.
102
- Styles are injected automatically during `mount()`. Hosts with a strict
103
- `style-src` Content Security Policy can pass `styleNonce` with their
104
- request-level CSP nonce.
105
-
106
- SDK browser storage and IndexedDB state are namespaced under
107
- `worth:onboarding-sdk` by default. Consumers can override this with
108
- `storageNamespace` for deterministic isolation, but the SDK supports one mounted
109
- onboarding runtime at a time.
110
-
111
- The SDK 3 subpath remains available for consumers that need to pin the current package
112
- boundary:
113
-
114
- ```ts
115
- import { createWorthOnboarding } from '@worthai/onboarding-sdk/sdk3';
116
- ```
67
+ Optional: use `apiBaseUrl` to target non-production environments.
117
68
 
118
- For script-tag usage, load the browser-global bundle from the package, then call
119
- `window.WorthAI.createWorthOnboarding`:
69
+ ### 3. Mount asynchronously
120
70
 
121
- ```html
122
- <script
123
- src="https://unpkg.com/@worthai/onboarding-sdk@<version>/dist-sdk/sdk3/worthai-onboarding-sdk.global.js"
124
- ></script>
125
- <script type="module">
126
- const onboarding = window.WorthAI.createWorthOnboarding({
127
- apiBaseUrl: 'https://api.example.com',
128
- inviteToken: 'INVITE_TOKEN'
129
- });
130
-
131
- await onboarding.mount('#worth-onboarding');
132
- </script>
71
+ ```typescript
72
+ await onboarding.mount('#worth-onboarding');
133
73
  ```
134
74
 
135
- Build the deployed app and SDK artifacts separately:
136
-
137
- ```bash
138
- pnpm build
139
- pnpm build:sdk
140
- ```
75
+ Wrap the mount call in try/catch to handle mount failures separately from runtime errors.
141
76
 
142
- `pnpm build` writes the deployable app to `dist/`. `pnpm build:sdk` writes
143
- package artifacts to `dist-sdk/sdk3/` and does not replace the app `dist/`
144
- output.
145
- SDK artifacts are minified by default. For a local debug SDK build with readable
146
- output and source maps, run:
77
+ ### 4. Clean up
147
78
 
148
- ```bash
149
- WORTH_SDK_DEBUG=true pnpm build:sdk
150
- ```
79
+ Call `unmount()` when routes change or components unload. SDK 3 allows only one mounted instance at a time.
151
80
 
152
- ## Folder Structure
153
-
154
- ```text
155
- .
156
- |-- README.md
157
- |-- react-vs-solid.README.md
158
- |-- package.json
159
- |-- vite.config.ts
160
- |-- src/
161
- | |-- App.tsx
162
- | |-- index.tsx
163
- | |-- routes.ts
164
- | |-- routeDefinitions.ts
165
- | |-- components/
166
- | | |-- alerts/
167
- | | |-- buttons/
168
- | | |-- card/
169
- | | |-- form/
170
- | | | |-- modular/
171
- | | | |-- inputs/
172
- | | | |-- layoutContent/
173
- | | | |-- widgets/
174
- | | |-- global/
175
- | | |-- icons/
176
- | | |-- progress/
177
- | | |-- step/
178
- | |-- lib/
179
- | | |-- axios/
180
- | | |-- flowComposer/
181
- | | | |-- componentRegistry/
182
- | | | | |-- catalogs/
183
- | | | |-- db/
184
- | | | |-- flow/
185
- | | | |-- form/
186
- | | | |-- rules/
187
- | | | |-- schema/
188
- | | |-- google/
189
- | | |-- storage/
190
- | |-- pages/
191
- | | |-- Composer/
192
- | | | |-- editor/
193
- | | | |-- steps/
194
- | | |-- Login/
195
- | |-- services/
196
- | |-- auth/
197
- | |-- case/
81
+ ```typescript
82
+ onboarding.unmount();
198
83
  ```
199
84
 
200
- ## Core FlowComposer Feature
201
-
202
- `FlowComposer` is the schema-driven engine for the onboarding journey. It reads
203
- the flow definition, resolves the current step, renders the matching UI
204
- components, and manages step-to-step progression so forms can be updated by
205
- changing configuration instead of rebuilding screens by hand.
206
-
207
- ## Catalog Pattern
208
-
209
- A catalog is the typed source of truth for what the schema is allowed to describe. In Flow Composer,
210
- catalogs define supported field, layout, widget, and custom step types, including their metadata and
211
- configuration schemas.
212
-
213
- Catalogs do not render UI. They answer, "is this a valid thing the schema can ask for?"
214
-
215
- ## Registry Pattern
85
+ ### Framework Integration
216
86
 
217
- A registry maps known catalog entries to the renderer functions that produce UI at runtime. In Flow
218
- Composer, the component registry takes validated schema items and resolves the field, layout, widget, or
219
- step renderer that should handle each item.
87
+ In React or similar frameworks, create the instance once, mount during component
88
+ initialization, and unmount in the cleanup function of your effect/lifecycle hook.
220
89
 
221
- The catalog defines what exists. The registry decides how a known item becomes UI.
90
+ ### Content Security Policy
222
91
 
223
- ## Flow Composer Routes
92
+ If your page enforces a strict `style-src` CSP, pass your nonce so injected styles aren't blocked:
224
93
 
225
- - `/flow`: Renders the current `schema.json` and reflects the flow experience users would see.
226
- - `/flow/editor`: Admin-focused route with a Monaco editor attached to `StepContainer` for live schema editing.
94
+ ```typescript
95
+ createWorthOnboarding({
96
+ // ...
97
+ styleNonce: window.__CSP_NONCE__,
98
+ });
99
+ ```
227
100
 
228
- ## Route Params: `:formKey` and `:stepKey`
101
+ ### Error Handling
229
102
 
230
- Flow routes include dynamic params to identify what should be rendered:
103
+ Use `isWorthOnboardingError()` to identify Worth-specific errors and branch on their `code` property.
231
104
 
232
- - `:formKey` identifies which form definition is active.
233
- - `:stepKey` identifies the specific step within that form.
105
+ ## Migrating from SDK 2
234
106
 
235
- Example pattern:
107
+ The migration shifts iframe ownership from your application to the SDK itself. Instead of
108
+ creating and managing an iframe with `postMessage` subscriptions, you now mount an embedded
109
+ runtime into a DOM element.
236
110
 
237
- `/flow/:formKey/:stepKey`
111
+ **Key architectural shift:** With SDK 2, your host page creates and manages a Worth iframe
112
+ directly. With SDK 3, you give the SDK a DOM element and it mounts, renders, and tears down
113
+ the onboarding runtime for you — no iframe and no `postMessage` subscription required.
238
114
 
239
- Example concrete URL:
115
+ ### Feature Comparison
240
116
 
241
- `/flow/company-info/get-started`
117
+ | Aspect | SDK 2 | SDK 3 |
118
+ | ---------- | -------------------------------------- | ---------------------------------------------------------- |
119
+ | Rendering | Host-managed iframe | SDK-managed DOM mount |
120
+ | Setup | `createOnboardingApp()` | `createWorthOnboarding()` |
121
+ | Mounting | `appendChild(iframe)` | `await onboarding.mount(target)` |
122
+ | Events | `subscribe()` + postMessage | Typed callbacks (`onStepSubmit`, `onComplete`, `onError`) |
123
+ | Navigation | Manual (`next()`, `prev()`, `skip()`) | SDK-owned (not exposed) |
124
+ | Styling | `setCustomCss()` | Auto-injected on mount |
125
+ | Cleanup | `unsubscribe()` + `cleanup()` | `unmount()` |
242
126
 
243
- In practice, these params let the app deep-link to a specific form and step,
244
- and are what flow navigation uses to move between steps in a predictable way.
127
+ ### SDK 3 Basic Setup
245
128
 
246
- ### Current Limitation
129
+ ```typescript
130
+ const onboarding = createWorthOnboarding({
131
+ inviteToken: 'INVITE_TOKEN',
132
+ onComplete: ({ values }) => {},
133
+ onError: (error) => {},
134
+ });
247
135
 
248
- The editor currently does not write changes back to files. Any live schema
249
- edits in `/flow/editor` are in-memory only and will be lost on page refresh
250
- until persistence is implemented.
136
+ await onboarding.mount('#worth-onboarding');
251
137
 
252
- ## Application Tech Stack
138
+ onboarding.unmount(); // cleanup
139
+ ```
253
140
 
254
- | Technology | Purpose |
255
- | --- | --- |
256
- | [`solid-js`](https://docs.solidjs.com/) | Provides the reactive UI framework used to build the application. |
257
- | [`@solidjs/router`](https://docs.solidjs.com/solid-router) | Handles client-side routing for the Solid application. |
258
- | [`@solid-primitives/utils`](https://primitives.solidjs.community/package/utils/) | Provides shared utility helpers that complement Solid's reactive primitives. |
259
- | [`@modular-forms/solid`](https://modularforms.dev/) | Provides form state management and validation helpers for Solid components. |
260
- | [`vite`](https://vite.dev/guide/) | Provides the development server and production build tooling for the app. |
261
- | [`typescript`](https://www.typescriptlang.org/docs/) | Adds static typing and compile-time checks for the application code. |
262
- | [`@biomejs/biome`](https://biomejs.dev/) | Provides code formatting and linting to keep the codebase consistent. |
263
- | [`markdownlint-cli2`](https://github.com/DavidAnson/markdownlint-cli2) | Runs markdown linting and automatic fixes for project documentation. |
264
- | [`tailwindcss`](https://tailwindcss.com/docs) | Provides utility-first CSS classes for styling the application. |
265
- | [`daisyui`](https://daisyui.com/) | Adds Tailwind CSS component classes and themes for faster UI development. |
266
- | [`tailwind-merge`](https://github.com/dcastil/tailwind-merge) | Resolves conflicting Tailwind CSS classes when composing class strings. |
267
- | [`@fontsource/figtree`](https://fontsource.org/fonts/figtree) | Provides the Figtree font as an installable package for application styling. |
268
- | [`axios`](https://axios-http.com/docs/intro) | Handles HTTP requests to backend services and external APIs. |
269
- | [`axios-retry`](https://github.com/softonic/axios-retry) | Adds retry behavior to Axios requests for transient network or service failures. |
270
- | [`dexie`](https://dexie.org/docs/) | Provides a friendly IndexedDB wrapper for local browser storage. |
271
- | [`zod`](https://zod.dev/) | Defines and validates runtime schemas for application data. |
272
- | [`jsonc-parser`](https://github.com/microsoft/node-jsonc-parser) | Parses and edits JSON with comments for configuration-like content. |
273
- | [`lodash`](https://lodash.com/docs/) | Provides general-purpose utility functions for working with collections, objects, and values. |
274
- | [`libphonenumber-js`](https://gitlab.com/catamphetamine/libphonenumber-js) | Parses, formats, and validates phone numbers. |
275
- | [`@googlemaps/js-api-loader`](https://googlemaps.github.io/js-api-loader/) | Loads the Google Maps JavaScript API on demand from application code. |
276
- | [`@googlemaps/places`](https://www.npmjs.com/package/@googlemaps/places) | Provides Google Places API client utilities and types for place-related features. |
277
- | [`monaco-editor`](https://microsoft.github.io/monaco-editor/) | Provides the browser-based code editor used for rich editing experiences. |
278
- | [`monaco-json`](https://github.com/microsoft/monaco-json) | Adds JSON language support and validation features to Monaco editor. |
141
+ ### Migration Steps
279
142
 
280
- ## Why SolidJS
143
+ 1. Update package version
144
+ 2. Add mount target element
145
+ 3. Remove old stylesheet imports
146
+ 4. Replace `createOnboardingApp` with `createWorthOnboarding`
147
+ 5. Move event handlers to callbacks (`onComplete`, `onError`)
148
+ 6. Add `onStepSubmit` if analytics/auditing needed
149
+ 7. Handle CSP nonce if applicable
150
+ 8. Remove iframe navigation methods
151
+ 9. Replace cleanup with `unmount()`
152
+ 10. Test full flow end-to-end
281
153
 
282
- SolidJS was chosen over React because of its fine-grained reactivity model. React relies on repeated component renders,
283
- meaning each state change can trigger broader recalculation across the component tree.
154
+ ## Documentation Links
284
155
 
285
- In contrast, Solid updates only the exact reactive nodes that depend on a changed value.
286
- There is no full component re-execution; only the minimal set of dependent expressions re-run.
156
+ - [Overview](https://docs.worthai.com/onboarding-sdk-3/overview)
157
+ - [Quick Start Guide](https://docs.worthai.com/onboarding-sdk-3/quickstart)
158
+ - [Migration Guide (SDK 2 → SDK 3)](https://docs.worthai.com/onboarding-sdk-3/migrate)
159
+ - [API Reference](https://docs.worthai.com/onboarding-sdk-3/api-reference)
160
+ - [Full Documentation](https://docs.worthai.com/introduction)
161
+ - [Sample SDK initialization](https://docs.worthai.com/onboarding-sdk-3/sample-scenario)
287
162
 
288
- This distinction is core to the architecture. Flow Composer is highly dynamic, and its performance and
289
- predictability depend on updating only what actually changed. Solid's reactive model maps directly to that
290
- requirement, making it a better fit for this system.
163
+ ## Support
291
164
 
292
- For deeper SolidJS reading, see [`react-vs-solid.README.md`](react-vs-solid.README.md) and
293
- [Solid.js Best Practices](https://www.brenelz.com/posts/solid-js-best-practices/).
165
+ Questions or issues: [support@joinworth.com](mailto:support@joinworth.com)