Marc Mintel
5397309103
Some checks failed
Build & Deploy / 🔍 Prepare (push) Successful in 20s
Build & Deploy / 🧪 QA (push) Failing after 34s
Build & Deploy / 🏗️ Build (push) Has started running
Build & Deploy / 🚀 Deploy (push) Has been cancelled
Build & Deploy / 🧪 Smoke Test (push) Has been cancelled
Build & Deploy / ⚡ Lighthouse (push) Has been cancelled
Build & Deploy / 🔔 Notify (push) Has been cancelled
67 lines
3.5 KiB
Plaintext
67 lines
3.5 KiB
Plaintext
import type { BuildFormStateArgs, ClientFieldSchemaMap, Data, DocumentPreferences, Field, FieldSchemaMap, FormState, PayloadRequest, SanitizedFieldsPermissions, SelectMode, SelectType } from 'payload';
|
|
import type { RenderFieldMethod } from './types.js';
|
|
import { iterateFields } from './iterateFields.js';
|
|
type Args = {
|
|
/**
|
|
* The client field schema map is required for field rendering.
|
|
* If fields should not be rendered (=> `renderFieldFn` is not provided),
|
|
* then the client field schema map is not required.
|
|
*/
|
|
clientFieldSchemaMap?: ClientFieldSchemaMap;
|
|
collectionSlug?: string;
|
|
data?: Data;
|
|
/**
|
|
* If this is undefined, the `data` passed to this function will serve as `fullData` and `data` when iterating over
|
|
* the top-level-fields to generate form state.
|
|
* For sub fields, the `data` will be narrowed down to the sub fields, while `fullData` remains the same.
|
|
*
|
|
* Usually, the `data` passed to this function will be the document data. This means that running validation, read access control
|
|
* or executing filterOptions here will have access to the full document through the passed `fullData` parameter, and that `fullData` and `data` will be identical.
|
|
*
|
|
* In some cases however, this function is used to generate form state solely for sub fields - independent from the parent form state.
|
|
* This means that `data` will be the form state of the sub fields - the document data won't be available here.
|
|
*
|
|
* In these cases, you can pass `documentData` which will be used as `fullData` instead of `data`.
|
|
*
|
|
* This is useful for lexical blocks, as lexical block fields there are not part of the parent form state, yet we still want
|
|
* document data to be available for validation and filterOptions, under the `data` key.
|
|
*/
|
|
documentData?: Data;
|
|
fields: Field[] | undefined;
|
|
/**
|
|
* The field schema map is required for field rendering.
|
|
* If fields should not be rendered (=> `renderFieldFn` is not provided),
|
|
* then the field schema map is not required.
|
|
*/
|
|
fieldSchemaMap: FieldSchemaMap | undefined;
|
|
id?: number | string;
|
|
/**
|
|
* Validation, filterOptions and read access control will receive the `blockData`, which is the data of the nearest parent block. You can pass in
|
|
* the initial block data here, which will be used as `blockData` for the top-level fields, until the first block is encountered.
|
|
*/
|
|
initialBlockData?: Data;
|
|
mockRSCs?: BuildFormStateArgs['mockRSCs'];
|
|
operation?: 'create' | 'update';
|
|
permissions: SanitizedFieldsPermissions;
|
|
preferences: DocumentPreferences;
|
|
/**
|
|
* Optionally accept the previous form state,
|
|
* to be able to determine if custom fields need to be re-rendered.
|
|
*/
|
|
previousFormState?: FormState;
|
|
readOnly?: boolean;
|
|
/**
|
|
* If renderAllFields is true, then no matter what is in previous form state,
|
|
* all custom fields will be re-rendered.
|
|
*/
|
|
renderAllFields: boolean;
|
|
renderFieldFn?: RenderFieldMethod;
|
|
req: PayloadRequest;
|
|
schemaPath: string;
|
|
select?: SelectType;
|
|
selectMode?: SelectMode;
|
|
skipValidation?: boolean;
|
|
};
|
|
export declare const fieldSchemasToFormState: ({ id, clientFieldSchemaMap, collectionSlug, data, documentData, fields, fieldSchemaMap, initialBlockData, mockRSCs, operation, permissions, preferences, previousFormState, readOnly, renderAllFields, renderFieldFn, req, schemaPath, select, selectMode, skipValidation, }: Args) => Promise<FormState>;
|
|
export { iterateFields };
|
|
//# sourceMappingURL=index.d.ts.map |