Which standard should we use for Validators?

[matheo]

We've seen some existing stuff at ngx-formly guide > validation
but we'd like to collect ideas and some practices from the community to manage validators and their output messages.

Please share your way to accomplish this on your forms, or thumb up an existing post 😄

[Yumitoya8569]

IMHO the "Matcher" in libraries udos86/ng-dynamic-forms
maybe a good reference for related ( validators / visible / disable ) state management

[Yumitoya8569]

1. ya, the matchers is better.

2. maybe more thing go in this way?

3. In normal case id is better , but few cases user want reference field which is in other path or ambiguity id

{
    group1:{
        text1: '',
        group2: {
            text1: ''
            myField: '' // this field want to reference 'group1.text1' not 'group2.text1'
        }
    }
}

How about providing the path feature implicitly in id ?

when: [
 { id: "group1.text1", value: "" } 
]

[matheo]

@Yumitoya8569 right now there's no id field in the DynControlConfig, only the name.
We could ref other fields by relative path, using a convention like operative systems maybe:

when: [
  { name: "../../group1/text1", value: "x" },
  { name: "/root/field", value: "/regex/" },
  { name: "group1.text1", value: "z" }
]

so the DynFormNode can process the specified syntax
and trigger the event inside the desired section of the controls tree.

I will build a diagram on how the things are working right now
so you can get the picture and dream with possibilities ;)

[matheo]

@Yumitoya8569 I've made this structure to show the core stuff happening inside dyn-forms:
myndpm-dyn-forms.pdf

There you can see that the main manager of the hierarchy is the DynFormNode which receives the config: DynBaseConfig and the respective control: AbstractControl when a DynControl is loaded.

While loading the Node, we can process a plain configuration object,
and there we can create the Validators and AsyncValidators for the control.
We just need to figure out a nice standard inside the DynBaseConfig and the Node will take care 😉

PS. Please tell me what do you think of the diagram.

[Yumitoya8569]

@matheo
Diagram is fine, but when i check DynFormNode code i don't get the point that how it tracking other node value change
maybe you could point it out for me? thx.

[matheo]

@Yumitoya8569 it's not implemented yet hehe, but in the load method, we can setup the matchers and validators/asyncValidators. If there's a matcher refering to another field, the Node will get it and listen to its valueChanges.

I will get the time to prototype that with a similar object to the one you posted above
and getting some inspiration from ng-conditional-validator of course :)

[matheo]

A collection of ideas:

1. We provide the custom Validators and AsyncValidators via tokens like:

providers: [
  { provide: DYN_VALIDATORS, useValue: { id: 'requiredCheckbox', fn: myValidatorFn }, multi: true },
  { provide: DYN_ASYNCVALIDATORS, useValue: { id: 'uniqueEmail', fn: myAsyncValidatorFn }, multi: true },
]

(I can build an utility to avoid boilerplate)

2. we use them from the Control Configurations like:

{
  control: 'CHECKBOX',
  options: { validators: { requiredCheckbox: null } }
},

3. We will need some errorHandlers to show the corresponding error message,
and we can configure many and the control will show the first message returned by a handler, like:

{
  control: 'INPUT',
  params: { type: 'email' },
  options: {
    asyncValidators: { uniqueEmail: [2] },
    errorHandlers: ['requiredHandler', 'uniqueEmailHandler']
  }
}

4. then we also implement the matchers:

interface DyMatcher {
  name: string; // matcherId  
  fn: DynMatcherFn; // something like (args) => (value):boolean   
}

and we provide these on another DYN_MATCHERS token to use them in a plain config:

{
  control: 'X',
  matchers: Array<{
    matcher: 'matcherId',
    match: 'DISABLED' | 'ENABLED' | 'HIDDEN' | 'VISIBLE' | 'REQUIRED' | 'INVALID',
    when: Array<DynMatcherCondition>
  }>
}

so if there's a match, then we apply the specified match (disable(), enable(), hide(), show(), apply(Validators.required), invalid()

So, basically the matchers are conditional validators right @Yumitoya8569? 😃
we can provide some defaults like notEqual(id1, id2) and match INVALID (following your example)

