TypeScript into a SAPUI5 codebase

SAPUI5 predates the assumption that a frontend codebase is typed. Its module system, its class definitions, and its XML views were all designed for a world where the editor could not help you. Types can be added, but not evenly — some parts of the framework reward them immediately, and some resist.

Where it pays immediately

Model access is the clearest win. A line like this is where most of the runtime bugs live:

const rate = model.getProperty("/header/exchangeRate");

Everything about it is a guess: whether the path exists, whether it is a number, whether it can be null after a failed load. Typing the model shape moves all three guesses into the editor.

Formatters and OData calls follow. Both are boundaries — data crosses them and changes shape — and boundaries are exactly where a type is worth the keystrokes.

Where it turns into ceremony

Controller lifecycle methods gain almost nothing. onInit takes no arguments and returns nothing; typing it is filling in a form.

XML views are the real limit. A view binds to a controller method by string name, and no compiler checks that string. You can type the controller perfectly and still ship a view that calls a method deleted three commits ago. Types give a strong impression of safety across a gap they never cross.

What I would tell myself at the start

Type the data, not the framework. Model shapes, service responses, formatter inputs and outputs — those catch real defects.

Resist typing the parts that exist only to satisfy the framework. Every any you eliminate there costs a maintenance burden and returns nothing, and it makes the diff long enough that reviewers skim it.

The goal was never full coverage. It was knowing what shape the data is when it reaches the screen.