override and noImplicitOverride for TypeScript class inheritance

typescript was released in october 2012 and in december 2014 we got the feature request for virtual plus override now virtual is a bit confusing specifically in the javascript programming language it's more of a c plus thing so we got the feature request for just the override keyword in february 2015 and now six years later in 2021 in touchscreen 4.3 it's finally landed so let's have a look now to demonstrate the motivation for the override keyword let's look at a simple example here we have a base class called visibility that has a member called visible and two methods to change this visible value now within our test code we have a mock version of this visibility class that simply replaces the show and the hide methods to lock to the console instead of doing anything significant and of course we have some usages of the base class within our application code and some usages of the mock class within our test code now this is all fine and handy but it's not particularly safe in terms of the code evolution now someone might come in the future and modify the visibility class within our application code to have a single method that takes a boolean value now if they make this modification they will get errors from the typestrip compiler about all usages of this particular class within the application code so they can jump into the application code and make the necessary modifications over there as well however they will not be notified that these methods were actually being overridden in our mock implementation and now our mocks as well as our test code are out of sync with the real application this is where the override keyword comes in handy during inheritance if your intention is to override a base class feature you can mark that member as override since the class mock visibility intended to override the members show and height of the base class we can mark them as override and now if these members actually don't exist on the base class we get a nice compile time error this error points us in the right direction forcing us to overwrite the actual member that exists on the visibility class which in our case is set visible so we replace what's already there with this particular method take in a boolean property and update the method body accordingly and of course get rid of the extra method and now we get nice errors in our test code as well and we can update it to match the refactorings that happened in our application code and that's it for the override keyword now if by chance you forget to specify that you are actually overriding a base class feature you will not get any compile time errors and now if someone refactors the base class you will no longer be notified about modifications that you need to make in your child implementation so by default you have to remember to specify the override modifier fortunately there is a typescript compiler option that forces you to use the override keyword when you are replacing some base class functionality we jump into our ts config and add the option no implicit override and set it to true this option forces you to use the override modifier whenever there is some base class functionality that you are replacing and now with this option set to true since we are replacing the functionality of set visible from our base class we get a nice compile-time error from typescript this forces us to use the override keyword so we follow the guidance provided to us by the error message and add the override modifier and the error goes away and now with this modifier in place if someone were to modify the members of the base class we would get a nice error in our child implementation as we saw before now in addition to enforcing you to label all your intentional overrides this option no implicit override also catches any implicit overrides that might be non-intentional within your code base let's switch this option off and look at another example here we have a base disposable class with a simple method called dispose that sets the is disposed property to true this class also has utility method called log which it uses to log to the console now it's quite easy to imagine that we create a class called file which is intended to log stuff to some particular file and we have this method called log that will write to the file now we have actually unintentionally replaced the log method from the disposable base class so if someone creates a file and calls dispose the dispose method will actually end up logging to the file now that is an example of an unintentional override so if we jump to our ds config file and set no implicit override to true now any unintentional overrides will also get marked as a compile-time error and now we can choose if this override was actually intentional by adding the override modifier but in our case it is not intentional so we can refactor this method to something else for example write so there are two key takeaways here first always set no implicit override to true and second this will force you to use the override keyword when you want to replace some base class functionality as always thanks for watching and smash that like and subscribe for more content like this and i will see you in the next one you

Channel: basarat

Views: 4,800

Keywords: typescript, javascript, basarat, that typescript guy, typescript deep dive, react, node, npm, angular

Id: arjrOdT73b4

Length: 5min 12sec (312 seconds)

Published: Sun Apr 25 2021