ow wow and this will be wired by default in these dynamic-forms!
I love the concept of your library! what do you think?

[Yumitoya8569]

Hi @matheo
It looks fine, but why abandon this structure?

{
  control: 'X',
  matchers: Array<{
    match: 'DISABLED' | 'ENABLED' | 'HIDDEN' | 'VISIBLE' | 'VALIDATOR' | 'ASYNC_VALIDATOR',
    args?: { [name: string]: any },  // like { uniqueEmail: [2] } or { invalid: '...' }
    when?: Array<DynMatcherCondition> // always match if no condition
  }>
}


/*---------------use case------------------*/

// control always disable
{
   control: 'X',
   matchers: [{ match: 'DISABLED' }]
}

// validators
{
   control: 'X',
   matchers: [{ match: 'VALIDATOR', args: { required: null, min: 3  } }]
}

// conditional validators
{
   control: 'X',
   matchers: [{ match: 'VALIDATOR', args: { required: null, min: 3 }, when:[ .... ] }]
}

// asyncValidators
{
   control: 'X',
   matchers: [{ match: 'ASYNC_VALIDATOR', args: { uniqueEmail: [2] }}]
}

// conditional asyncValidators
{
   control: 'X',
   matchers: [{ match: 'ASYNC_VALIDATOR', args: { uniqueEmail: [2] }, when:[ .... ] }]
}

[matheo]

@Yumitoya8569 it introduces a bit of boilerplate, compare:

{
   control: 'X',
   matchers: [{ match: 'VALIDATOR', args: { required: null, min: 3 } }]
}

with:

{
   control: 'X',
   options: { validators: { required: null, min: 3 }}
}

I love the matchers for conditional stuff, but not to enforce everything into that structure.
I see no harm supporting both approaches, the developer pick the more tasty one, don't you think? :)

[Yumitoya8569]

@matheo
ya, i'm focus in entities should not be multiplied unnecessarily
but the developer pick the more tasty one is important too! :)

[matheo]

This PR #21 implemented Validators and AsyncValidators
also the Matchers #23 are able to set Errors manually into the node.control, so I guess we're good in this topic now 🙂

I will write an article about this soon!

[Yumitoya8569]

Cheers! 🎉

I may be reading detail this weekend 🙂

[matheo]

Conditional validator added via Matcher here: 90554e3

[osmelpa86]

Hi, your library is very nice.
I'm exploring it right now and I wanted to know if the button text that is created when you use 'ARRAY' to create dynamic components can be changed.

createMatConfig('ARRAY', {
      name: 'products',
      factory: { cssClass: 'row' },
      params: {
        title: 'Products',
        subtitle: 'Items to checkout',
        initItem: true,
      },
      controls: [
        createMatConfig('INPUT', {
          name: 'product',
          options: { validators: ['required'] },
          factory: { cssClass: 'col-6 col-md-8' },
          params: { label: 'Product Name *' },
        }),
        createMatConfig('INPUT', {
          name: 'quantity',
          options: { validators: ['required', ['min', 1]] },
          factory: { cssClass: 'col-5 col-md-3' },
          params: { label: 'Quantity *', type: 'number' },
        }),
      ],
    })

[matheo]

Hi @osmelpa86 thanks for the kind words
Indeed, you can change that via params: array.component.params.ts:

createMatConfig('ARRAY', {
  params: {
    title: 'Products',
    ...
    addButton: 'Add new product',
  }

[osmelpa86]

Hello, how are you?
I thank you for the answer and excuse me for asking another question. Is it possible to customize the error messages. I ask you the question because I have created other forms that the error consists of an icon and then the error message and I do not know if it is possible.

[matheo]

@osmelpa86 ATM only string error messages are supported:

<mat-error *ngIf="errorMsg$ | async as errorMsg">{{ errorMsg }}</mat-error>

https://github.com/myndpm/open-source/blob/master/libs/forms/ui-material/src/components/input/input.component.html#L36

If you want to add a custom icon you might do it customizing the template in a custom Text implementation.