@picked/client 0.0.1-dev.1776662399138 → 0.0.1-dev.1776837084253

package/dist/docs/sdk/conditions.md

@@ -4,13 +4,15 @@ layout: docs
 
 # Conditions
 
-Conditions evaluate of the current state of the Picked client to decide outcomes as defined by the user. Conditions are `JsonLogic`, which will always return the same result given the same input.
+Conditions use JSON Logic to evaluate client state. Use them to gate experience activation, branch step navigation, and control field visibility.
 
-## Conditions in Experiences
+## Conditions in experiences
 
-A common method of navigating a Funnel Experiences is using conditions between steps. The condition will evaludate values from the Picked state, and navigation the user based on a boolean value
+A common pattern is using conditions between steps to branch the flow based on form responses:
 
 ```ts
+import { createExperience } from '@picked/client/plugins/create-experience'
+
 const questionaireFunnel = createExperience({
   id: 'mini-funnel',
   // experience config
@@ -30,7 +32,7 @@ const isSigningUpForNewsletter = funnel.addConditional({
   condition: {
     '==': [
       {
-        var: 'responses.sign-up-for-newsletter-field', // check if response value for the field is true
+        var: 'responses.sign-up-for-newsletter-field',
       },
       true,
     ],
@@ -43,11 +45,13 @@ isSigningUpForNewsletter.addTrue(signUserUpToNewsletter)
 isSigningUpForNewsletter.addFalse(userDoesNotWantNewsletter)
 ```
 
-## Conditional Fields
+## Conditional fields
 
-Fields can be shown or hidden based on previous responses or predicates using JSON Logic conditions:
+Fields can be shown or hidden based on previous responses or [predicates](./predicates) using JSON Logic conditions:
 
 ```ts
+import { createField } from '@picked/client/plugins/create-experience'
+
 // Show email field only if user selected "email" as a contact method
 export const emailField = createField({
   id: 'email-input',
@@ -60,7 +64,7 @@ export const emailField = createField({
     in: [
       'email',
       {
-        var: 'responses.communication-methods', // Reference previous field
+        var: 'responses.communication-methods',
       },
     ],
   },
@@ -87,11 +91,13 @@ export const mailingAddressField = createField({
 })
 ```
 
-## Field Options with Conditions
+## Field options with conditions
 
 Individual options within a field can also have conditional visibility:
 
 ```ts
+import { createField } from '@picked/client/plugins/create-experience'
+
 export const contactMethodsField = createField({
   id: 'contact-methods',
   name: 'contact-methods',

package/dist/docs/sdk/experiences.md

@@ -4,38 +4,41 @@ layout: docs
 
 # Experiences
 
-Experiences enable you to conditionally show UI components in your application based on custom logic. Each experience defines a component to render, where to inject it in the DOM, and an optional condition that controls when it appears. Experiences support multi-step flows with fields and branching logic, making them ideal for onboarding, surveys, and interactive product tours
+Define experiences in code with `createExperience()`, or load them from the dashboard at runtime with the [Dynamic Experiences Plugin](./plugins/dynamic-experiences).
 
-## Creating Experiences
+## Creating experiences
 
 ```ts
 import { createExperience } from '@picked/client/plugins/create-experience'
+import { adaptSvelteComponent } from '@picked/svelte'
+import appCss from '../app.css?inline'
 
 export const productPageExperience = createExperience({
   id: 'product-page-experience',
-  name: 'Product Page Experience,
+  name: 'Product Page Experience',
   condition: {
     '==': [
-        {
-            var: 'location.pathname',
-        },
-        '/product/',
-    ]
-  }
+      { var: 'location.pathname' },
+      '/product/',
+    ],
+  },
   targets: [{ selector: 'body', placement: 'after' }],
