A case for extending Angular Forms - part 2

Intro

In my previous article I wrote about reasons for extending Angular Forms functionality. In this article I wanted to write about adding visibility functionality BUT I realized I need to discuss possible approaches first so here we are :)

Approaches

With Typescript, we have 2 options for extending Ng Forms:

1. Using object oriented approach
2. Using JS approach

Object Oriented approach

The OO approach does not differ from Java or C# OO so basically to use this method we create out own classes:

• DcFormControl extends FormControl
• DcFormArray extends FormArray
• DcFormGroup extends FormGroup

And add the functionality there. Now, the thing with this approach is that we actually cannot have our own DcAbstractControl which we will extend and that's because FormControl, FormArray and FormGroup are concrete classes with their own functionality which we will need and we cannot extend two or more classes or abstract classes which means we would have to repeat the functionality in each of our concrete classes.

But we also need to have some common interface which will enable us to use any of our form classes without explicitly stating which one is it so the definition bacomes:

DcFormControl extend FormControl implements DcAbstractForm

After that we would need to override the get() method from the FormGroup to return our DcAbstractForm interface so we could use our new functionality.

There are probably some things I might have forgotten about but this is a quick rundown of things that need to be done in order for this approach to work.

Despite all this hassle and code repetition it gives us one HUUUUGE advantage: we have separated our functionality from Angular functionality which means we can use both DcFormGroup and FormGroup in one project. What's more, we don't need to worry too much (we have to worry some) about Angular upgrade breaking our application since we have our own classes. If you are one+ year in a project and suddenly decide that you need new functionality, then this approach might be good for you.

JS approach

This approach is much easier to implement but (depending on what are you adding) it's also an approach which I think should be incorporated early in the project.

With this approach we use the prototype to extend a library, in this case, the AbstractControl. With Typescript we cannot simply write AbstractControl.prototype... because it will throw an error, but we will use module augmentation.

Basically, we change the definition of the class, which gives us some neat benefits:

• we do not need to repeat the code
• we do not need extra classes
• typescript code check will pick up new functionality automatically
• our changes will be applied to an existing code automatically (if it is not a breaking change, mind you)

The biggest problem which you might encounter is that it affects the library itself so every time you upgrade the library you have to check if nothing is broken.

Summary

Although Object Oriented is the approach I used so far, we will not use it in following articles, simply because doing the same thing over and over is boring :)

See you in the next article where we finally do some coding.