Ngx-formly: @ngx-formly/json-schema

[juristr]

1. Progress of supported schema:

• [x] string
  
  
  
  • [x] Length (minLength, maxLength)
  
  
  • [x] Regular Expressions (pattern)
  
  
  • [ ] Format
  
  
• [x] Numeric types
  
  
  
  • [x] integer
  
  
  • [x] number
  
  
  • [x] Multiples (multipleOf)
  
  
  • [x] Range (minimum, exclusiveMinimum, maximum and exclusiveMaximum)
  
  
  • [x] minimum and maximum
  
  
  • [x] exclusiveMinimum and exclusiveMaximum
  
  
• [x] object
  
  
  
  • [x] Properties
  
  
  • [x] Required Properties
  
  
  • [ ] Property names
  
  
  • [ ] Size
  
  
  • [x] Dependencies
  
  
  • [ ] Pattern Properties
  
  
• [x] array
  
  
  
  • [x] Items
  
  
  • [x] Length
  
  
  • [x] Uniqueness
  
  
  • [ ] contains
  
  
• [x] boolean
• [x] null
• [x] Generic keywords
  
  
  
  • [x] Annotations (title, description, default)
  
  
  • [x] Enumerated values
  
  
  • [x] Constant values
  
  
• [ ] Media: string-encoding non-JSON data
  
  
  
  • [ ] contentMediaType
  
  
  • [ ] contentEncoding
  
  
• [ ] Combining schemas
  
  
  
  • [x] allOf
  
  
  • [x] anyOf
  
  
  • [x] oneOf
  
  
  • [ ] not
  
  
• [ ] Applying subschemas conditionally (if, then and else)
• [x] Structuring a complex schema
  
  
  
  • [x] $ref
  
  
  • [ ] $id
  
  
• [ ] extra options
  
  
  
  • [x] widget
  
  
  • [x] map
  
  
  • [ ] uiSchema
  
  
  • [ ] convert formly schema to json-schema
  
  

2. add @ngx-formly/json-schema

3.Docs

• [ ] add guide section
• [ ] improve demo examples
• [ ] options
  
  
  
  • [ ] widget
  
  
  • [ ] map
  
  
  • [ ] uiSchema
  
  

[juristr]

@aitboudad @kenisteward I've followed your issue #1348 and I'd like to start developing on some of those things (as mentioned in my original issue description), specifically I'd need

• dynamic select boxes/autocompletes (i.e. where the data is fetched on the fly by giving it a source URL to the API)
• datepickers

And for those, the main issues I'm currently encountering is

