As the library is not yet released, breaking changes are acceptable.
From early usage outside of package development, I noticed that FieldOnChangeCallback
and FormOnSubmitCallback
have differences in their parameters.
FieldOnChangeCallback
has:
event
newValue
fieldId
store
And FormOnSubmitCallback
has:
While defining and using both callbacks in the same class like so:
onSubmit: FormOnSubmitCallback = (event, store) => {
// <...>
};
onChange: FieldOnChangeCallback<any> = (event, newValue, fieldId, formId) => {
// <...>
};
It seems that usage should differ, but in essence, it should not differ that much.
E.g. formId
is available in FieldOnChangeCallback
, but not in FormOnSubmitCallback
. Why so?
Also, store
is being passed into FormOnSubmitCallback
, but getting FormStore
in FieldOnChangeCallback
requires importing FSHContainer
and getting FormStore
with a dance like so:
const store = FSHContainer.FormStoresHandler.GetStore(formId);
Not pretty and could scare an inexperienced user.
Therefore, I suggest updating FieldOnChangeCallback
from:
export type FieldOnChangeCallback<TElement> = (
event: React.FormEvent<TElement>,
newValue: FieldValue,
fieldId: string,
formId: string
) => void;
To:
export type FieldOnChangeCallback<TElement> = (
event: React.FormEvent<TElement>,
newValue: FieldValue,
fieldId: string,
store: FormStore
) => void;
Changing the last parameter from formId
to store
.
Also, figuring out which form's store instance you have is a bit tricky at the moment, because FormId
property is protected
. As TypeScript does not allow us to have different visibility property getter and setter and we cannot make a protected setter and public getter, the solution here is a public GetFormId()
method on a FormStore
.
Another observation is that public methods like GetFieldId
, GetFieldsGroupid
and similar ones should be moved out into helpers, because they are cluttering public API.