@jobber/components-native 0.101.5 → 0.101.6

package/dist/docs/ContentOverlay/ContentOverlay.md

@@ -0,0 +1,64 @@
+# ContentOverlay
+
+ContentOverlay allows the user to quickly access information that supports their
+understanding of the primary content of their current view.
+
+## Design & usage guidelines
+
+The ContentOverlay component will allow users to quickly access detailed
+information about a topic without having to navigate away from their current
+view.
+
+## Content guidelines
+
+The ContentOverlay should be able to present any type of content, but its most
+common use case will probably be text and images.
+
+While the ContentOverlay can have input such as InputText within it, and the
+keyboard will adjust its location to make the currently focused field visible,
+it is advisable to be cautious about how much content it contains if there are
+inputs. If an input ends up near the bottom of the ContentOverlay with no room
+to move up, it will become obstructed by the keyboard. Only enabling scrolling
+will allow it to be visible.
+
+## Accessibility
+
+ContentOverlay responds to touch events, specifically swiping.
+
+## Responsiveness
+
+ContentOverlay will take up as much vertical space as needed, minus a small
+amount of space between the top of the overlay and the top of the screen. It
+will also take up the full width of the screen up to a breakpoint of 640px,
+where it will be a maximum width of 640px and be centered on the screen.
+
+## Mockup
+
+
+## Developer notes
+
+`ContentOverlay` uses the same library internally as
+[BottomSheet.](../BottomSheet/BottomSheet.md)
+
+
+## Props
+
+### Mobile
+
+| Prop | Type | Required | Default | Description |
+|------|------|----------|---------|-------------|
+| `children` | `ReactNode` | Yes | — | Content to be passed into the overlay |
+| `accessibilityLabel` | `string` | No | `"Close {title} modal"` | Optional accessibilityLabel describing the overlay. This will read out when the overlay is opened. |
+| `adjustToContentHeight` | `boolean` | No | `false` | If true, automatically adjusts the overlay height to the content height. This will disable the ability to drag the ov... |
+| `fullScreen` | `boolean` | No | `false` | Force overlay height to fill the screen. Width not impacted. |
+| `isDraggable` | `boolean` | No | `true` | If false, hides the handle and turns off dragging. |
+| `keyboardShouldPersistTaps` | `boolean` | No | `false` | Allows taps to be registered behind keyboard if enabled |
+| `loading` | `boolean` | No | `false` | Boolean to show a disabled state |
+| `modalBackgroundColor` | `ModalBackgroundColor` | No | `surface` | Set the background color of the modal window |
+| `onBeforeExit` | `() => void` | No | — | Callback that is called between overlay is closed and when the "x" button is pressed |
+| `onClose` | `() => void` | No | — | Callback that is called when the overlay is closed. |
+| `onOpen` | `() => void` | No | — | Callback that is called when the overlay is opened. |
+| `ref` | `Ref<{ open?: () => void; close?: () => void; }>` | No | — | Ref to the content overlay component. |
+| `scrollEnabled` | `boolean` | No | `false` | Enables scrolling in the content body of overlay |
+| `showDismiss` | `boolean` | No | `false` | Display the dismiss button in the header of the overlay. |
+| `title` | `string` | No | — | Title of overlay, appears in the header next to the close button. |

package/dist/docs/Disclosure/Disclosure.md