1. where to define the "widget" to use, i.e. <select> or some custom autocomplete, basically what would then translate to some formly type.
2. where to put custom attributes, like the source (or how you'd call it) property that specifies the URL where to fetch the entries for the select box

I started giving a look to:

• https://mozilla-services.github.io/react-jsonschema-form/
• http://guillotina.io/ngx-schema-form/dist/ngx-schema-form/json

They often use a widget property, which seems to be custom though, as I couldn't find it in the spec. We had a similar strategy, like for mapping an autocomplete of people like

{
  "title": "test",
  "type": "object",
  "properties": {
    "personId": {
      "type": "integer",
      "title": "Owner",
      "widget": {
        "type": "autocomplete",
        "source": "/api/options/people.json"
      }
    }
  }
}

What's your opinion on this?

[kenisteward]

The main issue here is there is no concept of a "layout.json" yet. This
I'd something I've been looking into adding for the json-schema generations
for the past month. I've gone through 1 or 2 partial iterations and am
formulating a plan for it. I can post my findings here or start a new issue
for it
I've also taken some inspiration from
Angular6-json-schema-form.

The biggest issue with that project is it is not maintained.

Once we have the concept of the layout.json in formly ( which awkwardly
enough can technically be a formly config ) we can use that while parsing
the fields to define formgroup layouts and special options like the one you
stated.

On Thu, Mar 7, 2019, 8:23 AM Juri Strumpflohner [e-mail]
wrote:

@aitboudad https://github.com/aitboudad @kenisteward
https://github.com/kenisteward I've followed your issue #1348
https://github.com/ngx-formly/ngx-formly/issues/1348 and I'd like to
start developing on some of those things (as mentioned in my original issue
description), specifically I'd need

• dynamic select boxes/autocompletes (i.e. where the data is fetched
  on the fly by giving it a source URL to the API)
• datepickers

And for those, the main issues I'm currently encountering is

1. where to define the "widget" to use, i.e. or some custom
   autocomplete, basically what would then translate to some formly type.
   where to put custom attributes, like the source (or how you'd call
   it) property that specifies the URL where to fetch the entries for the
   select box

   I started giving a look to:

   • https://mozilla-services.github.io/react-jsonschema-form/
   • http://guillotina.io/ngx-schema-form/dist/ngx-schema-form/json

   They often use a widget property, which seems to be custom though, as I
   couldn't find it in the spec. We had a similar strategy, like for mapping
   an autocomplete of people like

   {
   "title": "test",
   "type": "object",
   "properties": {
   "personId": {
   "type": "integer",
   "title": "Owner",
   "widget": {
   "type": "autocomplete",
   "source": "/api/options/people.json"
   }
   }
   }
   }

   Validating it against this validator https://www.jsonschemavalidator.net/
   seems to work and be valid.

   What's your opinion on this?

   —
   You are receiving this because you were mentioned.
   Reply to this email directly, view it on GitHub
   https://github.com/ngx-formly/ngx-formly/issues/1459#issuecomment-470544383,
   or mute the thread
   https://github.com/notifications/unsubscribe-auth/AMPLtWJ7GJuiHdDPBeTnQqLAUKm_8NEEks5vUSDjgaJpZM4bir7f
   .

   kenisteward on 7 Mar 2019

   👍2

   Also one of the key things I wanted to do was to make sure we started with
   the separate layout.json and allowed it to be combined later.

   Also one of the issues with the form given now is that you can't make
   arbitrary wrapper elements in that form. You can only define fields for
   elements. Defining arbitrary wrapper elements for grouping of elements is
   basically a must have.

   On Thu, Mar 7, 2019, 8:30 AM Kenneth Steward [e-mail] wrote:

   The main issue here is there is no concept of a "layout.json" yet. This
   I'd something I've been looking into adding for the json-schema generations
   for the past month. I've gone through 1 or 2 partial iterations and am
   formulating a plan for it. I can post my findings here or start a new issue
   for it
   I've also taken some inspiration from
   Angular6-json-schema-form.

   The biggest issue with that project is it is not maintained.

   Once we have the concept of the layout.json in formly ( which awkwardly
   enough can technically be a formly config ) we can use that while parsing
   the fields to define formgroup layouts and special options like the one you
   stated.

   On Thu, Mar 7, 2019, 8:23 AM Juri Strumpflohner [e-mail]
   wrote:

   @aitboudad https://github.com/aitboudad @kenisteward
   https://github.com/kenisteward I've followed your issue #1348
   https://github.com/ngx-formly/ngx-formly/issues/1348 and I'd like to
   start developing on some of those things (as mentioned in my original issue
   description), specifically I'd need

   • dynamic select boxes/autocompletes (i.e. where the data is fetched
     on the fly by giving it a source URL to the API)
   • datepickers

   And for those, the main issues I'm currently encountering is

   1. where to define the "widget" to use, i.e.

   or some custom
   autocomplete, basically what would then translate to some formly type.
2. where to put custom attributes, like the source (or how you'd call
   it) property that specifies the URL where to fetch the entries for the
   select box

I started giving a look to:

• https://mozilla-services.github.io/react-jsonschema-form/
• http://guillotina.io/ngx-schema-form/dist/ngx-schema-form/json

They often use a widget property, which seems to be custom though, as I
couldn't find it in the spec. We had a similar strategy, like for mapping
an autocomplete of people like

{
"title": "test",
"type": "object",
"properties": {
"personId": {
"type": "integer",
"title": "Owner",
"widget": {
"type": "autocomplete",
"source": "/api/options/people.json"
}
}
}
}

Validating it against this validator https://www.jsonschemavalidator.net/
seems to work and be valid.

What's your opinion on this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459#issuecomment-470544383,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMPLtWJ7GJuiHdDPBeTnQqLAUKm_8NEEks5vUSDjgaJpZM4bir7f
.

[aitboudad]

If you're ok with that, I'll post ideas on how to evolve the current implementation here to discuss with you

that's a good news, my thought about this part can be found here https://github.com/ngx-formly/ngx-formly/issues/1056#issuecomment-410301293

what's currently possible

the majority of use-cases, except two parts which are mentioned in the V6 roadmap:

• custom validation
• allow passing custom UISchema

react-jsonschema-form is a good lib to follow, once we've done with that part, the next step is to wrap the FormlyJsonschema service within a component.

[juristr]

I can post my findings here or start a new issue
for it

If ur ok, let's post here and use this as the main discussion issue around evolving the json-schema part of formly (if also @aitboudad agrees).

I've also taken some inspiration from
Angular6-json-schema-form.
The biggest issue with that project is it is not maintained.

Ya, I've quickly seen that one too. Well, if it is not maintained, we might take inspiration from their ideas and port it over.

Also one of the key things I wanted to do was to make sure we started with
the separate layout.json and allowed it to be combined later.

Sounds good for me, would love to get some more insight in your ideas.

Also one of the issues with the form given now is that you can't make
arbitrary wrapper elements in that form. You can only define fields for
elements. Defining arbitrary wrapper elements for grouping of elements is
basically a must have.

💯 agree.

[juristr]

the majority of use-cases

@aitboudad how would you implement the "widget" scenario though? Like distinguishing between an autocomplete, date picker,...?

[aitboudad]

how would you implement the "widget" scenario though? Like distinguishing between an autocomplete, date picker,...?

If I'm not mistaken that would be solved by UISchema which can be passed as a second argument to
FormlyJsonschema::toFieldConfig but I think your proposal is better if it's a valid json-schema.

[juristr]

If I'm not mistaken that would be solved by UISchema

Yep I've seen the usage of UISchema in the react form example. The UISchema allows for sure to have more complex configurations, having a widget directly attached, makes it a bit easier to handle everything though, from the server side that generates the JSONSchema as well as the client-side. I've seen that being used in ngx-schema-form.
From a first check it seems to be "valid", in the sense it's being ignored as far as I could tell. Pasted it into the https://www.jsonschemavalidator.net/, although I'm not 100% sure that tool does a proper validation. I'll check.

Do you have any prefs on how that widget should be structured internally?

[aitboudad]

Do you have any prefs on how that widget should be structured internally?

The more we're in line with the existing solution the more is better but always keep it simple,
if possible widget should be FormyFieldConfig which will be merged with the converted field:

mySchema = {
  "properties": {
    "pageContent": {
      "type": "string",
      "description": "Page content",
      "widget": {
        "type": "select",
        "templateOptions": {
          ...
        }
      }
    }
  }
}

well if that is allowed, it can be implemented easily by merging the converted field with the widget

[juristr]

well if that is allowed, it can be implemented easily by merging the converted field with the widget

Agree 👍 . @kenisteward any insights from your part? Otherwise I'll provide a PR with a 1st implementation of the widget prop.

the widget.type would then overwrite the formlyFieldConfig.type in case it is specified. Thus if I have a formly type registered - say ng-select, then I could specify ng-select on that widget.type & it would automatically instantiate that formly field.

[kenisteward]

@juristr

https://www.jsonschemavalidator.net/

is a reference to using schema 7 spec. In that, you are allowed to have any additional properties based on the base schema spec for a jsonSchema. That is why it doesn't fail.

Via remote url that returns [{ label: '...', value: ...}, ...]

The proper utilization for what should be returned in a schema is defined here:
https://github.com/json-schema-org/json-schema-spec/issues/57#issuecomment-247861695

This basically states that a value will be oneOf these schemas which are represented by const/title combination. Other libraries implement this as should we. This allows for your schema to define what your select list options should be.

https://hamidihamza.com/Angular6-json-schema-form/?set=ng-jsf&example=ng-jsf-select-list-examples&framework=material-design&language=en

is an example of the idea in angular6-json-schema-form

The reason I bring this up is what you could do is for the field add a $ref link to get a "schema" that is dynamically generated based on the values you want it in. That way when the fields are being built from the schema we can have them there. If your use case is for live updates as they type though then we'd just have to implement it in the field like you have it.

well if that is allowed, it can be implemented easily by merging the converted field with the widget

Agree 👍 . @kenisteward any insights from your part? Otherwise I'll provide a PR with a 1st implementation of the widget prop.

I'm not sure currently how we can use this setup to allow arbitrary wrappers for fields.
Example: https://hamidihamza.com/Angular6-json-schema-form/?set=ng-jsf&example=ng-jsf-flex-layout&framework=material-design&language=en

Adding the widget option would 100 percent allow us to have layout information for specific fields but I don't think it allows us to say:

with this example schema:

 {
   "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "properties": {
      "first_name": { "type": "string" },
      "last_name": { "type": "string" },
      "address": {
        "type": "object",
        "properties": {
          "street_1": { "type": "string" },
          "street_2": { "type": "string" },
          "city": { "type": "string" },
          "state": {
            "type": "string",
            "enum": [ "AL", "AK", "AS", "AZ", "AR", "CA", "CO", "CT", "DE",
                "DC", "FM", "FL", "GA", "GU", "HI", "ID", "IL", "IN", "IA",
                "KS", "KY", "LA", "ME", "MH", "MD", "MA", "MI", "MN", "MS",
                "MO", "MT", "NE", "NV", "NH", "NJ", "NM", "NY", "NC", "ND",
                "MP", "OH", "OK", "OR", "PW", "PA", "PR", "RI", "SC", "SD",
                "TN", "TX", "UT", "VT", "VI", "VA", "WA", "WV", "WI", "WY" ]
          },
          "zip_code": { "type": "string" }
        }
      }
    },
    "required": [ "last_name" ]
  }

