Add foundations for extensible validation in forms #6161

sneridagh · 2024-07-10T14:48:33Z

No description provided.

netlify · 2024-07-10T14:48:48Z

✅ Deploy Preview for plone-components canceled.

Name	Link
🔨 Latest commit	`3152854`
🔍 Latest deploy log	https://app.netlify.com/sites/plone-components/deploys/6698c82ca89ad600086fc5c5

* main: Remove `react-share` library and `SocialSharing` component (#6162)

ericof · 2024-07-14T23:20:31Z

@wesleybl, @luxcas This is about getting validation also on blocks

tiberiuichim · 2024-07-16T07:52:23Z

docs/source/configuration/validation.md

+```
+
+It takes two `dependencies`.
+The first element should be the `default` identifier, and the second you can set it up to identify the validator.


It's not explained why default should be the first identifier.

tiberiuichim · 2024-07-16T07:52:47Z

docs/source/configuration/validation.md

+```ts
+config.registerComponent({
+  name: 'fieldValidator',
+  dependencies: ['integer', 'maximum'],


Here the default is missing.

ummm, in that line, the default is not needed here, because it's not a default validator, it's a type one, so the first dependency is the name of the type.

tiberiuichim · 2024-07-16T07:57:16Z

docs/source/configuration/validation.md

+    customField: {
+      title: 'Default field',
+      description: '',
+      validator: 'isURL',


Maybe allow passing directly a validator function as well? We're way past the point "schemas should be serializable" and for one-offs it's easier to declare them inline.

If the pattern we are teaching is go for "named" components and call them by name (partially because of the duality forms from the backend/content types and the client defined forms in blocks), I'd refrain to do so, because then we will have two use cases, one where you can do it, and another use case in which you can't.

Also, in terms of explaining this in docs will became tricky and separate this is already confusing (I've been there when reviewing this with @ericof). Some other considerations is testability, because in that regard, modularization >> inlining things.

So, in principle, I would be -1 for this.

docs/source/upgrade-guide/index.md

packages/volto/src/helpers/MessageLabels/MessageLabels.js

davisagli · 2024-07-18T04:09:16Z

docs/source/configuration/validation.md

+  name: 'fieldValidator',
+  dependencies: ['phoneNumber', 'isValidPhone'],
+  component: phoneValidator,
+});


What makes this a widget validator instead of a type validator?

davisagli · 2024-07-18T04:15:01Z

docs/source/configuration/validation.md

+});
+```
+
+The first dependency should be the `id` of the block, and the second the `id` of the field.


Isn't it the @type of the block?

davisagli · 2024-07-18T04:20:26Z

docs/source/configuration/validation.md

+```
+
+It does not need to be tied to any field `type` or `widget` definition.
+It runs in addition to all the above, so it complements the other validators if any apply.


My biggest piece of feedback on this overall is using an array for the dependencies feels like trying to fit a square peg into a round hole. It's quite hard to keep track of all the different ways validators can be registered and which values need to go in the dependencies for each one. And it also seems to be like there might be some ambiguous cases, like if there is a field type and a widget type with the same name.

I don't know if the registry supports this but would it be possible to make things a bit more explicit by specifying the dependencies as an object instead of an array? So for example:

config.registerComponent({ name: 'fieldValidator', dependencies: { blockType: 'slider', fieldName: 'url', validatorName: 'isURL', }, component: urlValidator, });

@davisagli TBH, I'm not fully satisfied with it... I thought that the reason was mainly because we can't get it to work as satisfying as the ZCA works :) As you know, I initially envisioned and implemented the resolution algorithm using a string and concating the deps if we have an array, so I've played with that concept, even in the new getComponents registry API method.

Using an object would be possible too, I guess. I can play with the idea, and leave the original API in place also.

@davisagli I did an initial implementation of using an object instead of an array but I have doubts on how to hash the resultant key to store that object, so then getComponents work in the same simple way, under the same concepts that we had before. It does work, but under some assumptions that I do not like or they are not satisfactory/safe :/

Maybe if you have some time, we can talk about it.

Co-authored-by: David Glick <[email protected]>

tiberiuichim · 2024-07-19T05:56:15Z

~~@sneridagh Is it possible to pass parameters to validators? For example, if I have a validator "minmax", would I have to create and register a custom one for each use case?~~

Edit: nevermind, the validator function gets the field definition, so it's possible to set those in the schema

stevepiercy · 2024-07-19T06:41:41Z

docs/source/configuration/validation.md

+
+### `default` validators
+
+These validators are registered and applied to all fields.