-  component: adaptSvelteComponent(import('../ui/ProductPageExperience.svelte', {
-    css: [appCss],
-  }),
+  component: adaptSvelteComponent(
+    import('../ui/ProductPageExperience.svelte'),
+    { css: [appCss] },
+  ),
 })
 ```
 
-## How Experiences Work
+Register experiences using the [Create Experience Plugin](./plugins/create-experience) for code-defined experiences, or the [Dynamic Experiences Plugin](./plugins/dynamic-experiences) to fetch and manage them from the dashboard at runtime.
+
+## How experiences work
 
 When an experience is registered, the SDK follows this execution flow:
 
-1. **Registration**: Experiences are registered to the Picked client using [createExperiencePlugin](./plugins/create-experience.md) for code-defined experiences, or [dynamicExperiencesPlugin](./plugins/dynamic-experiences.md) for dashboard-managed experiences
-2. **Condition Evaluation**: The SDK evaluates the experience's `condition` using the logic engine to determine if it should be shown
-3. **Target Resolution**: The SDK searches the DOM for elements matching the `targets` selectors (e.g., `body`, `.product-page`, `#checkout`)
+1. **Registration**: Experiences are registered to the Picked client using [createExperiencePlugin](./plugins/create-experience) for code-defined experiences, or [dynamicExperiencesPlugin](./plugins/dynamic-experiences) for dashboard-managed experiences
+2. **Condition evaluation**: The SDK evaluates the experience's `condition` using the logic engine to determine if it should be shown
+3. **Target resolution**: The SDK searches the DOM for elements matching the `targets` selectors (e.g., `body`, `.product-page`, `#checkout`)
 4. **Initialization**: If the condition evaluates to `true` and at least one target element exists, the experience is initialized
-5. **Component Rendering**: The experience's component is rendered and injected into the DOM at the specified target location and placement (before, after, append, prepend, or replace)
-6. **Flow Execution**: If the experience contains steps, fields, and conditionals, users can progress through the multi-step flow with validation and branching logic
+5. **Component rendering**: The experience's component is rendered and injected into the DOM at the specified target location and placement (before, after, append, prepend, or replace)
+6. **Flow execution**: If the experience contains steps, fields, and conditionals, users can progress through the multi-step flow with validation and branching logic

package/dist/docs/sdk/features.md

@@ -4,9 +4,9 @@ layout: docs
 
 # Features
 
-Features enable A/B testing and feature flagging in your application. Each feature defines decision logic that resolves to a `bucket` as either a boolean value (`true`/`false`) or a string value (like `"control"`, `"variant-a"`, or `"variant-b"`). Once a feature is decided, the result is cached in browser storage to ensure consistent user experiences across sessions.
+Define feature flags with a `decide` function that resolves to a bucket value, access results through framework hooks, and invalidate cached decisions by bumping the version.
 
-## Defining Features
+## Defining features
 
 Define features when creating the Picked client by passing a `features` object. Each feature requires a unique identifier, a versioning key, a human-readable name, and a `decide` function:
 
@@ -51,7 +51,7 @@ features: {
 }
 ```
 
-## How Features Work
+## How features work
 
 When a feature is registered, the SDK follows this execution order:
 
@@ -61,7 +61,7 @@ When a feature is registered, the SDK follows this execution order:
 4. **Storage**: Once resolved, the bucket value is persisted to browser storage for consistency across page loads
 5. **Event Emission**: A `feature_decide` event is fired on the event bus when a feature is resolved for the first time
 
-## URL-Based Overrides
+## URL-based overrides
 
 You can override feature decisions via URL search parameters for testing purposes:
 
@@ -79,7 +79,7 @@ The format is `?picked-feature=<feature-id>:<bucket-value>`.
 
 This is useful for QA testing specific feature variants without modifying code. The override is persisted in session storage and will be cleared when the browser tab is closed.
 
-## Accessing Features
+## Accessing features
 
 Once features are defined, you can access their resolved bucket values in your application code. The SDK provides framework-specific hooks and a framework-agnostic event bus for subscribing to feature decisions.
 
@@ -132,7 +132,7 @@ function MyComponent() {
 
 :::
 
-## Using Features in Experience Conditions
+## Using features in experience conditions
 
 Features can be used with experience conditions via JSON logic:
 
@@ -156,7 +156,7 @@ const myExperience = createExperience({
 })
 ```
 
