SAPUI5 and TypeScript: A good match?

Isn’t it awful when you write a new piece of code in JavaScript and refresh your application just to find out that you mistyped a property name, or a function name? Imagine if there was a way we could calculate all the time we wasted. Well, there isn’t, but there might be a way of avoiding these types of silly errors, and perhaps even more complex ones.

In this blog post I am going to talk about the experiences we had coding a project using TypeScript along with SAPUI5 framework.

A brief introduction of TypeScript

TypeScript is an open-source programming language maintained by Microsoft that compiles into JavaScript. It is a typed superset of JavaScript, which means that any valid JavaScript is also valid TypeScript. Its main feature is static typing, which allow features such as static checking and code refactoring when developing JavaScript applications.

As we’ve got to know TypeScript and its features, we wondered if we could apply it to a project and improve productivity, code readability and quality. We decided to give it a try, and faced several challenges.

Perceived benefits

Some of the examples below come from the seamless integration between Visual Studio Code and the TypeScript language. As both of them are maintained by Microsoft, VS Code is one of the best IDEs to go for when developing with TypeScript, even though there are plug-ins for other ones, such as Sublime or VIM.

Please open images in new tab to better visualize them.

Auto-complete

• We get auto-complete and “on the fly” documentation for SAPUI5 types and our own defined types.

Find references

• We can find all the references of something in the project.

Clean code

• We dropped Hungarian notation, since types are explicitly defined, allowing us to choose better names for our variables

JavaScript code vs TypeScript code

• TypeScript’s module system is cleaner than SAPUI5’s.

JavaScript code vs TypeScript code

• We could use all of JavaScript’s newest features, which can improve code readability. Such as:
  • Template literals

TypeScript code vs JavaScript code

• • Async, await for asynchronous code

TypeScript code vs JavaScript code

• You get instant feedback while you type your code, like what happens with other typed languages such as ABAP or Java.

• When you hover code, you get additional useful information about the artifact

OData entities to TypeScript definitions

We’ve also written a script to parse the metadata.xml from our OData services and generate TypeScript type definitions for the OData entities. This way we get auto-complete and validations even for operations on OData entities.

Difficulties

SAPUI5 Module System

There are several implementations of the module concept in JavaScript environments, such as Node.js (CommonJS), require.js (AMD), UMD or ECMAScript 2015 native modules. TypeScript currently offers support for several module systems.

SAPUI5 implements its own module system, which is only used in SAPUI5 itself. This means we could not run the generated JavaScript code out of the box with SAPUI5. Leonardo Carreiro’s (https://github.com/lmcarreiro/) solution was to generate the code with AMD modules and use a script to “bridge” AMD modules into UI5 modules. The code can be seen here. However, this was not a valid solution for us, because most of the time we cannot control the environment in which our SAPUI5 applications run, and it seems more like a workaround than a definite solution. Thus, we made the decision of forking the TypeScript compiler and add support for the “ui5” module system. This way, our generated code runs out of the box with SAPUI5.

Type definitions

Another challenge we faced was getting access to correct SAPUI5 type definitions. JavaScript libraries interfaces can be defined as type definitions in TypeScript. For example, if I have correct type definitions for SAPUI5, the TypeScript compiler will know that if I call “sap.ui.getCore().getModel()” in my code, it should return an object of type “sap.ui.model.Model”. In pure JavaScript, with that line of code, we make several assumptions:

• We assume sap.ui exists.
• We assume sap.ui.getCore() returns an object of type “sap.ui.core.Core”
• We assume “sap.ui.core.Core has a function called “getModel” which can be called without parameters and returns an object of type “sap.ui.model.Model

Type definitions are a way to formally define these assumptions so TypeScript can also work with them and help you catch errors. This way, the compiler can perform static checks instantly to see if my code makes sense.

There were no up-to-date TypeScript definitions for SAPUI5. What we did was use the ui5ts project to generate them. It parses the SAPUI5 designtime documentation and generates the equivalent definition files. The generator worked for most of the classes, and we manually corrected the places it didn’t.

I like, I wish

Although the experience with the tool was good, we’ve also ran into some issues on the process. As mentioned before, because SAPUI5 don’t use any of the module types that TypeScript supports, we’ve had to fork the compiler. This took a lot of work, and we still need to manually merge the upstream changes of the original TypeScript every time because of that. It would be nice if SAPUI5 started supporting one of the standard module loaders commonly used.

Also, we’ve also had work generating and manually writing correct type definitions for SAPUI5. It would be nice if this was provided by SAPUI5 team.

Wrap-up

Overall, by using TypeScript, we could write cleaner code, define our interfaces better to detect errors early and develop faster, due to the productivity boost provided by the seamless integration between Microsoft’s TypeScript and the Visual Studio Code editor.

We are having a nice experience with TypeScript and will use it again in future endeavors.