For context, does "all" mean for all form blocks, or something else? I guess form blocks, but please correct me, if not.

Suggested change

These validators are registered and applied to all fields.

Default validators are registered and applied to all fields for all form blocks.

stevepiercy · 2024-07-19T06:54:10Z

docs/source/configuration/validation.md

+});
+```
+
+It takes two `dependencies` being the first element a fixed `default` identifier, and the second you can set it up to identify the validator itself.


We need to flesh out what the dependencies key actually means and how to use it.

What's the purpose of the default identifier?

Can I use more than two identifiers in the dependencies array?

Suggested change

It takes two `dependencies` being the first element a fixed `default` identifier, and the second you can set it up to identify the validator itself.

The `dependencies` key accepts an array of two values.

The first element has the identifier of `default`, and the second element has the identifier of the validator.

The second identifier can be any string.

In the following example, the second identifier is `minLength`.

stevepiercy · 2024-07-19T06:55:34Z

docs/source/configuration/validation.md

+```
+
+It takes two `dependencies` being the first element a fixed `default` identifier, and the second you can set it up to identify the validator itself.
+In the case of the example, this other dependency is `minLength`.


Suggested change

In the case of the example, this other dependency is `minLength`.

stevepiercy · 2024-07-19T06:55:45Z

docs/source/configuration/validation.md

+
+It takes two `dependencies` being the first element a fixed `default` identifier, and the second you can set it up to identify the validator itself.
+In the case of the example, this other dependency is `minLength`.
+It can be any string.


Suggested change

It can be any string.

stevepiercy · 2024-07-19T07:01:49Z

docs/source/configuration/validation.md

+  dependencies: ['default', 'minLength'],
+  component: minLengthValidator,
+});
+```


Let's move the example after the explanation. It's jarring to throw an example before its description without some kind of introduction.

stevepiercy · 2024-07-20T10:47:52Z

docs/source/configuration/validation.md

+
+Volto provides a set of validators by default, you can find them in this module: `packages/volto/src/config/validators.ts`
+
+### How to override them


Suggested change

### How to override them

### Override Volto's default validators

stevepiercy · 2024-07-20T10:49:28Z

docs/source/configuration/validation.md

+
+### How to override them
+
+You can override them in your add-on as any other component defined in the registry, by redefining them using the same `dependencies`, and providing your own.


Suggested change

You can override them in your add-on as any other component defined in the registry, by redefining them using the same `dependencies`, and providing your own.

You can override Volto's default validators in your add-on as any other component defined in the registry.

To do so, use the `dependencies` key, and provide your own values.

```{todo}

Provide usage example.

```

stevepiercy · 2024-07-20T10:51:01Z

docs/source/configuration/validation.md

+};
+```
+
+This is an example of an `isNumber` validator:


Suggested change

This is an example of an `isNumber` validator:

The following example shows an `isNumber` validator.

stevepiercy · 2024-07-20T10:52:26Z

docs/source/configuration/validation.md

+};
+```
+
+Using the `formData` you can perform validation checks using other field data as source.


Suggested change

Using the `formData` you can perform validation checks using other field data as source.

Using `formData`, you can perform validation checks between multiple fields' data.

stevepiercy · 2024-07-20T10:54:11Z

docs/source/configuration/validation.md

+```
+
+Using the `formData` you can perform validation checks using other field data as source.
+This is interesting in the case that two fields are related, like `start` and `end` dates.


Suggested change

This is interesting in the case that two fields are related, like `start` and `end` dates.

This is useful when you need to compare the values of multiple fields, such as ensuring that the end date and time of an event is after its start.

```{todo}

Provide usage example.

```

ichim-david · 2024-07-29T05:27:33Z

Closing this pull request since we have the superseding #6181

Add foundations for extensible validation in forms

d02a64b

sneridagh requested review from davisagli, ichim-david, ericof and pnicolli July 10, 2024 14:48

sneridagh added 11 commits July 10, 2024 16:57

Fix tests

d4a6d70

fix build-deps precedence

bc7b779

Fix more

ad3a0d6

Fix generator tests

1fa71ed

Fix react-share package

f6bba96

fix test for social sharing

3a4b000

Add custom validation field property

709ed59

Merge branch 'main' into extensible-validation

84bc5bf

* main: Remove `react-share` library and `SocialSharing` component (#6162)

Fix uniqueValidator

26c82f9

Add documentation

3378ade

Changelog

0101fca

sneridagh requested a review from stevepiercy July 12, 2024 13:44

sneridagh added 3 commits July 12, 2024 15:45

Changelog

7f2cfaa

Checkpoint

7963197

Validation for blocks too :)

