import { Entity, EntityStatus, EntityValues } from "@rebasepro/types"; import { RebaseContext, AdminCollection } from "@rebasepro/cms-types"; import { RebaseData } from "@rebasepro/types"; /** * @group Hooks and utilities */ export type SaveEntityWithCallbacksProps> = { path: string; values: Partial>; entityId?: string | number; previousValues?: Partial>; collection?: AdminCollection; status: EntityStatus; afterSave?: (updatedEntity: Entity) => void; afterSaveError?: (e: Error) => void; }; /** * This function is in charge of saving a entity. * * It runs the collection's **`admin.browserCallbacks`** around the write — * `beforeSave`, then `afterSave` or `afterSaveError`. Not `callbacks`: that * block belongs to the server, which runs it inside the write it serves, and * its bodies are stripped from this bundle entirely. * * Which matters most for a collection on a `direct`/`custom` transport, where * the panel talks to the store itself and no server sees the write at all — * before this ran them, such a collection had no write callbacks anywhere. This * function has been named `saveEntityWithCallbacks` since it was written and * did not run any. * * A `beforeSave` that throws blocks the write, exactly as the server's does: * nothing is sent, and the error reaches `afterSaveError` and the caller. * * `afterSave`/`afterSaveError` below are the *caller's* UI callbacks — the * form's "close the dialog", the table's "clear the editing state" — and are * unrelated to the collection's. Both run: the collection's first. * * @param collection * @param path * @param entityId * @param values * @param previousValues * @param status * @param data * @param context * @param afterSave * @param afterSaveError * @group Hooks and utilities */ export declare function saveEntityWithCallbacks>({ collection, path, entityId, values, previousValues, status, data, context, afterSave, afterSaveError }: Omit, "collection"> & { collection: AdminCollection; data: RebaseData; context: RebaseContext; }): Promise>;