Instructor: If you take a look at the Formly configuration here, you can see that it's actually pretty simple. We have some kind of key value pairs here. There's some massive objects like for template options, with the exception here of onInit hooks, which are more code-like.
What I want to arrive at is that it's actually possible to deliver this whole configuration directly from the server. This is a very specific case, but it might be useful in those cases where the user can somehow configure which fields should appear on a UI.
Let's see how to do that with Formly. First of all, let's go here in the assets folder. Let's create here a new file, which we call dynamic-form.json. This will be a file that contains the actual response that usually then the server API would expose. For the purpose of this demo here, we're just creating a static JSON file.
The interesting part here is that we can actually go and copy over our whole configuration that we have inside here. Let's remove here the key because we don't need it right now. Then let me go ahead and copy the entire Formly configuration over to our dynamic form.
The only thing we have to remove here are a couple of things. We have to remove here the hooks because that's something we actually cannot provide in JSON because we have some function expressions inside here and JSON doesn't support that. I'll remove this one now.
Also, what you see here is that we have some other function expressions here that disable property as well as hide expression. Interestingly, these can directly be written also as string expressions, which is perfectly supported by Formly. We can just transform them.
Let's save here. Let's verify whether we have some other expressions here that don't match the JSON structure. For instance, this here.
We cannot, of course, provide a data source because that won't be available, but given that we will deliver the values directly from the server, we will actually already prepopulate also the values of those option fields, because it doesn't make any sense to do another call to the server forgetting the data.
Probably, we would have here something like value NULL, label for deselecting the nation, and then let's just add one nation as an example, Italy. Obviously, you would have your multiple nations inside here. Also need to remove here the comments because comments are not supported.
Let's check whether we have some autocomments inside here. Let's remove all the inaudible dates because it contains some function expressions.
Now we should be good to go. You can see that Prettier automatically transformed the single quotes into double quotes so we have a valid JSON structure.
In order to use that inside our components, let's first of all remove here that Formly config. Now, we can go and dynamically fetch that JSON file. Of course, I need here the HTTP service. Let me just quickly import that from HTTP common, and then in the OnInit, for instance, I can go and say this.http.get.
We will call here our assets/dynamic-form.json file. What we expect here is to be returned at Formly field config array. So we can already give that here, and then we can just subscribe for now here, and we will get here the fields.
Once we have the fields, we can actually associate them here to our fields, which is our local variable, which will then be taken over by Formly. Now, you can already see that we have already our form in place that is now dynamically constructed from that string that comes from the server.
So obviously, we are a bit limited in what we can express in a valid JSON, like function inaudible cannot be expressed, really. But still, for instance, validations like your inaudible validation perfectly works. For instance, if I add here 16, you can see that the validator called for triggers, and the validation messages which we have registered on Formly will appear.
Also, if we scroll down to the Cities here, you can see here we have a couple of expression properties here as well as a hide expression, and that also works. For instance, if I, here, de-select nation, you can see that this city field disappears, so we can even implement some dynamic behavior based on other fields.
What we have removed, however, is, for instance, on that city ID here, the OnInit hook which automatically inaudible listen to changes on a nation, and based on that nation, filters basically the cities here. Now, this is something we will have to implement ourselves in some post-processing step, for instance.
What you could do is, when you get here, the fields, you could actually go and search for the cities. Then on the service site, for instance, on that city here on the template options, you could add some property, for instance, something like DependentField. And let's see, here, write nationID.
So based on that, you put that in a post-processing tab which you perform here, attach it on OnInit hook, and then register on the valid changes of that dependent field that is specified here in that template options.
There are a lot of possibilities which allow you to extend that further more, but there is really something specific to your use case.