Say:

I want to put first_name and last_name with address.street_1 on the same row
then put the rest of the fields within address inside a wrapper container element.

I think with formly, you normally have to create those "wrapper container" formgroups by hand and put what fields you want to in them (I did this with the first iteration of the form maker I'm trying internally).

Sorry for the wall of text :(

[aitboudad]

I want to put first_name and last_name with address.street_1 on the same row
then put the rest of the fields within address inside a wrapper container element.

well it can be done :) here is an early implementation: https://stackblitz.com/edit/angular-rbv4qw

[aitboudad]

in the end, I think we should provide both ways because for a large form it's better to separate your UI config from your schema.

[kenisteward]

@aitboudad THIS IS EVIL MAGIC SORCERY AND I LOVE IT!

I'm all for this type of layout.json.

If I understand this correct, we could also set a formly wrapper component set and have it generically handle making "sections". I see you just used a class here to get the point across and it looks great!

The only thing that was throwing me off is that in the schema that was input into the toFormlyConfig() function, it had the address.street1 in a different place than it should show in the original schema when validated but it properly was in the correct place in the form data. That may be because they are combined and so in the combined state it represents layout first and then the underlying data with the key names. the most important thing is to make sure that when the data is sent across it is in the proper format of the original "data schema" which I think this covers anyway.

in the end, I think we should provide both ways because for a large form it's better to separate your UI config from your schema.

100% agree. I'm personally working on multiple large form sets and have had to split them down and found it easier to work on with the two separate.

[juristr]

Awesome guys 🎉. So I guess we can agree on the widget object being used. Let's start incrementally. Most probably on Monday I'll start with a first PR for implementing a select that can be bound to an API endpoint for fetching the data. I'll post my JSONSchema definition here before starting the implementation.

Thx for now :)

