@eifi1/ui-kit 0.23.0 → 0.24.1

package/dist/feedback-attachment-fGAzZPf0.d.ts

@@ -1,469 +0,0 @@
-import * as react from 'react';
-import { ReactNode, RefObject } from 'react';
-
-interface FeedbackCategoryOption {
-    value: string;
-    label: string;
-}
-interface FeedbackAttachmentLabels {
-    /** The heading over the field. Optional: a note editor puts the buttons
-     *  straight under its textarea, where a second heading is noise. */
-    attachment?: string;
-    attachmentAdd: string;
-    /** Label for the "capture screenshot" button. Optional — falls back to the provider's
-     *  `feedbackAttachment.attachmentCapture`, then English. */
-    attachmentCapture?: string;
-    /** The line under the attachment buttons saying a screenshot can be pasted
-     *  straight in. Optional — falls back to the provider's `feedbackAttachment`, then English. */
-    attachmentPaste?: string;
-    attachmentRemove: string;
-    /** `multiple` mode (0.15.5): the chip list's accessible name — and, in
-     *  `<FeedbackDialog attachments="multiple">`, the heading over it (0.16.0). Optional,
-     *  as are the keys below — they fall back to the provider's `feedbackAttachment`,
-     *  then English. */
-    attachmentList?: string;
-    /** `multiple` mode (0.16.0): the screenshot slot's chip title, in place of its file name. */
-    attachmentScreenshot?: string;
-    /** `multiple` mode: one chip's remove button, given the file's name. */
-    attachmentRemoveFile?: (name: string) => string;
-    /** `multiple` mode: the line shown once `max` files are attached. */
-    attachmentLimit?: (max: number) => string;
-    /** `refs` mode (0.22.0): the second line of a chip whose upload is still running. */
-    attachmentUploading?: string;
-}
-interface FeedbackDialogLabels extends FeedbackAttachmentLabels {
-    title: string;
-    category: string;
-    subject: string;
-    body: string;
-    attachment: string;
-    submitHint: string;
-    cancel: string;
-    save: string;
-    /** @deprecated since 0.16.0 — use `attachmentList`, the one key for the heading and
-     *  the chip list it names. Still honoured: set, it wins over the provider's
-     *  `attachmentList` (but not over an `attachmentList` passed beside it). */
-    attachments?: string;
-}
-/**
- * The dialog's own strings — the `feedbackDialog` namespace of `<UiKitProvider
- * labels>` (0.12.0). The attachment keys are not repeated here: they are the
- * `feedbackAttachment` namespace's, which the field inside already reads.
- *
- * Before, every key was required at the call site, so each app restated ten strings
- * wherever it mounted the dialog (kastlan feedback-button.tsx built the object inline).
- */
-interface FeedbackDialogTextLabels {
-    title: string;
-    category: string;
-    subject: string;
-    body: string;
-    /** The body's label when `requireBody={false}`: "What happened? (optional)".
-     *  Optional, so a complete `UiKitLabels` typed before 0.14.2 still compiles. */
-    bodyOptional?: string;
-    /** The heading over the attachment buttons. */
-    attachment: string;
-    /** The line beside the buttons naming the shortcut. */
-    submitHint: string;
-    cancel: string;
-    save: string;
-    /** @deprecated since 0.16.0 — use `feedbackAttachment.attachmentList`. It and this
-     *  key were two names for one heading ("Attachments" over the chips that list names
-     *  "Attachments"), and a catalogue that translated one left the other English. Still
-     *  honoured when set: it wins over `feedbackAttachment.attachmentList`. */
-    attachments?: string;
-}
-declare const DEFAULT_FEEDBACK_DIALOG_LABELS: FeedbackDialogTextLabels;
-interface FeedbackSubmission {
-    title: string;
-    body: string;
-    category: string;
-    attachment: File | null;
-}
-/**
- * What `onSubmit` gets under `attachments="multiple"` (0.15.5): the screenshot and
- * the picked/pasted files apart, because an app files them differently — keksdose
- * attaches the screenshot to the report and the photos as its evidence list. No
- * `attachment`: there is no one file it could name.
- */
-interface FeedbackMultipleSubmission {
-    title: string;
-    body: string;
-    category: string;
-    /** What `onCaptureScreenshot` returned, or `null` — at most one. */
-    screenshot: File | null;
-    /** Picked and pasted files, in the order they were added; at most `maxAttachments`. */
-    attachments: File[];
-}
-interface FeedbackDialogBaseProps {
-    open: boolean;
-    onClose: () => void;
-    categories: FeedbackCategoryOption[];
-    category: string;
-    onCategoryChange: (value: string) => void;
-    /** Prop > `<UiKitProvider labels={{ feedbackDialog, feedbackAttachment }}>` >
-     *  English. Optional since 0.12.0; a whole `FeedbackDialogLabels` still fits. */
-    labels?: Partial<FeedbackDialogLabels>;
-    submitting?: boolean;
-    contextSlot?: ReactNode;
-    attachmentAccept?: string[];
-    maxAttachmentBytes?: number;
-    /**
-     * Optional: capture a screenshot of the underlying app view and return it as a
-     * File. When provided, a "Capture screenshot" button is shown next to "Add
-     * attachment"; the returned file is fed through the same validation + preview.
-     */
-    onCaptureScreenshot?: () => Promise<File | null>;
-    /**
-     * `false`: a report with only a subject can be sent, and the body's label says it is
-     * optional (`bodyOptional`, unless `labels.body` is passed). Default `true`, the
-     * dialog's behaviour until 0.14.2 (keksdose K1: its backend takes title-only reports).
-     */
-    requireBody?: boolean;
-}
-/** One attachment — a screenshot, a picked or a pasted image; a second replaces
- *  nothing, it has to wait for the first to be removed. The default. */
-interface FeedbackDialogSingleProps extends FeedbackDialogBaseProps {
-    attachments?: "single";
-    onSubmit: (data: FeedbackSubmission) => void | Promise<void>;
-    /** `info` (0.23.0) names the refused file and the limit — see
-     *  {@link FeedbackAttachmentErrorInfo}. */
-    onAttachmentError?: (kind: "type" | "size", info: FeedbackAttachmentErrorInfo) => void;
-    /** Multiple mode only — refused here rather than silently ignored. */
-    maxAttachments?: never;
-}
-/**
- * One screenshot plus up to `maxAttachments` picked or pasted files (0.15.5, keksdose
- * dev#578: "pasted two photos, the second overwrote the first"). The capture button is
- * offered while there is no screenshot yet; the add button while there is room.
- */
-interface FeedbackDialogMultipleProps extends FeedbackDialogBaseProps {
-    attachments: "multiple";
-    /** Default `DEFAULT_MAX_ATTACHMENTS` (5). The screenshot does not count. */
-    maxAttachments?: number;
-    onSubmit: (data: FeedbackMultipleSubmission) => void | Promise<void>;
-    /** `"count"`: more files arrived at once than there was room for; the surplus was
-     *  dropped. `info` (0.23.0) names the refused file(s) and the limit. */
-    onAttachmentError?: (kind: FeedbackAttachmentError, info: FeedbackAttachmentErrorInfo) => void;
-}
-type FeedbackDialogProps = FeedbackDialogSingleProps | FeedbackDialogMultipleProps;
-/**
- * The generic feedback form dialog: category + subject + body + an optional image
- * attachment, with Ctrl/Cmd+Enter to submit. Domain-free — the app supplies the
- * category options, labels and an `onSubmit` that talks to its own backend, plus
- * an optional `contextSlot` for app-specific context (user, current URL, …).
- *
- * **A screenshot can be pasted straight in.** Ctrl/Cmd+V anywhere in the dialog
- * takes an image off the clipboard and makes it the attachment, through the same
- * validation and the same preview as the file picker. It is the gesture the two
- * ways in did not cover: `onCaptureScreenshot` snapshots the *whole* app view,
- * and the file picker needs a file — so somebody who wanted to show one panel,
- * or one region of one, had to save a crop to disk first and then find it again
- * (Steering Design feedback #39). The clipboard is where a region snip already
- * is on every platform.
- *
- * **`attachments="multiple"`** (0.15.5) takes several: every paste and pick adds a
- * chip, and `onSubmit` gets `{ screenshot, attachments }` ({@link
- * FeedbackMultipleSubmission}) instead of `attachment`. Opt-in, so a caller typed
- * against the one-file submission keeps compiling and behaving as before.
- */
-declare function FeedbackDialog(props: FeedbackDialogProps): react.JSX.Element | null;
-
-declare const DEFAULT_ATTACHMENT_ACCEPT: string[];
-declare const DEFAULT_MAX_ATTACHMENT_BYTES: number;
-/** How many files `<FeedbackAttachmentField multiple>` takes when `max` is not given
- *  (0.15.5). Five photos of one problem is already a lot to look through; a report
- *  that needs more is a conversation, which the thread is for. */
-declare const DEFAULT_MAX_ATTACHMENTS = 5;
-/**
- * The field's own strings — the `feedbackAttachment` namespace of `<UiKitProvider
- * labels>`. The keys are {@link FeedbackAttachmentLabels}' own, so the `labels` prop
- * (and a whole `FeedbackDialogLabels` handed down by the dialog) merges over them
- * one to one. The optional heading, `attachment`, stays a prop: a note editor puts
- * the buttons straight under its textarea and wants none.
- *
- * Before 0.7.0 the two optional keys fell back to hard-coded English, so a German app
- * that relied on its provider got "Capture screenshot" under a German form.
- *
- * The three keys added in 0.15.5 for `multiple` mode are optional, so a complete
- * `UiKitLabels` typed before it still compiles; they fall back to English. So is
- * `attachmentScreenshot` (0.16.0).
- */
-interface FeedbackAttachmentFieldLabels {
-    attachmentAdd: string;
-    attachmentCapture: string;
-    attachmentPaste: string;
-    attachmentRemove: string;
-    /** `multiple` mode: the accessible name of the list of chosen files — and, since
-     *  0.16.0, the heading `<FeedbackDialog attachments="multiple">` puts over it. */
-    attachmentList?: string;
-    /** `multiple` mode (0.16.0): what the screenshot slot's chip is called — "Screenshot"
-     *  rather than the capture's file name ("screenshot.webp"), which says nothing a
-     *  reporter chose. The file name stays as the chip's second line. */
-    attachmentScreenshot?: string;
-    /** `multiple` mode: one chip's remove button — "Remove photo.jpg". Named per file,
-     *  because five buttons all called "Remove attachment" say nothing about which. */
-    attachmentRemoveFile?: (name: string) => string;
-    /** `multiple` mode: the line shown in place of the add buttons once `max` is reached. */
-    attachmentLimit?: (max: number) => string;
-    /** `refs` mode (0.22.0, keksdose K16): the second line of a chip whose upload is still
-     *  running, where an uploaded one shows its size — "Uploading…". Optional, like the
-     *  keys above, so a `UiKitLabels` typed before it still compiles. */
-    attachmentUploading?: string;
-    /** `refs` mode (0.23.0, keksdose G5a): {@link FeedbackAttachmentErrorInfo.message} for
-     *  an `"upload"` refusal — "“huge.png” could not be uploaded". The other refusals'
-     *  sentences are the `filePicker` namespace's, shared with FileButton. Optional, like
-     *  the keys above. */
-    attachmentUploadFailed?: (name: string) => string;
-}
-declare const DEFAULT_FEEDBACK_ATTACHMENT_LABELS: FeedbackAttachmentFieldLabels;
-/** Why a file was turned away. `"count"` only ever comes from `multiple` (and `refs`)
- *  mode: more files arrived at once than `max` left room for, and the surplus was
- *  dropped. */
-type FeedbackAttachmentError = "type" | "size" | "count";
-/** `refs` mode's reasons: {@link FeedbackAttachmentError}, or `"upload"` — `onUpload`
- *  rejected, and what it rejected with is `onError`'s second argument. A type of its
- *  own so a host's exhaustive switch over the File modes' reasons stays exhaustive. */
-type FeedbackAttachmentRefsError = FeedbackAttachmentError | "upload";
-/**
- * What `onError` knows about a refusal beyond its kind (0.23.0, keksdose G5a): the file
- * it was about, the limit that refused it, and a sentence that says both.
- *
- * keksdose's support chat toasted "File too large" with no name — the field's `onError`
- * carried a kind and nothing else, so a refusal could not say WHICH of three pasted
- * screenshots went, nor what the ceiling was, and its own `AttachmentPicker` (a
- * FileButton, whose `onReject` hands over `{ file, message }`) said more than the kit's
- * field would have. This is that, for every mode.
- *
- * It arrives as an EXTRA argument, after the ones `onError` already had, so a handler
- * written for 0.22 — `(kind) => …`, or `refs` mode's `(kind, error) => …` — compiles
- * and behaves as before:
- *
- * - single and `multiple`: `onError(kind, info)`;
- * - `refs`: `onError(kind, error, info)` — the second place is `onUpload`'s rejection
- *   since 0.22 (`undefined` for the other kinds, as it always was), so the info comes
- *   third rather than changing what a 0.22 handler reads there. It also carries that
- *   `error`, so one helper `(kind, info) => …` serves all three modes.
- *
- * An object rather than more positional arguments because what a host reaches for
- * differs by kind — the bytes for `"size"`, `max` for `"count"`, the server's answer for
- * `"upload"` — and a field added later must not shift anyone's arguments.
- */
-interface FeedbackAttachmentErrorInfo {
-    /** The file refused — under the name the field would have given it (a pasted image
-     *  is already "pasted.png"). For `"count"`, the first of the surplus; for
-     *  `"upload"`, the file whose upload failed. */
-    file: File;
-    /** `"count"`: every file of the surplus (several can arrive in one pick). Otherwise
-     *  `[file]`. */
-    files: File[];
-    /**
-     * One translated sentence naming the file and the limit — the ones FileButton's
-     * `onReject` hands over, from the same `filePicker` namespace: "“huge.png” is larger
-     * than 10 MB", "Only image/png, image/jpeg files", "“c.png” was not added: at most 5
-     * files" (several at once: "3 files were not added"). `"upload"`: the field's own
-     * `attachmentUploadFailed`, "“huge.png” could not be uploaded" — a host with a better
-     * sentence from the server's answer uses `error`. Ready for a toast as it is.
-     */
-    message: string;
-    /** The field's `maxBytes` — the ceiling a `"size"` refusal went over, in bytes. */
-    maxBytes: number;
-    /** The field's `accept` — the types a `"type"` refusal was not among. */
-    accept: string[];
-    /** The field's `max` — the ceiling a `"count"` refusal hit. Absent in single mode,
-     *  which holds one file by definition. */
-    max?: number;
-    /** `"upload"` only: what `onUpload` rejected with — `onError`'s second argument. */
-    error?: unknown;
-}
-/**
- * One uploaded attachment in `refs` mode: what the host's upload answered with. `key`
- * identifies it (a storage key, an upload id) and is what a remove goes by; `name` is
- * what the chip says. `size` (bytes) and `type` (mime) are optional — given, the chip
- * shows the size and an image icon or a file icon accordingly.
- */
-interface FeedbackAttachmentRef {
-    key: string;
-    name: string;
-    size?: number;
-    type?: string;
-}
-interface FeedbackAttachmentFieldBaseProps {
-    /** Prop > `<UiKitProvider labels={{ feedbackAttachment }}>` > English. Optional
-     *  since 0.7.0; `attachment` (the heading) is only ever read from here. */
-    labels?: Partial<FeedbackAttachmentLabels> & Pick<Partial<FeedbackAttachmentFieldLabels>, "attachmentUploading" | "attachmentUploadFailed">;
-    accept?: string[];
-    maxBytes?: number;
-    /**
-     * Take no files for now (0.23.0, keksdose G5b): the add and capture buttons, the
-     * hidden file input and every chip's remove button are natively disabled, and a paste
-     * is let through untouched. The chips stay as they are — what is about to be sent
-     * stays readable.
-     *
-     * For the moment a send is in flight. keksdose's support picker is `disabled` while
-     * the message goes out, because the message carries the attachments AS THEY WERE at
-     * the press: a chip removed mid-send has gone with it all the same, and one added
-     * mid-send looks as if it had. The field has no drop target; the paste is its drop.
-     *
-     * This is a pause, not a lock that explains itself — for that, `refs` mode (the mode
-     * that commits) takes `commit` and `disabledReason`.
-     */
-    disabled?: boolean;
-    /** Snapshot the app view behind this and return it as a File. A "Capture
-     *  screenshot" button appears only when it is given. */
-    onCaptureScreenshot?: () => Promise<File | null>;
-    /** Listen for the paste on `document` rather than on this field's own
-     *  subtree. For a modal, which owns the whole page while it is up. */
-    documentPaste?: boolean;
-    /** Listen for the paste within this element's subtree rather than this
-     *  field's own — for a field standing *beside* the text box a paste is made
-     *  in, whose common parent is where the event bubbles to. Ignored when
-     *  `documentPaste` is set. */
-    pasteFrom?: RefObject<HTMLElement | null>;
-    className?: string;
-}
-/** One file: choosing a second means removing the first. The field's only mode until 0.15.5. */
-interface FeedbackAttachmentFieldSingleProps extends FeedbackAttachmentFieldBaseProps {
-    multiple?: false;
-    refs?: false;
-    value: File | null;
-    onChange: (file: File | null) => void;
-    /** A file was refused. `info` (0.23.0) names it and the limit — see
-     *  {@link FeedbackAttachmentErrorInfo}. */
-    onError?: (kind: "type" | "size", info: FeedbackAttachmentErrorInfo) => void;
-    max?: never;
-    screenshot?: never;
-    onScreenshotChange?: never;
-    commit?: never;
-    disabledReason?: never;
-}
-/**
- * Several files (0.15.5, keksdose dev#578: "pasted two photos, the second overwrote
- * the first"). Every way in ADDS — a pick of several files, a paste, a capture — up to
- * `max`, and each file is a removable chip.
- */
-interface FeedbackAttachmentFieldMultipleProps extends FeedbackAttachmentFieldBaseProps {
-    multiple: true;
-    refs?: false;
-    value: File[];
-    onChange: (files: File[]) => void;
-    /** How many files `value` may hold. Default {@link DEFAULT_MAX_ATTACHMENTS} (5). The
-     *  add buttons and the paste hint are offered only while there is room. */
-    max?: number;
-    /** Per file: a rejected one is reported and the others are still added. `"count"` is
-     *  once per pick, with the whole surplus in `info.files`. `info` (0.23.0): see
-     *  {@link FeedbackAttachmentErrorInfo}. */
-    onError?: (kind: FeedbackAttachmentError, info: FeedbackAttachmentErrorInfo) => void;
-    /**
-     * A separate slot for THE screenshot, outside `value` and `max`. Given
-     * `onScreenshotChange`, what `onCaptureScreenshot` returns lands here instead of in
-     * `value`, shown as the first chip, and the capture button is offered only while the
-     * slot is empty — a second snapshot of the same view is not more evidence. This is
-     * how `<FeedbackDialog attachments="multiple">` keeps the screenshot apart from the
-     * photos; a form built from the parts can do the same.
-     */
-    screenshot?: File | null;
-    onScreenshotChange?: (file: File | null) => void;
-    commit?: never;
-    disabledReason?: never;
-}
-/**
- * Uploaded on pick (0.22.0, keksdose K16). keksdose's support chat uploads each file
- * the moment it is chosen and sends the message with the REFS the uploads answered —
- * a 10 MB screenshot is refused while the reporter is still typing, not when they
- * press Send — so its `AttachmentPicker` could not use this field, whose value is
- * `File`s held until the form is submitted. Here the value is
- * {@link FeedbackAttachmentRef}s: every way in (pick, paste, capture) validates the
- * file as the other modes do, then hands it to `onUpload` and shows a chip with a
- * spinner until it answers; the ref it resolves to joins `value` through `onChange`.
- * A rejection drops the chip and reports `onError("upload", error)`. A chip is removed
- * BY KEY: `onChange` gets the list without it, and `onRemove` the key, for a host that
- * deletes the upload on the server too.
- *
- * Uploads still running count against `max`, so five picks in quick succession cannot
- * overshoot it; they are not in `value` until they land, so a send that reads `value`
- * sends only what has arrived — hold Send back while {@link onUploadingChange} says
- * an upload is running. Several files upload side by side and join in the order they
- * finish. The File modes are unchanged.
- */
-interface FeedbackAttachmentFieldRefsProps extends FeedbackAttachmentFieldBaseProps {
-    refs: true;
-    multiple?: never;
-    value: FeedbackAttachmentRef[];
-    onChange: (refs: FeedbackAttachmentRef[]) => void;
-    /** Upload one file; resolve to its ref, or reject to refuse it. Called once per
-     *  accepted file, the moment it is chosen. */
-    onUpload: (file: File) => Promise<FeedbackAttachmentRef>;
-    /** A chip was removed — after `onChange` — with its ref's key. */
-    onRemove?: (key: string) => void;
-    /** Whether any upload is running: `true` when the first starts, `false` when the
-     *  last settles — for the host's Send, which should wait. */
-    onUploadingChange?: (uploading: boolean) => void;
-    /** How many refs `value` may hold, uploads in flight included. Default
-     *  {@link DEFAULT_MAX_ATTACHMENTS} (5). */
-    max?: number;
-    /** Per file. `"upload"` carries what `onUpload` rejected with as `error` (`undefined`
-     *  for the other kinds). `info` (0.23.0) comes third so a 0.22 handler's `error` is
-     *  still the second argument — see {@link FeedbackAttachmentErrorInfo}. */
-    onError?: (kind: FeedbackAttachmentRefsError, error: unknown, info: FeedbackAttachmentErrorInfo) => void;
-    /**
-     * This field COMMITS (0.23.0): each file is uploaded the moment it is chosen, and a
-     * remove may delete the upload (`onRemove`) — a save, unlike the File modes, which
-     * only stage a file for a form sent later (and so stay open under a lock, like every
-     * field). Under a locked {@link WriteLockProvider} it takes the `disabledReason` path
-     * with the lock's reason, which wins over one of its own. No provider, or an unlocked
-     * one: no effect.
-     */
-    commit?: boolean;
-    /**
-     * Why no file can be added or removed — the write lock's sentence, a quota, a thread
-     * closed to replies. Unlike `disabled`, it SAYS so, the kit's commit-control way: the
-     * buttons (add, capture, every chip's remove) stay focusable, `aria-disabled`, with
-     * the reason in the kit Tooltip and their description; no pick, paste or remove gets
-     * through; and the reason stands where the paste hint was, for a phone that never
-     * hovers. The chips stay readable.
-     */
-    disabledReason?: ReactNode;
-    screenshot?: never;
-    onScreenshotChange?: never;
-}
-type FeedbackAttachmentFieldProps = FeedbackAttachmentFieldSingleProps | FeedbackAttachmentFieldMultipleProps | FeedbackAttachmentFieldRefsProps;
-/**
- * Picking one picture: the file dialog, a capture of the app view, or a paste.
- * With `multiple`, picking several (see {@link FeedbackAttachmentFieldMultipleProps}).
- *
- * Lifted out of {@link FeedbackDialog} so the *reply* half of the feature can
- * have it too (Steering Design feedback #128). A report is a conversation — it
- * is filed, it is answered, and the reporter sends it back saying that is not
- * what they meant — and the screenshot showing what they mean is taken at
- * whichever of those points they looked. Only the first of them had a way to
- * attach one, so everything after it had to be described in words.
- *
- * **Three ways in, and they are three because no one of them covers the others.**
- * The file dialog needs a file on disk; `onCaptureScreenshot` snapshots the
- * *whole* app view; and the clipboard is where a region snip already is on every
- * platform (Steering Design feedback #39). Somebody who wanted to show one panel
- * had to save a crop and then find it again.
- *
- * `documentPaste` and `pasteFrom` decide where the paste is listened for, and
- * it is a real choice rather than a flag with a default. A modal traps focus,
- * so while it is up every paste in the page is meant for it — including one
- * made with nothing in particular focused, which never reaches a React
- * `onPaste` on a child: that is `documentPaste`. An editor **inline on a
- * page** is not that: the page around it has its own fields, so it listens
- * within its own subtree and a paste elsewhere stays where it was aimed. But
- * "its own subtree" has to include the text box the paste is actually made in,
- * and that box is this field's *sibling*, not its child — a paste in it bubbles
- * to their common parent and never through here. `pasteFrom` is that parent
- * (Steering Design feedback #140): the element whose subtree is listened to,
- * handed in by whoever renders both the box and this field side by side.
- */
-declare function FeedbackAttachmentField(props: FeedbackAttachmentFieldProps): react.JSX.Element;
-/** What a pasted image is called once it is an attachment.
- *
- *  The extension is read off the mime type rather than assumed to be `.png`:
- *  Safari puts TIFF on the clipboard and a file called `pasted.png` that is not
- *  a PNG is one the receiving end opens wrong. */
-declare function pastedName(type: string): string;
-
-export { DEFAULT_ATTACHMENT_ACCEPT as D, type FeedbackAttachmentError as F, DEFAULT_FEEDBACK_ATTACHMENT_LABELS as a, DEFAULT_FEEDBACK_DIALOG_LABELS as b, DEFAULT_MAX_ATTACHMENTS as c, DEFAULT_MAX_ATTACHMENT_BYTES as d, type FeedbackAttachmentErrorInfo as e, FeedbackAttachmentField as f, type FeedbackAttachmentFieldLabels as g, type FeedbackAttachmentFieldMultipleProps as h, type FeedbackAttachmentFieldProps as i, type FeedbackAttachmentFieldRefsProps as j, type FeedbackAttachmentFieldSingleProps as k, type FeedbackAttachmentLabels as l, type FeedbackAttachmentRef as m, type FeedbackAttachmentRefsError as n, type FeedbackCategoryOption as o, FeedbackDialog as p, type FeedbackDialogLabels as q, type FeedbackDialogMultipleProps as r, type FeedbackDialogProps as s, type FeedbackDialogSingleProps as t, type FeedbackDialogTextLabels as u, type FeedbackMultipleSubmission as v, type FeedbackSubmission as w, pastedName as x };