useForm / useFormField

[dy]

useForm / useFormField

[dy]

// similar to settings-panel
const params = [{ id: 'number', type: Number }]
const params2 = { number: 3, ... }

const [ fields, { set, submit, validate, reset } ] = useForm( params )
const { fieldName: { valid, error, touched, ref, type, validate }, ...rest } = fields

const [ { value, error, touched, ref, input }, { validate, set } ] = useField( 'name', { type: Number, validate: (value) => {} } )

[dy]

react-table introduces nice useTable hook approach, able to generate props for target elements. Same technique can be used here.

[dy]

3 aspects of useFormFIeld.

1. Possibly unnecessary separation of useFormField and useInput: separates creation of some data from accessing - not conceptually very much different.

2. useValidation can be a part of functionality, augmenting useInput. (although it redefines onChange, which may be redundant.

3. Passing input props into hook, instead of direct element is doubtful practice. It's better to focus on direct generating the UI, instead of passing props through some transforms.

[dy]

useValidation is insufficient on itself: it must show error only when the input is blurred, not when focused, so it depends on input element state.
Also, we may want to validate on form submit for example, but validate requires value to check against, since it is not bound to specific input - therefore it is useful to have something that knows about "input store".

So, responding to 1, 2, 3.

1. No need to separate - it can be used bot for creating and controlling, single hook returns "state" of some input element (null-ish state is allowed - it is not fully null but detached). That "virtual" state can optionally be rendered to real node.
2. field.validate() is better.
3. No need to pass input props, pass minimal input config.

[dy]

The quesion is: how to use useFormField as aspect, considering that it may create an input?
This is very similar to useStore(id, initObj) - if id is not found, it is created..
There can therefore be useFormField(id|element, initProps).
Conceptually, that is similar to upsert proposal: upsert(id, update: oldValue => newValue, insert: () => initValue), but in case of hooks update and insert functions are single init function.

More generally, resource hook creates a thread (like in erlang) of specific functionality (specific lens to look at data source).

To overcome explicit createStore call, there must be main aspect and auxiliary aspects - main aspect creates/controls entry, aux augments behavior.