[kenisteward]

https://json-schema.org/understanding-json-schema/structuring.html

https://json-schema.org/latest/json-schema-core.html#rfc.section.8.3

This is something else I thought we want to make sure we support. Right now, the implementation knows nothing of $ref ( local or external reference ) the spec right now states that if $ref is found all of the validation keys ( type, minlength, maximum etc) should be pulled from ref and ignored in the schema referencing it. Annotations like $comment , title, description etc don't have to be. Different forms validators handle it differently.

Also in spec 8 (coming soon) there will be a definition for saying which pieces in a ref you want to take ( I think ).

[juristr]

Alright, so I started implementing the select with dynamic data. @aitboudad I like the "MAGIC SORCERY" (as @kenisteward called it 😄 ) from your example.

I'd add the..

if (schema['widget']) {
    return reverseDeepMerge(field, schema['widget']);
}

...part into the current FormlyJsonschema. The only thing I'd change is to maybe move it into a sub-property of the widget. like

{
   ...
   widget: {
      formlyConfig: { ... }
   }
}

The main reason is to allow having other configs in the widget part as well, which Formly shouldn't just merge onto the config by default. Just like in my case with the select, I'm having

{
   ...
   widget: {
      source: '/api/options/people.json',
      formlyConfig: { 
        type: 'select'
     }
   }
}

That way, Formly automatically merges the select configuration, and after that I check for the source property and load the according data onto that templateOptions.options in whatever way I like.

---

Another point: What do you think about changing the current signature of the toFieldConfig in a way to add an optional mapFn?

toFieldConfig(jsonSchema: JSONSchema7, mapFn?: mappingCallbackFn): FormlyFieldConfig {
  ...
}

..where the mapFn is defined as

export type mappingCallbackFn = (mappedField: FormlyFieldConfig, mapSource: JSONSchema7) => FormlyFieldConfig;

That allows to hook that in and get called back by Formly for each field config. Basically the FormlyJsonschema would do its mapping first and then call the mapFn (if defined), passing the mapped FormlyFieldConfig + the original JSONSchema part that was used to create it.

This gives you full flexibility to hook into the mapping process if needed.

Any thoughts on this?

[aitboudad]

Alright, so I started implementing the select with dynamic data. @aitboudad I like the "MAGIC SORCERY" (as @kenisteward called it smile ) from your example.

me too, that comment is much magic too :smile:

The only thing I'd change is to maybe move it into a sub-property of the widget. like ...

it makes sense

Another point: What do you think about changing the current signature of the toFieldConfig in a way to add an optional mapFn?

I'm ok with that but I would prefer the following signature instead, to allow adding more options if needed.

toFieldConfig(jsonSchema: JSONSchema7, options: { mapFn?: mappingCallbackFn}): FormlyFieldConfig {
}

[juristr]

I'm ok with that but I would prefer the following signature instead, to allow adding more options if needed.

Oh yes absolutely 👍

I'll submit a PR once I have it. (working on it again tomorrow probably)

[Adam-Michalski]

What about allowing a value to be validated against multiple criteria at the same time.

https://json-schema.org/understanding-json-schema/reference/combining.html

{
  "anyOf": [
    { "type": "string", "maxLength": 5 },
    { "type": "number", "minimum": 0 }
  ]
}

The keywords used to combine schemas are:

allOf: Must be valid against all of the subschemas
anyOf: Must be valid against any of the subschemas
oneOf: Must be valid against exactly one of the subschemas
All of these keywords must be set to an array, where each item is a schema.

In addition, there is:

not: Must not be valid against the given schema

Or
Is this element already implemented? I couldn't find it.

[aitboudad]

@Adam-Michalski not yet, based on the provided description it shouldn't be hard to implement using the map callback until formly support that part.

I'll try to provide an example when time allows.

[aitboudad]

