A typical Formly form configuration can get quite large and often also hard to read. Thus, I highly recommend to extract common steps in helper functions. This not only helps with the readability but also helps factor out common steps and repetitive code. In this lesson we're going to refactor a Formly form config with some re-usable helper functions.
Juri Strumpflohner: [0:00] When we're writing such a Formly form, it can get quite huge, especially if you have a larger form, because there's a lot of details to write out. There's a lot of configurations and indentation that might also get a bit hard to read.
[0:13] Now, in some of our previous videos we have already started to factor out some of the configuration in so-called "reusable utility functions." For instance, here we have a so-called "Formly Row," where we pass in a Formly configuration and we create the internal path that Formly requires.
[0:28] For instance, the definition of a class that we applied to each row in order to have a multicolumn layout. Similarly, you can do that for the other form configurations as well. For instance, you could create a reusable function for all the input fields.
[0:43] We create here some Formly input. Wait, for now, here let's leave that empty. This is termed a "Formly Field config." It's exactly what we're returning here. Now, as a first off, you could see here we have various fields that are for sure, variable.
[0:58] For instance, property binding would, of course, be a variable. First of all, let's fix here our arrow function. We have a different kind of type. We have here the config that we passed in, and this will be a custom config type.
[1:12] We will have definitely a key property to provide, and this is a string. We will also provide a label, which is also a string, and then we might provide template options, which can be exactly to override the different kind of template options in our Formly config.
[1:28] Now, we can start customizing that. For instance, the key is here is the one we have in the config, so config.key. We definitely want to override here our label, so we have here the label property, which will be the config.label. Then we want to de-structure here the config.templateOptions that might have been provided from the outside.
[1:52] With that, we can go and for instance, refactor out here our first name property. We could see or simply say formlyInput. We have to key firstname, which remains the same. We could give it a label, which is Firstname.
[2:10] For the template options below here, we could actually specify them here and move them up. We don't need to specify the label anymore. You can see how we start to reduce basically the amount of configuration we have to write.
[2:26] Now this is just an example I'm writing out of my head right now, but this can be very customized to your own application. For instance, you could even create a whole configuration just for nations because they'll represent always the same in your application.
[2:40] What you could do here is to actually create a hyperfunction, nation input, which gets you a configuration. You just return basically the entire configuration of a nation. You can go down here. Instead of the nation specified like that, because you might have that in multiple places as well, you can just say Formly nation input. It's going to reflect when we broke here our form. Let's have look.
[3:08] Of course, we need the data service to be passed in because our function doesn't know about a data service. Here, we could either decide to pass into data service or directly based as a result of that data service.
[3:19] In this case, let's say we pass in this one. This is an observable of, let's say, any for now. We reference these here as a data property. Now we obviously have to pass them in down here.
[3:37] The goal here is to show you how you can reduce the Formly configuration because that might look always the same within your application. Also, in this case, for instance, the Formly nation embed is easily reusable across multiple forms inside your app.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!