Feature/password validation #118
Conversation
… views to incorporate changes
|
So with validation out of the box are we still going to use this validation or would it be better to have our own? |
|
We should still use our own because our own validation library will allow for more customization. |
| * @param {object} initialFormState - The initial values of the form properties. | ||
| * @returns {...UseFormState} The useForm initial state. | ||
| */ | ||
| function init(schema, initialFormState) { |
There was a problem hiding this comment.
i feel like init should be at the top since it's kinda a constructor and that's where i initially looked when i saw 'init'
There was a problem hiding this comment.
Fair point. I can move that up. Actually, because init is not part of the useForm function, it can only be moved up to the top of the file. The component is going feel a bit buried, I think. What do you think?
|
|
||
| if (matchingProperty) return matchingProperty; | ||
|
|
||
| for (const property in schema) { |
There was a problem hiding this comment.
this for each confuses me, maybe i need to see it in action
There was a problem hiding this comment.
I'm going to rename schema to formSchema just to be clearer. It's matching up elements that have the matches option. For example:
const formSchemas =
{
pwd: new Schema(),
confPwd: new Schema().matches('pwd')
}; When confPwd fires an onchange event, validation is going to look at its schema and say ok confPwd matches up to pwd and it just plucks pwd's schema from the formSchemas. But when pwd fires an onchange event, its schema does NOT have a matches property on it.
The loop is going through all the formSchemas checking to see if any singular schema has a matches property whose value is pwd, and in this particular case confPwd's schema does contain exactly that.
By doing this, we're forcing validation for both elements each time one of them changes.
| * @example | ||
| * validateType(5, isBoolean); // Error: Value must be of type boolean. | ||
| */ | ||
| export function validateType(value, callback) { |
There was a problem hiding this comment.
If these utils are intended to be used by developers rather than requiring a user to pass the callback themselves I think there could be a better way to handle it. But that would take some thought. If intended to be a private function then this should be fine
There was a problem hiding this comment.
I didn't want to have a separate function for each type that's why I opted for the callback. It's not really meant to be exported outside of the project.
| * @param {Event} [event=null] - The form submit event. | ||
| * @returns {Promise<void>} Nothing. | ||
| */ | ||
| async function handleSubmit(submitForm, event = null) { |
There was a problem hiding this comment.
should this parameter be called submitCallback rather than submitForm. submitForm makes me think of an html element
| INVALID_MIN_MAX: 'Minimum or maximum length cannot be less than the number of required characters' | ||
| }; | ||
|
|
||
| export const VALIDATION_ERROR_MESSAGES = { |
There was a problem hiding this comment.
are these also specific to oneleif, would be best to allow users to have their own error messages if possible
There was a problem hiding this comment.
This is the default for the package. I'm actually working on letting the user set their own error messages right now.
Closes #88