Updated the summary of this issue :) to track all remaining features.
The $ref and dependencies are implemented a PR is scheduled next week :+1:

Once done with the remaining part, in V6.1 the FormlyJsonschema service will be wrapped within a component and moved into a sub-package @ngx-formly/json-schema:

<formly-json-schema [schema]="schema" [uiSchema]="uiSchema" [options]="options">
<formly-json-schema>

[kenisteward]

@aitboudad were you able to implement dependencies with $id and async http calls in mind. I've been trying to figure out a non obtrusive way to do it. I was only able to figure out non url based ones with the current api because asyc // await kinda messed things up.

My original idea was to follow suit with ajv and make a separate "compileAsync" function but that seemed not as good

[juristr]

@kenisteward I'm doing that right now by having a JSON schema like

anotherId: {
      type: 'integer',
      title: 'Some Select',
      widget: {
        source: '/api/options/people.json',
        formlyConfig: {
          type: 'select'
        }
      },
      propertyOrder: 2
    },

..and then by using the formlyJsonSchema.toFieldconfig(jsonSchema, ..) and the according map that can be passed to it to wrap all the configs having a widget.source defined in an observable HTTP call. Something like

this.formlyJsonSchema.toFieldConfig(jsonSchema, {
    map: (field: FormlyFieldConfig, source: JSONSchema7) => {
        // TODO: manually map the http observable here to the field
    }
})

That works pretty good

[kenisteward]

@juristr

Could you give a full example of your json?
I wouldn't just be filling in a select or a particular field. This would be more for resolving external schemas by the Json schema spec

E.g. https://json-schema.org/understanding-json-schema/structuring.html

Scroll down to the example with using $id with $ref

Also the actual specification here is a really good example.
https://json-schema.org/latest/json-schema-core.html#rfc.section.8.2.4

[aitboudad]

@kenisteward Remote schemas not supported yet, the solution is to add an options for that:

toFieldConfig(schema, { resolveSchema: (url) => this.http.get(url) });

and in that case toFieldConfig will be async

[kenisteward]

This is actually what I had in mind but I wasn't sure if you also were okay with making the whole function asynchronous

[kenisteward]

@aitboudad did you end up making the PR? I was going to add the async to what you had and I didn't want to end up causing merge issues.

[aitboudad]

@kenisteward I've pushed my initial work (https://github.com/aitboudad/ngx-formly/tree/json-schema-deps) but I'd prefer you to wait until I'm getting back to work next week.

[olaf89]

Could it be published as some kind of alpha version? I would really help me out.

[aitboudad]

@olaf89 not ready for production, but if you want to try it
just copy the FormlyJsonschema service and include it on your project.

[olaf89]

Thanks, i am testing it and it looks like it works well. I need to implement allOf, would you like me to submit pr with it when im done?

[aitboudad]

This is something else I thought we want to make sure we support. Right now, the implementation knows nothing of $ref ( local or external reference ) the spec right now states that if $ref is found all of the validation keys ( type, minlength, maximum etc) should be pulled from ref and ignored in the schema referencing it. Annotations like $comment , title, description etc don't have to be. Different forms validators handle it differently.

@kenisteward can you point me to the doc where was it mentioned?

[kenisteward]

@aitboudad

https://json-schema.org/latest/json-schema-core.html#rfc.section.8.3

Here's the main spec for $ref. Above it talks about how $id should work
with $ref

On Tue, Jul 9, 2019, 6:05 AM Abdellatif Ait boudad [e-mail]
wrote:

This is something else I thought we want to make sure we support. Right
now, the implementation knows nothing of $ref ( local or external reference
) the spec right now states that if $ref is found all of the validation
keys ( type, minlength, maximum etc) should be pulled from ref and ignored
in the schema referencing it. Annotations like $comment , title,
description etc don't have to be. Different forms validators handle it
differently.

@kenisteward https://github.com/kenisteward can you point me to the doc
where was it mentioned?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459?email_source=notifications&email_token=ADB4XNOC6EG5TKYA4BIFJ33P6RWIXA5CNFSM4G4KX3P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZP5RFI#issuecomment-509597845,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADB4XNMPEYIVRJ4MMTXBP6TP6RWIXANCNFSM4G4KX3PQ
.

[aitboudad]

if $ref is found all of the validation keys ( type, minlength, maximum etc) should be pulled from ref and ignored in the schema referencing it. Annotations like $comment , title, description etc don't have to be.

if title is defined with $refs, should we take account of it or ignore it, I couldn't find any information about it from the spec.

{
  $ref: "#/definitions/address",
  title: "billing address"
};

[kenisteward]

@aitboudad
It is up to use to choose. I preferably think using the topmost level annotation is best. That way it allows us to override titles if we are sharing schemas.

[olaf89]

From the spec

An object schema with a "$ref" property MUST be interpreted as a "$ref" reference. The value of the "$ref" property MUST be a URI Reference. Resolved against the current URI base, it identifies the URI of a schema to use. All other properties in a "$ref" object MUST be ignored.