b135545

sneridagh and others added 7 commits July 15, 2024 11:05

locales

3d6ef22

Refactor validation in Form

80d7462

Changelog

9ad0eea

Separate type-widget validators. Add behavior-fieldId validator types.

6234d48

Block-fieldId validators

30db8cd

Changelog

bef6a77

Typos correction for validation.md

41da3fb

sneridagh mentioned this pull request Jul 16, 2024

fix: ineffectiveness of the "Whole Day" and "Open End" checkbox in Event forms (#3243) #6165

Open

tiberiuichim reviewed Jul 16, 2024

View reviewed changes

Complete default explanation

2a32edc

dobri1408 mentioned this pull request Jul 16, 2024

(feat): Show error in metadata section refs 269086 eea/volto-metadata-block#50

Merged

Add more down to earth examples

34490f9

ichim-david requested review from avoinea and a team July 16, 2024 10:50

davisagli reviewed Jul 18, 2024

View reviewed changes

Apply suggestions from code review

3152854

Co-authored-by: David Glick <[email protected]>

stevepiercy requested changes Jul 20, 2024

View reviewed changes

sneridagh mentioned this pull request Jul 22, 2024

Extensible validation support in Volto forms #6181

Merged

stevepiercy added a commit that referenced this pull request Jul 22, 2024

carry over suggestions from #6161 to index.md

0b4f253

ichim-david closed this Jul 29, 2024

ichim-david deleted the extensible-validation branch July 29, 2024 05:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add foundations for extensible validation in forms #6161

Add foundations for extensible validation in forms #6161

sneridagh commented Jul 10, 2024 •

edited

Loading

netlify bot commented Jul 10, 2024 •

edited

Loading

ericof commented Jul 14, 2024

tiberiuichim Jul 16, 2024

tiberiuichim Jul 16, 2024

sneridagh Jul 16, 2024

tiberiuichim Jul 16, 2024

sneridagh Jul 16, 2024

davisagli Jul 18, 2024

davisagli Jul 18, 2024

davisagli Jul 18, 2024

sneridagh Jul 18, 2024 •

edited

Loading

sneridagh Jul 18, 2024

tiberiuichim commented Jul 19, 2024 •

edited

Loading

stevepiercy Jul 19, 2024

stevepiercy Jul 19, 2024

stevepiercy Jul 19, 2024

stevepiercy Jul 19, 2024

stevepiercy Jul 19, 2024

stevepiercy Jul 20, 2024

stevepiercy Jul 20, 2024

stevepiercy Jul 20, 2024

stevepiercy Jul 20, 2024

stevepiercy Jul 20, 2024

ichim-david commented Jul 29, 2024


		### `default` validators

		These validators are registered and applied to all fields.

	These validators are registered and applied to all fields.
	Default validators are registered and applied to all fields for all form blocks.

-It takes two `dependencies` being the first element a fixed `default` identifier, and the second you can set it up to identify the validator itself.
+The `dependencies` key accepts an array of two values.
+The first element has the identifier of `default`, and the second element has the identifier of the validator.
+The second identifier can be any string.
+In the following example, the second identifier is `minLength`.


		Volto provides a set of validators by default, you can find them in this module: `packages/volto/src/config/validators.ts`

		### How to override them

	### How to override them
	### Override Volto's default validators


		### How to override them

		You can override them in your add-on as any other component defined in the registry, by redefining them using the same `dependencies`, and providing your own.

-You can override them in your add-on as any other component defined in the registry, by redefining them using the same `dependencies`, and providing your own.
+You can override Volto's default validators in your add-on as any other component defined in the registry.
+To do so, use the `dependencies` key, and provide your own values.
+```{todo}
+Provide usage example.
+```

	This is an example of an `isNumber` validator:
	The following example shows an `isNumber` validator.

	Using the `formData` you can perform validation checks using other field data as source.
	Using `formData`, you can perform validation checks between multiple fields' data.

Add foundations for extensible validation in forms #6161

Add foundations for extensible validation in forms #6161

Conversation

sneridagh commented Jul 10, 2024 • edited Loading

netlify bot commented Jul 10, 2024 • edited Loading

✅ Deploy Preview for plone-components canceled.

ericof commented Jul 14, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sneridagh Jul 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tiberiuichim commented Jul 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ichim-david commented Jul 29, 2024

sneridagh commented Jul 10, 2024 •

edited

Loading

netlify bot commented Jul 10, 2024 •

edited

Loading

sneridagh Jul 18, 2024 •

edited

Loading

tiberiuichim commented Jul 19, 2024 •

edited

Loading