@@ -0,0 +1,161 @@
+# Disclosure
+
+Disclosure is a component that allows users to progressively reveal content that
+is not essential to the primary objective of a given view.
+
+## Design & usage guidelines
+
+Disclosure is useful for revealing or hiding content that is not essential for
+the user to view all at once. You may want to put content inside of a Disclosure
+to:
+
+* reduce distractions or avoid overwhelming the user
+* hide non-critical controls or options in a form
+
+Disclosure should only be used to contain content or controls that aren't
+required for the user to complete the primary objective of a given view.
+
+For example, if a user has to make a selection between two options to complete a
+task, do not put the selection controls in a Disclosure. A better example of
+using a Disclosure would be if there is an optional setting that a user may want
+to change but is not required to.
+
+## Content guidelines
+
+* `title` should be informative and label the type of content grouped in the
+  body of the Disclosure.
+  * This can either be a string or a React component. If a React component is
+    used (containing multiple children), it should be wrapped in a container
+    element and not a `<Fragment>` to maintain correct UI styling.
+    * Caveat: The container element should NOT be `<div>` as it would break the
+      semantics of the `<summary>` element. Instead, use a `<span>` or `<p>`
+      tag.
+  * The elements passed as a `title` can be plain text, or HTML that can be used
+    within a paragraph (AKA
+    ["phrasing content"](https://developer.mozilla.org/en-US/docs/Web/HTML/Content_categories#phrasing_content))
+    to ensure that the title is accessible and can be properly read by screen
+    readers. A heading may also be used but will not be treated as a heading by
+    assistive technologies.
+* `children` should be actionable and clear. The contents of a Disclosure can
+  be:
+  * plain text
+  * any React component (except [Page](/components/Page) and
+    [Table](/components/Table))
+
+## Accessibility
+
+* Users should be able to use their keyboard and toggle the component's
+  open/close state
+* A single Heading element is permitted in `summary` elements, however, it might
+  lose some accessibility benefits, since according to
+  [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary#summaries_as_headings):
+  > Warning: Because the `<summary>` element has a default role of button (which
+  > strips all roles from child elements), this example will not work for users
+  > of assistive technologies such as screen readers. The `<h4>` will have its
+  > role removed and thus will not be treated as a heading for these users.
+* Include aria-expanded attribute on the trigger to communicate to assistive
+  technology
+* Include aria-controls attribute ties on the trigger to the content it controls
+  using the id of the collapsible container
+* The trigger contains a downward-pointing-arrow to hint that it can be
+  expanded. When the disclosure item is in an expanded state, this is rotated
+  180 degrees to point upwards
+* The icon will be given an `aria-hidden="true"` attribute to hide it from
+  assistive technologies, as well as `focusable="false"` to address an
+  inconsistency in IE and older versions of Edge
+
+## Responsiveness
+
+The Disclosure component should handle both click and touch, as well as keyboard
+inputs. It should fill the width of its container and if the component is less
+than 375px wide, the title will wrap and should not be truncated.
+
+
+## Component customization
+
+### UNSAFE\_ props (advanced usage)
+
+General information for using `UNSAFE_` props can be found
+[here](../customizing-components/customizing-components.md).
+
+**Note**: Use of `UNSAFE_` props is **at your own risk** and should be
+considered a **last resort**. Future Disclosure updates may lead to unintended
+breakages.
+
+Disclosure has multiple elements that can be targeted with classes or styles:
+
+* `container`: The container element of the Disclosure
+* `summary`: The clickable header area of the Disclosure
+* `summaryWrap`: The inner content within the summary, containing the title and
+  toggle arrow
+* `title`: The title element of the Disclosure
+* `icon`: The toggle arrow of the Disclosure
+* `arrowIconWrapper`: The wrapper element for the toggle arrow
+* `content`: The content inside the Disclosure
+
+#### UNSAFE\_className (web)
+
+Use `UNSAFE_className` to apply custom classes to the Disclosure. This can be
+useful for applying styles via CSS Modules.
+
+```tsx
+// Disclosure.tsx
+UNSAFE_className={{
+  container: styles.customDisclosure,
+  summary: styles.customSummary,
+}}
+
+// Disclosure.stories.css
+.customDisclosure {
+  border: 3px solid var(--color-interactive);
+  border-radius: var(--radius-base);
+}
+
+.customSummary {
+  padding: var(--space-base);
+}
+```
+
+#### UNSAFE\_style (web)
+
+The `UNSAFE_style` prop provides granular control over the Disclosure's
+appearance through inline styles, allowing you to modify the dimensions and
+colors independently.
+
+```tsx
+<Disclosure
+  ...
+  UNSAFE_style={{
+    container: {
+      border: "3px solid var(--color-interactive)",
+      borderRadius: "var(--radius-base)",
+    },
+    title: {
+      textStyle: {
+        color: "var(--color-interactive--hover)",
+      },
+    },
+    icon: {
+      path: {
+        fill: "var(--color-interactive--subtle)",
+      },
+    },
+  }}
+>
+  ...
+</Disclosure>
+```
+
+
+## Props
+
+### Mobile
+
+| Prop | Type | Required | Default | Description |
+|------|------|----------|---------|-------------|
+| `content` | `ReactNode` | Yes | — | Specifies the main content of the disclosure component. It can be any React Node - simple text, JSX, or a complex Rea... |
+| `header` | `ReactNode` | Yes | — | Defines the header of the disclosure component. Similar to `content`, it can be any React Node. |
+| `isEmpty` | `boolean` | Yes | — | A boolean that indicates whether the disclosure component is empty or not. If `isEmpty` is `true`, there is no conten... |
+| `onToggle` | `() => void` | Yes | — | A function that is called whenever the disclosure component is toggled between its open and closed states. |
+| `open` | `boolean` | Yes | — | A boolean that determines whether the disclosure component is in an open or closed state. If `open` is true, the disc... |
+| `animationDuration` | `number` | No | `staticTokens["timing-slowest"]` | An optional property that determines the duration of the opening and closing animation of the disclosure component. I... |

package/dist/docs/Divider/Divider.md

@@ -0,0 +1,84 @@
+# Divider
+
+The Divider component is used to separate content into different sections.
+
+## Design & usage guidelines
+
+Divider comes with no spacing around it. This means that it should be used
+within a [Content](../Content/Content.md) component.
+
+### Size
+
+For different levels of segmentation, you may find the need to use larger
+Dividers. As Dividers increase in size, they get lighter to offset the visual
+impact of their additional weight.
+
+## Related components
+
+* To segment different groups of content, use [Card](../Card/Card.md)
+* For guidance on borders in general, see our [Borders guide](../Borders/Borders.md)
+
+
+## Component customization
+
+### UNSAFE\_ props (advanced usage)
+
+General information for using `UNSAFE_` props can be found
+[here](../customizing-components/customizing-components.md).
+
+**Note**: Use of `UNSAFE_` props is **at your own risk** and should be
+considered a **last resort**. Future Divider updates may lead to unintended
+breakages.
+
+Divider has one element that can be targeted with classes or styles:
+
+* `container`: The main `div` element of the Divider
+
+#### UNSAFE\_className (web)
+
+Use `UNSAFE_className` to apply custom classes to the Divider. This can be
+useful for applying styles via CSS Modules.
+
+```tsx
+// YourComponent.tsx
+import styles from "./YourStyles.module.css";
+
+<Divider
+  UNSAFE_className={{
+    container: styles.customDivider,
+  }}
+/>
+
+// YourStyles.module.css
+.customDivider {
+  background-color: var(--color-background-brand-bold);
+  height: 5px;
+}
+```
+
+#### UNSAFE\_style (web)
+
+The `UNSAFE_style` prop provides granular control over the Divider's appearance
+through inline styles.
+
+```tsx
+<Divider
+  UNSAFE_style={{
+    container: {
+      backgroundColor: "var(--color-background-danger-bold)",
+      height: "10px",
+    },
+  }}
+/>
+```
+
+
+## Props
+
+### Mobile
+
+| Prop | Type | Required | Default | Description |
+|------|------|----------|---------|-------------|
+| `direction` | `"horizontal" | "vertical"` | No | `horizontal` | The direction of the divider |
+| `size` | `"base" | "large" | "larger" | "largest"` | No | `base` | The weight of the divider. |
+| `testID` | `string` | No | `Divider` | Used to locate this view in end-to-end tests. |

package/dist/docs/Elevations/Elevations.md

@@ -0,0 +1,76 @@
+# Elevation
+
+> Elevation is the relative distance between two surfaces along the z-axis.
+> –[Material Design](https://material.io/design/environment/elevation.html)
+
+In Atlantis, our web components use elevation to specify position on the z-axis,
+with shadows separately responsible for conveying that depth. Our mobile
+components combine these two concepts in keeping with Android and iOS patterns.
+
+Generally speaking, the "higher" an element sits in the z-axis, the broader its'
+shadow should spread, to reflect diffusion in the distance between the element
+and the ground. As an element gets nearer to the ground, or "lower", the
+shadow's spread should reduce and the shadow may appear darker.
+
+We also include a *slight* y-axis offset of elevation shadows to imply that the
+light source is coming from an angle slightly over the head of a user looking
+directly into the screen.
+
+### Low
+
+A low element may have a slight elevation, but is not necessarily something that
+will glide across the surface. A basic card on mobile that is not tappable would
+be represented as having a "low" elevation.
+
+### Base
+
+This shadow should be used for most instances of shadows to convey that an
+element is floating overtop related elements, such as in
+[Menu](/components/Menu) or [Popover](/components/Popover). An element with a
+base elevation is likely interactive, and this level can indicate and invite the
+use of gesture controls in a mobile app.
+
+### High
+
+High elements should be elements that float overtop the entire interface,
+typically with a fixed position. The "high" elevation indicates that the element
+has broken the plane of the view. A good example for web would be
+[Toast](../Toast/Toast.md).
+
+## Web
+
+### Z-index elevation
+
+The following table lists Atlantis components that have a z-index specified.
+
+These values can be referenced when you are building a view so that you can
+ensure the elements you are using do not unintentionally overlap, if you end up
+using z-index on non-Atlantis components.
+
+| Component        | Value |
+| :--------------- | :---- |
+| Form field label |       |
+| Menu             |       |
+| Modal            |       |
+| Tooltip          |       |
+| Toast            |       |
+
+### Shadow elevation
+
+These are the box-shadows rendered to signify elevation on given UI elements;
+they map to our low/base/high pattern.
+
+| Name            | Visual |
+| :-------------- | :----- |
+| `--shadow-low`  |        |
+| `--shadow-base` |        |
+| `--shadow-high` |        |
+
+## Mobile
+
+For mobile designs, the concept of elevation applies to both shadows and
+hierarchy of the element along the z-index. Android accepts a single "elevation"
+value, while iOS accepts more granular shadow values similar to CSS.
+
+When using the mobile tokens imported from `@jobber/design`, the shadow tokens
+will be resolved to apply to either android or iOS devices automatically.

package/dist/docs/EmptyState/EmptyState.md

@@ -0,0 +1,72 @@
+# Empty State
+
+EmptyState is a component we show when there is nothing here for the user. This
+component should be used for lists with no content, search with no results,
+error states etc.
+[Here is a document](https://jobber.atlassian.net/wiki/spaces/DES/pages/2103541908/Empty+states)
+that explores this in more detail.
+
+## Design & usage guidelines
+
+By considering and accounting for often “un-happy” paths in the user’s journey,
+we can allow the user to learn how to use Jobber more effectively, guide them
+out of troublesome scenarios, and ensure that they never feel like they’ve hit a
+dead-end in the product.
+
+For more detail you can read about our
+[Empty State patterns.](https://jobber.atlassian.net/wiki/spaces/DES/pages/2103541908/Empty+states)
+
+## Content guidelines
+
+An Empty State can display an Icon, text-based title, text-based description,
+and 1–2 actions in Buttons.
+
+If there is an icon that is relevant to helping the user understand the Empty
+State, and the layout has space to comfortably accommodate it, you can use an
+icon to help add an element of “glanceability”.
+
+When providing a title, ensure that it is succinct. It should not take up more
+than 1 line on a small (320px) device, so the user can quickly assess what's
+going on.
+
+A description can be longer and provide more context or instruction, but as with
+the title, keep it brief as possible so the user can spend less time reading and
+more time getting into a happier state.
+
+Action labels should be–you guessed it–short and succinct. Labels should be
+clear about what will happen when the Button is pressed.
+
+## Accessibility
+
+Icons are not read out by assistive technology as they are decorative in nature.
+
+Title has a role of Heading and will be announced as such to assistive
+technology like "Heading - {title content}".
+
+Description has a role of Text and will be read to assistive technology without
+any modifiers.
+
+Actions have a role of Button and will be announced as such to assistive
+technology.
+
+## Responsiveness
+
+Empty State will take up as much width as possible - all UI elements will remain
+in the centre as the width increases or decreases. Text-based elements will
+reflow to a second line if enough content is provided.
+
+## Mockup
+
+
+## Props
+
+### Mobile
+
+| Prop | Type | Required | Default | Description |
+|------|------|----------|---------|-------------|
+| `description` | `string` | No | — | Description of the empty state. |
+| `icon` | `IconNames` | No | — | Icon to display. |
+| `iconColor` | `"task" | "text" | "warning" | "icon" | "white" | "grey" | "greyBlue" | "greyBlueDark" | "greyBlueLighter" | "blue" | "lightBlue" | "green" | "yellow" | "red" | "navy" | "orange" | ... 33 more ... | "brandHighlight"` | No | `blue` | Color of Icon to display. |
+| `primaryAction` | `Action` | No | — | Handler for the primary action. |
+| `secondaryAction` | `Action` | No | — | Handler for the secondary action. |
+| `title` | `string` | No | — | Title of the empty state. |

package/dist/docs/Flex/Flex.md

@@ -0,0 +1,37 @@
+# Flex
+
+Flex is a component that allows you to easily create a flexible layout.
+
+## Design & usage guidelines
+
+The Flex component facilitates the rendering of multiple child components into a
+grid layout with as many rows as needed. Each column of the Flex grid can be
+programmed to take the smallest space possible or grow depending on available
+space. Once the number of child components exceeds the length of the template
+array, new rows will be created to accomodate the extra children, styled
+similarily to the children above.
+
+It is also possible to nest grids within each other. This can be helpful when
+wanting to apply different grid styles to different groups of children. For
+example, nested grids with different `align` and `template` props can be used to
+further control the layout of the children.
+
+## Related components
+
+Use [Grid](/components/Grid) to create grid layouts. Using Flex inside of Grid
+gives you the ability to achieve complex layouts without needing custom
+wrappers.
+
+Use [Content](../Content/Content.md) to evenly space elements in a simple
+one-directional layout.
+
+
+## Props
+
+### Mobile
+
+| Prop | Type | Required | Default | Description |
+|------|------|----------|---------|-------------|
+| `align` | `FlexAlignType` | No | `center` | It works the same way as `alignItems` style with flex. |
+| `gap` | `"none" | "smallest" | "smaller" | "small" | "base" | "large"` | No | `base` | The spacing between the children. |
+| `template` | `ColumnKeys[]` | No | `[]` | Determine how the children gets laid out on the flex grid. If there are more Children than elements in the template, ... |

package/dist/docs/Form/Form.md

@@ -0,0 +1,126 @@
+# Form
+
+The Form component is a wrapper component that handles the submission and
+validation of forms.
+
+For more information about `validations` using any of the Input components, see
+the [InputText](../InputText/InputText.md) documentation.
+
+## Design & usages guidelines
+
+The Form component has a lot of built-in features which rely on its internal
+state. To take advantage of these features, do not bypass the Form's internal
+state — the fields or inputs within the Form must have a `name` prop and **NOT**
+have a `value` and `onChange` prop.
+
+## Content guidelines
+
+### Inputs
+
+Form can accept various inputs and selection elements such as (but not limited
+to) [InputText](../InputText/InputText.md), [Select](../Select/Select.md),
+[Switch](../Switch/Switch.md), [Checkbox](../Checkbox/Checkbox.md), and
+[Chips](/components/Chips). They should be placed [Cards](../Card/Card.md) to
+indicate grouping when relevant, and groups of Cards can be spaced appropriately
+using ContentSection.
+
+### Save Button label
+
+The `saveButtonLabel` property defaults to "Save", but should be made more
+verbose to add context for the user. Use the format "Save {object}", such as
+"Save Job". This helps clarify to the user that tapping the Save Button is not
+saving the single input they are editing, but the entire object.
+
+### Form errors
+
+All error messaging should follow our
+[Product Vocabulary.](/content/product-vocabulary)
+
+## Setup (mobile)
+
+Consuming apps using the mobile Form must wrap their app root with
+`KeyboardProvider` from `react-native-keyboard-controller`.
+
+## Accessibility (mobile)
+
+The individual inputs are responsible for accessibility concerns such as the
+labels, types, values, and error messages of each input.
+
+
+## Platform considerations
+
+#### iOS
+
+On iOS, the save button will be fixed to the bottom of the viewport until the
+keyboard is opened.
+
+Once the keyboard is open, the save button will be inline beneath the Form's
+inputs, unless the Form is so short that it does not scroll. In this case, the
+save button will remain fixed above the keyboard.
+
+This prevents the user from accidentally submitting the Form before they have
+completed entering all the relevant information for their work, especially since
+many data points in Jobber cannot be edited once saved.
+
+#### Android
+
+On Android, the save button will always be inline with the contents of the Form.
+
+### Error handling
+
+#### Server-side errors
+
+Server-side error messages will be displayed in a banner at the top the Form
+upon a failed submission attempt. These are errors where something has gone
+wrong with the data either on the way to, or on the way back from, our servers.
+If the user can address the errors, inform them how to do so in the banner.
+Otherwise, a generic message informing the user that something went wrong is an
+appropriate fallback.
+
+Note: When a server-side error happens, inside the `onSubmit` function, an error
+must be thrown. Throwing an error inside the `onSubmit` function will ensure
+that your `onSubmitError` function is called instead of your `onSubmitSuccess`.
+
+#### Client-side errors
+
+Client-side errors are issues that we can catch and inform the user of before
+they attempt to submit the Form, such as a required field left blank or an
+incorrect email address format.
+
+Error messages for individual inputs should appear inline on each impacted
+input. Form will automatically scroll to the first invalid (has an error)
+element and display the error message.
+
+When an error occurs, either server-side or client-side, Form will announce the
+message to screen-readers and set focus to the impacted portion of the Form.
+
+
+## Props
+
+### Mobile
+
+| Prop | Type | Required | Default | Description |
+|------|------|----------|---------|-------------|
+| `children` | `ReactNode` | Yes | — | Content to be passed into the form |
+| `onSubmit` | `(data: T) => Promise<S>` | Yes | — | A callback function that handles the submission of form data. If an error occurs during submission, it should not be ... |
+| `onSubmitError` | `(error: FormErrors) => void` | Yes | — | A callback function that handles any error that occurs during "onSubmit" |
+| `onSubmitSuccess` | `(data: S) => void` | Yes | — | A callback function that handles a successful form submission from "onSubmit" |
+| `bannerErrors` | `FormBannerErrors` | No | — | Network or user errors to be displayed as a banner at the top of the form |
+| `bannerMessages` | `FormBannerMessage[]` | No | — | Status messages to be displayed as a banner at the top of the form |
+| `disableKeyboardAwareScroll` | `boolean` | No | — | @internal Do not use this prop. It is a hack and will be removed. TODO: JOB-147156 This is a HACK for multiline input... |
+| `formRef` | `RefObject<UseFormReturn<T> & { scrollViewRef?: RefObject<KeyboardAwareScrollViewRef>; saveButtonHeight?: number; messageBannerHeight?: number; }>` | No | — | ref object to access react hook form methods and state |
+| `initialLoading` | `boolean` | No | — | Loading when the initial form data is being fetched |
+| `initialValues` | `{ [x: string]: any; } | ((BrowserNativeObject | NestedValue) & FieldValues) | { [x: string]: any; }` | No | — | The initial values of the form inputs This should be available as soon as initialLoading is set to false |
+| `localCacheExclude` | `string[]` | No | — | Forms field names that will not be considered for caching. Useful for omitting sensitive data. |
+| `localCacheId` | `string | string[]` | No | — | A string or array of strings that can be used to identify the pre-filled data on the form. This can be used to suppor... |
+| `localCacheKey` | `string` | No | — | Adding a key will save a local copy of the form data that will be used to recover values when the app is backgrounded... |
+| `mode` | `"onBlur" | "onChange" | "onSubmit" | "onTouched" | "all"` | No | — | When the validation should happen. Possible values are "onBlur", "onChange", "onSubmit", "onTouched", and "all". The ... |
+| `onBeforeSubmit` | `(data: T) => Promise<boolean>` | No | — | A callback function that is run before invoking onSubmit. Form submission is canceled if the promise resolves to false. |
+| `renderFooter` | `ReactNode` | No | — | Renders a footer below the save button. |
+| `renderStickySection` | `(onSubmit: () => void, label: string, isSubmitting: boolean) => ReactElement<unknown, string | JSXElementConstructor<any>>` | No | — | @deprecated use `secondaryAction` instead. Override default save button in the sticky section of the form with anothe... |
+| `reValidateMode` | `"onBlur" | "onChange" | "onSubmit"` | No | — | When the validation after submission should happen. Possible values are "onBlur", "onChange", and "onSubmit". The def... |
+| `saveButtonLabel` | `string` | No | — | Label to be displayed for the save button |
+| `saveButtonOffset` | `number` | No | — | A number that will pull down the save button when the position is sticky. Useful when there's a footer or content bel... |
+| `secondaryActions` | `SecondaryActionProp[]` | No | — | Secondary Action for ButtonGroup |
+| `showStickySaveButton` | `boolean` | No | — | Forces to render the sticky save button instead of the inline. The sticky save button is default for iOS but not for ... |
+| `UNSAFE_allowDiscardLocalCacheWhenOffline` | `boolean` | No | — | If true, the local cache will be removed when the user navigates away from the dirty form even when offline. By defau... |

package/dist/docs/FormField/FormField.md

@@ -0,0 +1,57 @@
+# Form Field
+
+FormField is a helper component that allows other components to use form logic.
+Interacting with a component wrapped in a FormField will automatically update
+the form value for the field used by the component.
+
+## Related components
+
+Refer to the [Form](../Form/Form.md) documentation to learn more about inputs
+within a form.
+
+
+## Configuration
+
+### Mobile
+
+FormField should not be used to wrap separate instances of a given input
+component, it should be done at the component level. For example, say you had
+four SpecialInput components on a given form. Instead of the four SpecialInput
+components in FormField, it would be better to go to the SpecialInput component
+where it is exported and wrap it there.
+
+```ts
+// The SpecialInput implementation, without any form logic
+function SpecialInputInternal(props) {
+  ...
+}
+
+// This is what would be exported and used by other views or components
+export function SpecialInput(props) {
+  return (
+    <FormField name={props.name}>
+      {(field) => {
+        return (
+          <SpecialInput
+            ...props
+            onChange={field.onChange}
+            value={field.value}
+          />
+        );
+      }}
+    </FormField>
+  );
+}
+```
+
+
+## Props
+
+### Mobile
+
+| Prop | Type | Required | Default | Description |
+|------|------|----------|---------|-------------|
+| `children` | `(field: ControllerRenderProps<FieldValues, string>, error?: FieldError) => ReactNode` | Yes | — | Children to render. |
+| `name` | `string` | Yes | — | Name of the field. |
+| `defaultValue` | `T` | No | — | The initial value of the form field. |
+| `validations` | `RegisterOptions` | No | — | Rules for returning an error when validations are violated. WARNING: This component needs to be nested inside a FormP... |