Update:
I also found this discussion
https://github.com/json-schema-org/json-schema-spec/issues/672
Where in this PR it looks to be changed, to make this possible
https://github.com/json-schema-org/json-schema-spec/pull/628

And example of usage in next spec
http://json-schema.org/work-in-progress/WIP-jsonschema-core.html#rfc.section.10.1

[kenisteward]

I realize that but 1. That's changing in draft 8 and 2 that is not a great
experience to program under.

The annotations are actually meant to help for UI generation needs. It is
important for validators to overwrite the referenced validation terms but
not the annotations

On Tue, Jul 9, 2019, 12:41 PM Olaf Kasper [e-mail] wrote:

From the spec An object schema with a "$ref" property MUST be interpreted
as a "$ref" reference. The value of the "$ref" property MUST be a URI
Reference. Resolved against the current URI base, it identifies the URI of
a schema to use. All other properties in a "$ref" object MUST be
ignored.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459?email_source=notifications&email_token=ADB4XNIJSI4HRJVCJCBXASLP6TES5A5CNFSM4G4KX3P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZQ7WSI#issuecomment-509737801,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADB4XNKO4SCJSN6L36MFZFDP6TES5ANCNFSM4G4KX3PQ
.

[aitboudad]

seems clear now, added the annotations (title, description and default) support.
please check my PR #1658 and let me know if I'm not missing something.
Thanks!

[aitboudad]

Thanks, i am testing it and it looks like it works well. I need to implement allOf, would you like me to submit pr with it when im done?

@olaf89 PR welcomed :)

[kenisteward]

@aitboudad I want to try to add support for If Then Else this weekend.

http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.6

The idea is that the if schema decides whether you will validate with the then or else schema.

Valid to if = use then schema for a validation result (if present)
invalid to if = then else schema for validation result (if present)
otherwise we completely ignore the keywords.

I saw how you implemented dependencies and I wanted to follow along with that but I realized dependencies works because if it is defined then you will be using it no matter what

(e.g. we can eagerly add the config to validate on the deps added because they are setting up basically required relationships.)

in the case of if then else, we don't want to apply one or the other based on the data there.

Is there a way to conditionally use formly configs? I think that may more directly correlate to the If/thenelse/use case.

[aitboudad]

Is there a way to conditionally use formly configs?

hideExpression allow applying formly configs conditionally, https://formly.dev/examples/field-options/hide-fields

[kenisteward]

@aitboudad

I think I have an idea on how to properly do it but I'm not sure if I can find a way to set formstate from instead a field.

The idea would be something like this:

    if (schema.if) {
      const uniqueId = generateUniqueId();
      const ifConfig = this._toFieldConfig(<JSONSchema7> schema.if, options);
       // manipulate the ifConfig to be able to change formstate to have true or false when
       // the if config is valid or invalid.  This should not change the model

      // schema.then
      const thenConfig = this._toFieldConfig(<JSONSchema7> schema.then, options);
      thenConfig.hideExpression = (m, f) => f[`${f.key}-${uniqueId}-if`];

      // schema.else
      const elseConfig = this._toFieldConfig(<JSONSchema7> schema.else, options);
      elseConfig.hideExpression = (m, f) => !f[`${f.key}-${uniqueId}-if`];

      // add if/else/then configs to field
    }

I"m just not sure how to set the formState for that uniqueId if. Would the be a better way of doing this as well?

[aitboudad]

@kenisteward instead rely on formControl validity:

thenConfig.hideExpression = () => !ifConfig.formControl.valid;

[kenisteward]

@aitboudad okay I'll try that. I didn't think that was even possible for me to use!

[aitboudad]

v5.3 is released which includes the implemented json-schema features :tada:!

[aitboudad]

I'm working now on the following keywords (anyOf, oneOf and uniqueItems) which we be included in v5.5 the latest minor version of V5.
The rest of the specs will depend on the most requested ones but PR welcomed anyway!

After v5.5 release, we'll focus on the next major version v6 😍(better Doc, Api and more UIs).

[darrenmothersele]

A new version of the JSON Schema specification has been released:

https://json-schema.org/draft/2019-09/release-notes.html

[aitboudad]

here we go, the v5.5 is released with the following enhancements (you may check our demo example ):

• validators: uniqueItems and const.
• added alternative ways for custom labels to enum
• multiselect type
• partial support of anyOf/oneOf

@darrenmothersele thanks for the info, we'll try to bring the new updates in v6.

Happy coding 🎉🎉🎉!

[logvinoleg89]

