@vtex/faststore 0.0.6 → 0.0.8

package/dist/core/dist/define-component.d.ts

@@ -9,7 +9,7 @@ export interface EditorMetadata {
   description?: string;
   icon?: string;
 }
-export type PropType = 'string' | 'number' | 'boolean' | 'object' | 'array' | readonly string[];
+export type PropType = 'string' | 'number' | 'boolean' | 'object' | 'array' | 'link' | readonly string[];
 export type PropSchemaField = {
   /**
    * Prop type keyword. The catalog wire value `"icon"` is a sukima convention (collected at
@@ -23,10 +23,34 @@ export type PropSchemaField = {
    */
   items?: readonly string[];
   default?: unknown;
+  /**
+   * The route params the component supplies when it navigates, honored only when `type === 'link'`
+   * (e.g. `{ type: 'link', default: { standard: 'order-placed' }, fills: ['orderGroup'] }`).
+   */
+  fills?: readonly string[];
   label?: string;
 };
 export type PropSchema = Record<string, PropSchemaField>;
 export type FetchStrategy = 'static' | 'lazy' | 'reactive' | 'reactive-list-item';
+/**
+ * How one fragment variable reads the element's configuration when the by-name convention cannot
+ * express it (config-sourced fragment variables RFC). By convention `$first` reads the content-model
+ * field or schema prop named `first`; a binding is declared only to rename the source field (`from`)
+ * or to map its value through a table (`values`). Both operations are plain data: the block never
+ * carries a function, so the catalog keeps carrying JSON and the compiler stays domain-agnostic.
+ */
+export type VariableBinding = {
+  /** The content-model field or schema prop that feeds the variable, when its name differs. */
+  from?: string;
+  /**
+   * Maps the source field's value through a table: the key is the authored value (an enum member),
+   * the entry is what the variable receives (`relevance` -> `{ field: 'RELEVANCE', direction: 'DESC' }`).
+   * When the source field declares an enum, the table covers every member and nothing else.
+   */
+  values?: Record<string, unknown>;
+};
+/** Variable name (without `$`) -> binding. */
+export type VariableBindings = Record<string, VariableBinding>;
 export interface ComponentDefinition<TProps = Record<string, unknown>> {
   name: string;
   importPath: string;
@@ -62,6 +86,17 @@ export interface ComponentDefinition<TProps = Record<string, unknown>> {
    * bypass the compiler (Storybook, tests, manual JSX).
    */
   requiresContext?: string | string[];
+  /**
+   * Declares that this component is hardened for card data. The type is `boolean`, but the marker is
+   * only the author's claim: `defineComponent` does not verify it and nothing in this definition
+   * enforces it. Absent or `false` means the component makes no such claim; only the JSON boolean
+   * `true` is a claim of hardening. It is serialized into `catalog.json` as authored, so write the
+   * literal `true`. The catalog builder carries whatever the author wrote (a literal, or a same-file
+   * top-level `const`, `let` or `var` binding) and does not validate it, so a value that bypasses the
+   * type (a cast, a JS file) reaches the catalog unchanged. A consumer must compare strictly
+   * `=== true`, never test truthiness.
+   */
+  hardened?: boolean;
   /**
    * Write-side dependency declaration: the action namespaces and methods this component dispatches.
    * The compiler resolves each key against the first-party action catalog (`actions.json`, generated
@@ -82,6 +117,13 @@ export interface ComponentDefinition<TProps = Record<string, unknown>> {
    * page/layout locator are the compiler's concern; this field only fixes the declaration shape.
    */
   content?: ContentTypeDefinition;
+  /**
+   * Bindings for the fragment variables whose source field is not the variable's own name, or
+   * whose CMS value must be mapped before it reaches the query. Serialized into `catalog.json` as
+   * authored; the Catalog Build checks the shape and the compiler checks the cross-references at
+   * catalog load. Omit when every variable follows the by-name convention.
+   */
+  variables?: VariableBindings;
 }
 /**
  * When a `content` model is declared, the component's `$content` prop must be assignable to the

package/dist/core/dist/index.d.ts

@@ -2,6 +2,6 @@ import { ActionSelector } from "./actions/registry.js";
 import { MockActions, mockAction } from "./actions/mock-action.js";
 import { Direction, JsonValue, StorefrontContext } from "./schema/generated/schema.js";
 import { ContentArraySchema, ContentNestedObjectShape, ContentObjectPropertySchema, ContentObjectSchema, ContentPropertySchema, ContentPropertyType, ContentScalarSchema, ContentScalarType, ContentTypeDefinition, ContentValue, defineContentType } from "./define-content-type.js";
-import { ComponentDefinition, EditorMetadata, FetchStrategy, PropSchema, PropSchemaField, PropType, defineComponent } from "./define-component.js";
+import { ComponentDefinition, EditorMetadata, FetchStrategy, PropSchema, PropSchemaField, PropType, VariableBinding, VariableBindings, defineComponent } from "./define-component.js";
 import "./types.js";
-export { type ActionSelector, type ComponentDefinition, type ContentArraySchema, type ContentNestedObjectShape, type ContentObjectPropertySchema, type ContentObjectSchema, type ContentPropertySchema, type ContentPropertyType, type ContentScalarSchema, type ContentScalarType, type ContentTypeDefinition, type ContentValue, type EditorMetadata, type FetchStrategy, type JsonValue, type MockActions, type PropSchema, type PropSchemaField, type PropType, type StorefrontContext, defineComponent, defineContentType, mockAction };
+export { type ActionSelector, type ComponentDefinition, type ContentArraySchema, type ContentNestedObjectShape, type ContentObjectPropertySchema, type ContentObjectSchema, type ContentPropertySchema, type ContentPropertyType, type ContentScalarSchema, type ContentScalarType, type ContentTypeDefinition, type ContentValue, type EditorMetadata, type FetchStrategy, type JsonValue, type MockActions, type PropSchema, type PropSchemaField, type PropType, type StorefrontContext, type VariableBinding, type VariableBindings, defineComponent, defineContentType, mockAction };

package/dist/docs/account-access-gate.md

@@ -21,7 +21,7 @@ The image is the source of truth for layout, and this component is not in any la
 
 - On an individual account section, to repeat the rule → the layout already made it. A second gate is a second decision to keep in agreement with the first.
 - To show or hide a subtree by session state, with nothing else riding on it → use `SessionGuard`, which is the declarative show/hide. This component navigates, remembers, and is meant to own a whole page.
-- On the `/login` route → that route is [[sign-in-redirect]], and this component redirects *to* it. Gating it closes a loop the shopper cannot leave.
+- On the sign-in page → that page is [[sign-in-redirect]], and this component redirects *to* it. Gating it closes a loop the shopper cannot leave.
 - To decide whether a shopper may read *this particular order* or *that address* → the gate answers "is anyone signed in", never "is this record theirs". Record-level authorization belongs to the resolver.
 
 ---
@@ -64,7 +64,7 @@ Content model (`account-access-gate`) fields, edited in the CMS — the same fou
 
 **`identified` counts as signed out.** A shopper the platform recognizes but has not authenticated cannot reach their account, which is the same reading [[account-entry-point]] applies to its own label.
 
-**A visitor who arrived signed out is sent, not told.** The redirect replaces the history entry rather than pushing one, carrying the page they were trying to reach as the return, query string included — so back from the platform's login reaches the page they were reading rather than the first page of it, and never bounces off the gate again.
+**A visitor who arrived signed out is sent, not told.** The redirect replaces the history entry rather than pushing one, carrying the page they were trying to reach as the return, query string included, as a logical path the sign-in page prefixes on the way back — so back from the platform's login reaches the page they were reading rather than the first page of it, and never bounces off the gate again.
 
 **A session that ended mid-visit is told, not sent.** Past a redirect there is no surface left to say anything on, so the gate keeps the page and renders the notice with a sign-in link the shopper may take. This is a deliberate departure from "redirect whenever signed out", and it applies only when the gate has already rendered the account for this shopper.
 
@@ -113,7 +113,7 @@ Bound to a CMS entry, the element authors no messages at all — the entry suppl
 
 - **`AccountGate`, `AuthGuard`, `RequireLogin`, `ProtectedRoute`.** The correct name is `AccountAccessGate`.
 - **Repeating it per account section.** It belongs once in the layout, wrapping the body. Two gates are two decisions that can disagree.
-- **Putting [[sign-in-redirect]] under it.** The gate redirects to `/login`; a gated `/login` redirects to itself.
+- **Putting [[sign-in-redirect]] under it.** The gate redirects to the sign-in page `{ standard: 'sign-in' }`; a gated sign-in page redirects to itself.
 - **Placing it outside `SessionRoot`.** It declares `requiresContext: 'session'` and has nothing to read without one.
 - **Reaching for `SessionGuard when={['loggedIn']}` instead.** That expresses one of the five outcomes. It cannot redirect, cannot carry a return, cannot tell an arrival from an expiry, and renders nothing while the session is still resolving.
 - **Expecting it to redirect an expired session.** It renders a notice on purpose — see above.
@@ -148,6 +148,6 @@ Styling the gate's swatch reaches the loading part and both notices, which is us
 
 ## Related
 
-- [[sign-in-redirect]] — the `/login` route this component sends a signed-out visitor to, and which reads back the return this one encoded. Never place it under the gate.
+- [[sign-in-redirect]] — the sign-in page this component sends a signed-out visitor to, and which reads back the return this one encoded. Never place it under the gate.
 - [[account-entry-point]] — the header control that offers sign-in to a shopper who chose to go there. It asks; this one insists.
 - [[session]] — the context both read. `SessionGuard`, in the same group, is the declarative show/hide for a subtree with no navigation, no memory, and no loading state of its own.