-## Listening to Feature Decisions
+## Listening to feature decisions
 
 Subscribe to the `feature_decide` event to track when features are resolved:
 
@@ -206,7 +206,7 @@ features: {
 
 For features managed through the dashboard, versioning is handled automatically — the dashboard appends the version number to the cache key used by the SDK.
 
-## Best Practices
+## Best practices
 
 - **Use `session` storage for temporary tests**: Set `storage: 'session'` for short-lived experiments that shouldn't persist across browser sessions
 - **Keep `decide` functions fast**: The function blocks experience rendering, so avoid heavy computations or slow network calls

package/dist/docs/sdk/fields.md

@@ -4,9 +4,9 @@ layout: docs
 
 # Fields
 
-Fields are used to store data for a Picked instance. Fields can be added to steps or forms and rendered as inputs, or have their values directly set.
+Define fields in code with `createField()`, validate input with JSON Logic, and read submitted values through step context.
 
-## Defining Fields
+## Defining fields
 
 Define fields using `createField()` from the `@picked/client/plugins/create-experience` package. Each field requires a unique identifier, name, type, label, and cardinality:
 
@@ -52,7 +52,7 @@ export const communicationMethods = createField({
 })
 ```
 
-## How Fields Work
+## How fields work
 
 When a field is registered and used in an experience:
 
@@ -63,7 +63,7 @@ When a field is registered and used in an experience:
 5. **Storage**: Valid responses are stored in the experience state under `responses[field.name]`
 6. **Reference**: Field values can be referenced in subsequent field conditions, step conditions, or experience logic via `{ var: 'responses.field-name' }`
 
-## Field Types
+## Field types
 
 Fields support four primitive types, `text`, `number`, `boolean` and `object`:
 
@@ -129,7 +129,7 @@ const conditionalField = createField({
 })
 ```
 
-## Field Validation
+## Field validation
 
 Validate user input using JSON Logic rules. The `$input` variable contains the current field value:
 
@@ -179,7 +179,7 @@ const quantityField = createField({
 The `catch`/`throw` pattern in JSON Logic validates that the condition evaluates to `true`. If it doesn't, the `throw` message is displayed to the user.
 :::
 
-## Field Policies
+## Field policies
 
 Control how field data is tracked and stored using privacy policies:
 
@@ -205,7 +205,7 @@ const sensitiveField = createField({
 
 Use these policies for sensitive data like SSNs, credit cards, or passwords that should only exist client-side.
 
-## Field Metadata
+## Field metadata
 
 Enhance user experience with additional descriptive text:
 
@@ -229,7 +229,7 @@ const passwordField = createField({
 - `description`: Brief explanation shown below the label
 - `helpText`: Additional guidance or requirements displayed near the field
 
-## Accessing Field Values
+## Accessing field values
 
 Field responses are stored in the experience state and can be accessed via the `responses` object:
 
@@ -251,7 +251,7 @@ const sensitiveField = createField({
 
 :::
 
-## Best Practices
+## Best practices
 
 - **Use semantic IDs and names**: Name fields descriptively (e.g., `email-address` not `field1`) for easier debugging and analytics
 - **Match type to data**: Use `number` for numeric values, not `text`, to enable proper validation and comparison

package/dist/docs/sdk/steps.md

@@ -4,9 +4,9 @@ layout: docs
 
 # Steps
 
-Steps are the building blocks of an experience. Each step represents a single screen or stage in a multi-step journey.
+Render steps with `<StepRouter>` and `<Step>` from `@picked/react` or `@picked/svelte`, and access the active step through `useStep()` / `getStep()`.
 
-## How Steps Work
+## How steps work
 
 When an experience starts, its steps are connected in a directed node graph. The SDK traverses this graph to determine which step to display:
 
@@ -18,7 +18,7 @@ When an experience starts, its steps are connected in a directed node graph. The
 6. **Navigation**: The SDK follows the edge from the current step node to the next, traversing any conditionals or actions before arriving at the next step
 7. **Completion**: When no further steps exist, the experience flow is complete
 
-## Step Routing
+## Step routing
 
 `StepRouter` listens to the experience's current step state and activates the matching `Step` by its `id`. Each `Step` registers itself on mount and unregisters on unmount, so lazy-rendered tabs or drawers work automatically.
 
@@ -72,7 +72,7 @@ function MyExperience() {
 All Steps must be wrapped in a router, even if it is a single Step
 :::
 
-### Lazy-Loaded Steps
+### Lazy-loaded steps
 
 For large experiences, steps can be lazily loaded using dynamic imports:
 
@@ -100,7 +100,7 @@ const WelcomeScreen = lazy(() => import('./WelcomeScreen'))
 
 The `component` prop accepts a `Promise<Component>` — the step's content is not loaded until it becomes active.
 
-## Accessing Step Context
+## Accessing step context
 
 Inside a `Step` component (or any component rendered within one), call `getStep()` / `useStep()` to access the step's reactive context:
 
@@ -123,7 +123,7 @@ Inside a `Step` component (or any component rendered within one), call `getStep(
     onchange={field.onChange}
     onblur={field.onBlur}
   />
-  {#if field.error && field.touched
+  {#if field.error && field.touched}
     <p class="error">{field.error.userMessage}</p>
   {/if}
 {/each}
@@ -168,13 +168,13 @@ function ContactForm() {
 | `step`     | `Store<ExperienceStep>`                       | Reactive store containing the step's `id` and `label`                          |
 | `fields`   | `Store<FormField[]>`                          | Reactive store of fields with their current values, errors, and event handlers |
 | `isActive` | `Store<boolean>` (Svelte) / `boolean` (React) | Whether this step is currently active in the router                            |
-| `form`     | Object                                        | Form submission handlers (see Forms section)                                   |
+| `form`     | Object                                        | Form submission handlers (see [Forms](#forms))                                 |
 
 ## Forms
 
 When a step has fields, `getStep()` / `useStep()` provides a `form` object for handling submission, validation, and navigation.
 
-### Handling Submission
+### Handling submission
 
 Bind `form.props` to your `<form>` element's `onsubmit` handler:
 
@@ -249,7 +249,7 @@ Submitting the form:
 5. Fires `form_submit_success` or `form_submit_error` on the event bus
 6. Navigates to the next step (unless `stopNavigation` is called)
 
-### Transforming Data Before Submission
+### Transforming data before submission
 
 Use `form.onBeforeSubmit` to intercept and transform field data before it is committed. Callbacks run in series, each receiving the output of the previous:
 
@@ -293,7 +293,7 @@ function ContactStep() {
 
 :::
 
-### Success and Error Callbacks
+### Success and error callbacks
 
 Register callbacks for submission outcomes using `form.onSuccess` and `form.onError`:
 
@@ -347,7 +347,7 @@ function ContactStep() {
 
 Callbacks registered via `onSuccess` and `onError` are automatically cleaned up when the component unmounts — no manual teardown is needed.
 
-### Preventing Navigation on Success
+### Preventing navigation on success
 
 By default, the experience advances to the next step after a successful submission. Call `stopNavigation()` inside `onSuccess` to prevent this, for example when you need to handle navigation manually:
 
@@ -401,7 +401,7 @@ function PlanStep() {
 
 :::
 
-## Best Practices
+## Best practices
 
 - **Give steps meaningful labels**: The `label` is used in analytics events and the dashboard — prefer descriptive names like `"Contact Details"` over `"Step 2"`
 - **Keep steps focused**: Each step should collect a small, related set of information. Prefer more steps over longer forms to reduce abandonment

package/dist/esm/form/index.js

@@ -1,4 +1,4 @@
-import { t as e } from "../../rules-logic-B--rEvGw.js";
+import { t as e } from "../../rules-logic-D7dL30U1.js";
 import { attach as t, combine as n, createEffect as r, createEvent as i, createStore as a, sample as o, split as s } from "effector";
 //#region src/form/build-responses.ts
 function c(e, t, n) {