@aitboudad @juristr
I’d like to use ngx-fornly to generate forms based on json-schemas. oneOf/anyOf constructions support is critical for me. I’ve considered the implementation of this functionality in [email protected] and found out that, in fact, only oneOf logic works correctly. To support anyOf, I’ve made certain changes, which allow to display the dropdown control with multiple selection. It allows to display form controls of several anyOf array items simultaneously.
I’d like to use an original ngx-formly instead of the fork on my project. I’d appreciate if you share your thoughts regarding the changes made by me (https://github.com/ngx-formly/ngx-formly/pull/1862). I’m open for a conversation regarding the changes.

[aitboudad]

Note:
in v5.5.3 we adopted @logvinoleg89 proposal, anyOf displays the dropdown control with multiple selections.

[kenisteward]

@aitboudad how hard would it be to manipulate this to instead validate based on the rules and not have to have the user select which ones they want.

I ask because the use case would be as a developer creating the form that fits the schema and as a user just filling out a form that fits it so the user doesn't have to think about which structure it is.

[aitboudad]

@kenisteward in my opinion, the json-schema implementation in formly may be considered as a rule rather than validation (which would fit 90% of the use cases) that why we didn't put a lot of effort in validation yet.

how hard would it be to manipulate this to instead validate based on the rules and not have to have the user select which ones they want.

that depends on the use-cases, but for more advanced scenarios mixing the formly JSON is required but we're trying to make it much easy as it can be.

[HIAB-vesteel]

I love to see the progress of json-schema in formley.
What do you guys think about remote refs?

Maybe you could let the user send in an async fn that the user are responsible for. It feel like it would this solution is advantageous instead of forcing a behaviour.

Is remote refs in the plan/making ?

[aitboudad]

Is remote refs in the plan/making ?

yep, in the plan :). It should be added through the options, something like:

options = {
  refResolver: url => this.httpClient.get(url),
}

[kenisteward]

As a heads up, I was trying to get this done but was having trouble
figuring out the proper way to implement $id with it.

On Mon, Nov 4, 2019, 7:28 AM Abdellatif Ait boudad [e-mail]
wrote:

Is remote refs in the plan/making ?

yep, in the plan :). It should be added through the options, something
like:

options = {
refResolver: url => this.httpClient.get(url),
}

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459?email_source=notifications&email_token=ADB4XNIWQEIIMKHMXEFCBQLQSAPRTA5CNFSM4G4KX3P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC7HMVQ#issuecomment-549353046,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADB4XNOLCX5WT6FG6ZYEBMDQSAPRTANCNFSM4G4KX3PQ
.

[kenisteward]

@kenisteward in my opinion, the json-schema implementation in formly may be considered as a rule rather than validation (which would fit 90% of the use cases) that why we didn't put a lot of effort in validation yet.

how hard would it be to manipulate this to instead validate based on the rules and not have to have the user select which ones they want.

that depends on the use-cases, but for more advanced scenarios mixing the formly JSON is required but we're trying to make it much easy as it can be.

I want to confirm that I meant the implementation of anyOf / allOf to where the user doesn't have to pre select want they want to pick (current implementation assumes the user wants to select a type to fill out) and instead the fields are all given in the formly config and if the anyOf / allOf matches everything is green and okay.

[HIAB-vesteel]

@kenisteward I looked at this a while ago and it's quite confusing. I think the base thought is that all schemas should be hosted in the same location but its optional and might be on disk as well.

As a heads up, I was trying to get this done but was having trouble figuring out the proper way to implement $id with it.

If i know this correctly the default behavior as JSON-schema is:

1. $id is the base URL for relative $ref (even though the base file have been loaded from disk)
2. if $ref is a absolute URL it should be used
3. { "$ref": "person.json" } would be ($id base URL)/person.json
4. { "$ref": "#person" } would just point to the definition in the same file looking for an entity with "$id" : "person"
5. #/definitions/person - Json Pointer
6. { "$ref": "person.json#gender" } would be ($id base)/person.json/#gender

This would be default behavior if the option is not set like @aitboudad mentioned.

options = {
  refResolver: url => this.httpClient.get(url),
}

[aitboudad]

I want to confirm that I meant the implementation of anyOf / allOf to where the user doesn't have to pre select want they want to pick

@kenisteward not too hard to implement, I'll provide you an example if necessary.

[scottux]

I have worked with angular and react json schema forms for awhile. I like this package, but I really need the UI Schema support. Is there already a plan together for that? I would like to help if I can.

My json schema is from a remote ref, but it is used for a lot more than form display and I can't really tweak it just for the form - so I need to be able to have a layout defined which extends the schema, so that I can better control arrangement of the widgets.

[aitboudad]

@scottux UI Schema support will be part of 6.x version but not anytime soon, I'd suggest wrapping formly-form component in a custom one where you can add such feature for your project with the help of map fn https://github.com/ngx-formly/ngx-formly/issues/1982#issuecomment-566048527

[scottux]

@aitboudad that may get me through a few hurdles, but I would prefer to work on making it correct versus hacking it. If you have some kind of skeleton of an idea, I can take that and what I know from being part of https://github.com/orgs/json-schema-form to make a working Pull Request for this package.

[aitboudad]

@scottux the proper implementation would take some time TBH, I've started working on some changes (didn't have the time yet make a PR) that will allow using json-schema without FormlyJsonschema service:

