Tools for connecting a f-form.field
to the DOM.
The main utilities are the higher-level helpers input
, select
,
checkbox
, and radio
. Use plugin
to integrate with other libraries.
Tools for connecting a [[f-form.field]] to the DOM. The main utilities are the higher-level helpers [[input]], [[select]], [[checkbox]], and [[radio]]. Use [[plugin]] to integrate with other libraries.
Functions for creating and updating a field
, an immutable representation of
a single element in a form. A field has a value, some history about interactions
with it, and knowledge about where it fits in its f-form.form
.
Conceptually, a field
corresponds to a single HTML <input>
, <select>
, or
<textarea>
.
A field has a :field/value
, which can be any value: a primitive string, number or
boolean, or a more elaborate map or set. (It also has a :field/initial-value
,
the value before any changes.)
It has a :field/path
, which uniquely identifies it in its form. The path is
a sequence of keys as defined by clojure.core/assoc-in
.
And finally, it has a :field/tracker
. The tracker defines which other state
and history attributes will be stored on the field. See
f-form.field-tracker
for more information about these attributes and how
they are set.
See f-form.dom
for tools to attach a field to a DOM node.
Functions for creating and updating a `field`, an immutable representation of a single element in a form. A field has a value, some history about interactions with it, and knowledge about where it fits in its [[f-form.form]]. Conceptually, a `field` corresponds to a single HTML `<input>`, `<select>`, or `<textarea>`. A field has a `:field/value`, which can be any value: a primitive string, number or boolean, or a more elaborate map or set. (It also has a `:field/initial-value`, the value before any changes.) It has a `:field/path`, which uniquely identifies it in its form. The path is a sequence of keys as defined by `clojure.core/assoc-in`. And finally, it has a `:field/tracker`. The tracker defines which other state and history attributes will be stored on the field. See [[f-form.field-tracker]] for more information about these attributes and how they are set. See [[f-form.dom]] for tools to attach a field to a DOM node.
Tools to help a f-form.field
accumulate history about how it has been
interacted with.
There are two classes of interaction history.
First, the field can gain or lose focus. This history is summarized with three attributes:
:field/visited?
- whether the field has ever received focus. Typically
used to mark off complete fields or to call attention to incomplete or pending
fields.:field/active?
- whether the field currently has focus. Typically used to
add an outline or some other emphasis to the focused field, if this cannot be
done with CSS.:field/touched?
- whether the field has ever lost focus. Typically used to
hide errors until the user has failed to take the opportunity to resolve them, or
to show a ✓ or some other indicator beside completed fields.Second, its value can be changed. This history is summarized with two attributes:
:field/modified?
- whether the field's value has ever been changed (by a
user action). Typically used to allow the system to control the value of a
field until the user makes a choice, then to hand control of the value over to
them.:field/pristine?
- whether the field's value is the same as its initial
value. Typically used to skip submission of unchanged fields.For these two classes of interaction history, there are two sets of interaction events which modify the history.
The events related to the focus state of the field are:
:initialized
, when the field is created or reset.:focus-gained
, when the field gains focus.:focus-lost
, when the field loses focus.The events related to the value of the field are:
:changed
, when the field's value changes.:snapshot
, when the field's value and initial-value are synced, for example
when the field is initialized or when its form has been submitted on a
periodic timer.The names of the history fields were influenced by Final Form FieldState.
Since not every application design will care about every state change, and
since there is a cost to tracking excess state (computationally when
calculating the state, and in some cases when triggering unnecessary updates
to a datastore) it is best to skip accumulation of unused state. This
namespace provides some tools to customize a tracker
that helps the field
accumulate a minimal amount of state.
Tools to help a [[f-form.field]] accumulate history about how it has been interacted with. There are two classes of interaction history. First, the field can gain or lose focus. This history is summarized with three attributes: * `:field/visited?` - whether the field has ever received focus. Typically used to mark off complete fields or to call attention to incomplete or pending fields. * `:field/active?` - whether the field currently has focus. Typically used to add an outline or some other emphasis to the focused field, if this cannot be done with CSS. * `:field/touched?` - whether the field has ever lost focus. Typically used to hide errors until the user has failed to take the opportunity to resolve them, or to show a ✓ or some other indicator beside completed fields. Second, its value can be changed. This history is summarized with two attributes: * `:field/modified?` - whether the field's value has ever been changed (by a user action). Typically used to allow the system to control the value of a field until the user makes a choice, then to hand control of the value over to them. * `:field/pristine?` - whether the field's value is the same as its initial value. Typically used to skip submission of unchanged fields. For these two classes of interaction history, there are two sets of interaction events which modify the history. The events related to the focus state of the field are: * `:initialized`, when the field is created or reset. * `:focus-gained`, when the field gains focus. * `:focus-lost`, when the field loses focus. The events related to the value of the field are: * `:changed`, when the field's value changes. * `:snapshot`, when the field's value and initial-value are synced, for example when the field is initialized or when its form has been submitted on a periodic timer. The names of the history fields were influenced by Final Form [FieldState](https://final-form.org/docs/final-form/types/FieldState). Since not every application design will care about every state change, and since there is a cost to tracking excess state (computationally when calculating the state, and in some cases when triggering unnecessary updates to a datastore) it is best to skip accumulation of unused state. This namespace provides some tools to customize a [[tracker]] that helps the field accumulate a minimal amount of state.
Functions for creating and upating a form, an immutable collection of related
f-form.field
s which will be validated together.
A form usually corresponds to an html <form>
tag. Or to be more precise, one
<form>
is built out of one or more f-form.forms.
Functions for creating and upating a form, an immutable collection of related [[f-form.field]]s which will be validated together. A form usually corresponds to an html `<form>` tag. Or to be more precise, one `<form>` is built out of one or more f-form.forms.
Functions for setting or checking the validation on the form as a whole.
A f-form.form
is validated as a whole, and a summary is placed on the
form. Field errors are placed on the fields themselves.
f-form delegates validation to other validation libraries. See
f-form.validation.vlad
for more information about validating with
vlad.
Functions for setting or checking the validation on the form as a whole. A [[f-form.form]] is validated as a whole, and a summary is placed on the form. Field errors are placed on the fields themselves. f-form delegates validation to other validation libraries. See [[f-form.validation.vlad]] for more information about validating with [vlad](https://github.com/logaan/vlad).
Tools for validating forms and their fields with https://github.com/logaan/vlad.
If you wish to use this namespace, you must provide vlad
in your own
dependencies. If you want to validate with another library, do not load this
namespace.
Tools for validating forms and their fields with https://github.com/logaan/vlad. If you wish to use this namespace, you must provide `vlad` in your own dependencies. If you want to validate with another library, do not load this namespace.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close