Integrate yup for validation
Merge request reports
Activity
added 11 commits
-
ada76654...9bcf1474 - 8 commits from branch
master - 914733ec - fix: import correct theme in styleguide
- 6b263191 - fix: lock to styled-components 2.4.0
- 398243ba - feat(submission): integrate yup for validation
Toggle commit list-
ada76654...9bcf1474 - 8 commits from branch
added 1 commit
- a503b49c - feat(submission): integrate yup for validation
added 4 commits
-
a503b49c...5cc7a989 - 3 commits from branch
master - e55570a1 - feat(submission): integrate yup for validation
-
a503b49c...5cc7a989 - 3 commits from branch
added 4 commits
-
e55570a1...1a20b700 - 3 commits from branch
master - 0f166fdf - feat(submission): integrate yup for validation
-
e55570a1...1a20b700 - 3 commits from branch
added 1 commit
- 89e93734 - refactor: define empty values in schema file
added 1 commit
- f4ede9cb - refactor: define empty values in schema file
mentioned in merge request !14 (closed)
From the Formik documentation:
As you can see above, validation is left up to you. Feel free to write your own validators or use a 3rd party library. Personally, I use Yup for object schema validation. It has an API that's pretty similar Joi / React PropTypes but is small enough for the browser and fast enough for runtime usage. Because I
Accordingly, @tamlyn and I thought Yup worth a try for form validation.
Bundle size is a good argument, valiadtionSchema prop is also a plus. API similarity (but still a difference) is a counter argument.
Is it possible to use yup as a drop-in joi-browser replacement for our use cases? In that case we should do it.
Is there a difference between what you want to validate on the server, and what you want to validate on the client?
Is there a difference between what you want to validate on the server, and what you want to validate on the client?
Yes, definitely. This is already the case in xpub. There are several steps in the process of submitting a manuscript where validation occurs:
- On the client, when filling out a form in a multi-step submission process. The user can't proceed to the next step until particular values are present and/or formatted correctly. This is the only case where we expect the values to be invalid and present helpful messages when they aren't.
- On the server, when saving an object to the database, as an intermediate step along the way to submission. For example, in the existing xpub-submit form, the manuscript's metadata (title, abstract, declarations etc) are saved periodically while the form is being filled out. Some leniency is appropriate here - we probably still want the values to be saved even if you haven't filled out a required field yet - but we might still want to verify the structure of the object being saved, for example.
- On the server, when completing the submission process. This is, I suspect, where we want to apply the most thorough validation of both object structure and values.
Edited by Aanand PrasadI only just noticed that, compared to existing xpub code, Yup isn't a replacement for Joi here - it's a replacement for xpub-validators. xpub-review and xpub-submit both use xpub-validators to perform client-side validation, so the minimum-work alternative would be to use that.
Having done a bit of research, Joi doesn't provide user-readable validation messages or an easy way to define them, so we'd still have to do that part - though there's a library called relish which looks like it can automate most of it.
Here's an attempt at using joi-browser for validation: 7b481448
- app/components/ui/atoms/ValidatedField.js 0 → 100644
14 const render = ({ field, form }) => { 15 const touched = get(form.touched, name) 16 const errors = get(form.errors, name) 17 18 let validationStatus 19 if (touched) validationStatus = 'success' 20 if (touched && errors) validationStatus = 'error' 21 22 return ( 23 <div> 24 <FieldComponent 25 validationStatus={validationStatus} 26 {...field} 27 {...props} 28 /> 29 {touched && errors && <ErrorMessage>{errors}</ErrorMessage>} Note these recent changes to make
ValidatedFieldmore accessible https://gitlab.coko.foundation/pubsweet/pubsweet/blob/master/packages/ui/src/atoms/ValidatedField.js#L43changed this line in version 10 of the diff
Thanks for doing the two implementations for comparison.
- The Yup API for providing custom errors is much nicer as it reduces duplication and keeps it all in one place. Joi's equivalent is not suitable for us.
- I think reusing validation schemas between server and client is a non-goal so I'd be happy with using different libs on the server and the client.
- Bundle size is actually quite comparable since we're bundling moment anyway. But two libraries will always be bigger than one so we should avoid including both in the front-end.
- But there's not much in it and we're not doing that much form validation so we could stick with Joi for now.
Edited by Tamlyn Rhodes
68 46 </Flex> 69 47 70 {assigneeFormOpen ? ( 71 <AssigneeForm 72 handleChange={handleChange} 73 handleClose={this.closeAssigneeForm} 74 values={values.assignee} 75 /> 76 ) : ( 77 <Button onClick={this.openAssigneeForm}> 78 Assign a colleague to handle this submission 79 </Button> 80 )} 81 </div> 48 <Flex> 49 <Box width={1}> mentioned in merge request !16 (merged)
added 4 commits
-
f4ede9cb...5dc6143a - 2 commits from branch
master - 15e0efcc - feat(submission): integrate yup for validation
- 67423b6e - refactor: define empty values in schema file
-
f4ede9cb...5dc6143a - 2 commits from branch
added 1 commit
- 545c2537 - refactor: use React.Fragment to avoid extraneous div
mentioned in commit 25abc506