<formly-form [schema]="schema" ...></formly-form>

once done we can start on uiSchema.

[kenisteward]

@aitboudad any suggestions on how Format for strings should be implemented? extension? parser?

[aitboudad]

@kenisteward right now the best approach is to use ngx-mask as a custom field type

[kenisteward]

@aitboudad ahh. I wanted to add it to toFormlyConfig to have it be a solution for everyone instead of relying on my custom type.

[aitboudad]

@kenisteward once https://github.com/ngx-formly/ngx-formly/issues/180 resolved we can have a Formly solution :)

[classifieds-dev]

Would this issue be related to the error below?

zone-evergreen.js:171 Uncaught Error: [Formly Error] There is no type by the name of "object"

On the docs website object is being used. However, on my local when I use it I see that an error is thrown because object is not a valid type.

[aitboudad]

@classifieds-dev you may need to register json-schema types as shown in our demo example json-schema/app.module.ts

[classifieds-dev]

Ah… thanks. That looks like the missing piece.

[classifieds-dev]

It doesn't look there is a release of this module yet. So it looks like I need to create my own module for now and copy over whatever I need and register it in the root right?

[aitboudad]

@classifieds-dev yep, but the plan is to provide those types out of the box!

[beeman]

@classifieds-dev yep, but the plan is to provide those types out of the box!

This sounds awesome, I'm happy to take a shot at implementing that.

Does that mean we need to implement those json-schema related types for each of the UI libs we support?

[aitboudad]

@beeman Well we can start with the basic types already my main idea is to use the existing UI.

Example:

FormlyModule.forChild({
  types: [
    { name: 'checkbox', component: FormlyFieldCheckbox },
+   { name: 'boolean', extends: 'checkbox' },
  ],
}),

Note: use master branch.

[beeman]

@aitboudad that looks great!

I've started with the checkbox in this PR: https://github.com/ngx-formly/ngx-formly/pull/2232

I'd love to get some feedback. If this is the way to go, I'll create a similar commit for each of the basic types.

[classifieds-dev]

I think this is an amazing project. However, I've spent to much time working my way around bugs to have it be a feasible production solution. Either I find myself digging around your code or sides stepping issues. I love the idea but I found it much easier to just build reactive forms. I spent a week with this framework. I found my way around problem only to find another. I really tried. I really thought I could use this.

[classifieds-dev]

This project is kind of pathetic. I mean… you are still talking about how to support json after over a year. I mean; what is happening. You have this nice looking website but don't support the most basic of functionality. After a year. I can build a reactive form in angular quicker than it takes you.

[aitboudad]

@classifieds-dev Well, that's up to you :), the essential json-schema features are supported so the remaining parts are not blocking at all, keep in mind that's a free product so the timeline may not be respected at all.

[ceelian]

What version of JSONSchema is this PR addressing and what schema versions are currently supported in V5?

[aitboudad]

@ceelian JSONSchema7

[indiealexh]

Looking to use json schema format to use a date picker.

Anything I can do to help progress efforts toward the ability to use Date-picker from a json schema
type: string
formate: date-time
?

[Jelledb]

So from the example that I found in the docs (https://stackblitz.com/angular/qkjrkdnqymvb?file=src%2Fapp%2Fobject.type.ts) I get the feeling that there is still a lot of setup and stuff to be done before being able to use formly 'out of the box' with JSON schema. Is it planned to include all these setup components etc in the core library so we don't have to do this ourselves?

For now it's just sad to see that there is so much setup code required.

[kenisteward]

What exactly do you mean by setup code?

It doesn't seem to need any more than a regular setup for firmly would need.

On Mon, Oct 5, 2020, 10:44 AM Jelle den Burger [e-mail]
wrote:

So from the example that I found in the docs (
https://stackblitz.com/angular/qkjrkdnqymvb?file=src%2Fapp%2Fobject.type.ts)
I get the feeling that there is still a lot of setup and stuff to be done
before being able to use formly 'out of the box' with JSON schema. Is it
planned to include all these setup components etc in the core library so we
don't have to do this ourselves?

For now it's just sad to see that there is so much setup code required.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459#issuecomment-703716729,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADB4XNM7LZIQD6XS6NORIGTSJHSWJANCNFSM4G4KX3PQ
.

[GertjanJ]

Hi, first of all, thank you for this awesome package! Not to sound rude but is there any eta on the resolving remote json-schema refs feature? I'll be waiting patiently :)

[kenisteward]

Hi, first of all, thank you for this awesome package! Not to sound rude but is there any eta on the resolving remote json-schema refs feature? I'll be waiting patiently :)

@GertjanJ I had come up with a quick and dirty localized solution that I didn't want to share here yet. Now that' we are officially in production I'll see about adding it.

@aitboudad I may need some guidance on how you want to make use of async/await for remote references. If we leave it in the service it's fine because we can just convert that one function (from the json schema service) but if we move processing to the component it makes for uglier solutions.

[aitboudad]

@kenisteward just go with the service solution