Currently, the data structure for the FieldState seems to be finalizing:
interface FieldState<TValue, TData extends {}> {
readonly id: string;
readonly name: string;
readonly data: TData;
readonly status: FieldStatus;
readonly fields: Readonly<Dictionary<FieldState<unknown, any>>>;
}
In the previous versions of Forms library, we had FormState and various FieldState derivatives. This complicated things because we couldn't use common mechanisms and had to introduce 2 mechanisms for doing the same operations: one for FormState and one for FieldState.
This time, we arrived to a conclusion that Everything is a field. and that let us simplify the state into a nested structure with only a few properties.
First two properties are basic and identify the Field in a global or local manner:
id is a global identifier representing field's place in the state, e.g. person.firstName.
name is a local identifier, only representing the field's name it's responsible for, e.g. firstName.
data is where all field specific data will be stored, e.g. a TextField will have currentValue, initialValue, defaultValue, selectionStart, selectionEnd, etc.
data can be different for every field, thus it is like a bag where any field data can be put.
status is represented by FieldStatus interface:
interface FieldStatus {
focused: boolean;
touched: boolean;
pristine: boolean;
disabled: boolean;
readonly: boolean;
permanent: boolean;
}
These statuses represent any field status at a given time. More on them in a separate issue.
And the only one property left here is fields. It is a nested dictionary where all fields are placed and all their data described above can be found.
Some things are still moving around and we are battle-testing this data structure by creating the initial bunch of fields. Looking at the current version of it, I don't thing it will change, as there is not much left to take away 😄
And, as Antoine de Saint-Exupery said:
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Thus, we're trying to not add anything into the base structure, unless it proves to be mandatory and we cannot live without it. At least right now there's not much left to take away.
Currently, the data structure for the
FieldStateseems to be finalizing:In the previous versions of Forms library, we had
FormStateand variousFieldStatederivatives. This complicated things because we couldn't use common mechanisms and had to introduce 2 mechanisms for doing the same operations: one forFormStateand one forFieldState.This time, we arrived to a conclusion that
Everything is a field.and that let us simplify the state into a nested structure with only a few properties.First two properties are basic and identify the
Fieldin a global or local manner:idis a global identifier representing field's place in the state, e.g.person.firstName.nameis a local identifier, only representing the field's name it's responsible for, e.g.firstName.datais where all field specific data will be stored, e.g. aTextFieldwill havecurrentValue,initialValue,defaultValue,selectionStart,selectionEnd, etc.datacan be different for every field, thus it is like a bag where any field data can be put.statusis represented byFieldStatusinterface:These statuses represent any field status at a given time. More on them in a separate issue.
And the only one property left here is
fields. It is a nested dictionary where all fields are placed and all their data described above can be found.Some things are still moving around and we are battle-testing this data structure by creating the initial bunch of fields. Looking at the current version of it, I don't thing it will change, as there is not much left to take away 😄
And, as Antoine de Saint-Exupery said:
Thus, we're trying to not add anything into the base structure, unless it proves to be mandatory and we cannot live without it. At least right now there's not much left to take away.