Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
TLDR: We can use TypeScript types in every line of our code, but that doesn't mean that we have to use them in every line.  You can configure the TypeScript compiler as well as clearing its cache, if you need to. Let the IDE handle those imports.

If you need a recap on why we use TypeScript and how we use it check out Part 1 and Part 2 of this series.


In this final post of the series I will share some tips on how to use TypeScript in your SAP-ecosystem development.  I'm a recent convert (or 'reformed character' if you prefer) rather than a TypeScript expert, but I hope this perspective will be useful for others.

Use the import prompt

We use import statements to reference the types provided by the various frameworks that I discussed in the previous post. This is particularly important in UI5 development where we need to need to use the types that correspond to the UI controls on our views. The good news is that our IDE can add the import statements for us.

In this example, from SAP Business Application Studio,  we can click on the Quick Fix prompt.....

...and then choose from the list of matching types

The import statement will be added for us.  In this case there is ambiguity (which 'Button' class are we referencing?) but if the module name is unique the import will be added automatically.

Watch your case

In TypeScript, as in JavaScript, primitives are written all lower case: e.g. string, number, boolean.  Object types have title case: e.g. Date. With string in particular you need to be careful to use the correct case.  As we are usually referring the primitive type we should almost always be using string rather than String in our types.

Less is more

Once I was up and running with TypeScript I loved using types and declared an explicit type everywhere I could.  The downside to this is that the code becomes a little 'busy'.

TypeScript is smart enough to distinguish between situations in which an explicit type is needed and when there is no ambiguity and the type can be inferred, so in my opinion it's best to leave out the explicit types unless they add value. Consider the following example. The calculateAgeAtDeath function accepts a Sheriff object as a parameter and returns the age of the that sheriff (a number).  The return type of the function is explicitly declared as is the type of the variable we assigned to it.

Both of these declarations are redundant and can be removed.  The return type of the function will always be number, because are returning the difference between two numbers.  If so, the variable to which we assign that return value will also be a number.  We can dispense with the types altogether.

Clearing the cache

Very occasionally your IDE may report spurious errors.  This can be resolved by clearing the cache of the TypeScript compiler.  In Business Application Studio (or Visual Studio Code) this can be done with the Restart TS Server command.

Use the menu path View->Command Palette then type to filter the commands until Restart TS Server appears. NB You must have a .ts file open in the editor when you launch the Command Palette, otherwise this command won't appear.

Taking a break from types

Of course when using TypeScript we want to declare types wherever they resolve ambiguity and add value (see above).  There may occasionally be times however when you feel that including types is too difficult or impedes your 'flow' too much.

One simple approach in this scenario is to use the generic any type.  This is a way to acknowledge that a type is appropriate but still leave the exact type to be inferred at run-time.
let something: any = …

If you're doing this then your code may have a .ts suffix but it isn't really superior to the plain JavaScript we are replacing! For this reason you are risking a knock at the door from the TypeScript Sheriff

The TypeScript Sheriff

There are also annotations which give the TypeScript compiler instructions. With these you can use proper types for the vast majority of your code, but allow for the odd exception case.
@ts-ignore        //no checks for the next line
@ts-nocheck //no checks for the whole file
@ts-expect-error //expecting an error, only highlight if there isn't one

Confgure the TypeScript Compiler

The tsconfig.json file sits in the root of your project. It contains various options for the TypeScript compiler, controlling for example the destination folder and language version (e.g. es6) for the .js files generated.

Don't be a cowboy coder....

Don't be a 'cowboy coder', use TypeScript to stay on the right side of the law and hopefully these tips will assist you on your journey to more reliable and readable code

Labels in this area