Enhancing React DX with TypeScript

The feedback loop — taking your output as input — is at the core of the developer experience of not only the products of the DLS, but the way we work on them ourselves, too. While it’s important to us that the loop be shortened for you, the team using our products, it’s also key to our process that our own feedback loop is short, reliable, and informative, so that we can see how you are using them, and what friction you are encountering.

Whilst directly delivering to our Cardmembers is rewarding, we’re lucky at the DLS to serve other colleagues, and to have the opportunity that the working-in-the-open culture of Amex gives us to watch as our products are used across the business. Alongside automated analytics, we also read our code in your own projects, testing out how our tools feel on your own workbenches and identifying how we can serve web engineering better.

It was during one of these investigations that I stumbled across something that caught my eye – a JSX type error in a usage of an external library. Whilst this isn’t our component, what intrigued me was that we were receiving this linting assistance in a JavaScript file. TypeScript is a powerful devtool – how can we leverage its linting capabilities to help prevent bugs in our consumers’ code, directly in the IDE? How can we shorten the feedback loop to be as short as as-you-type?

My type on paper

Most web IDEs (WebStorm and VS Code) use the TypeScript engine under the hood to power a chunk of their intelligent code completion. This is much richer than the in-line documentation that prop types can provide and brings information from our online docs right into your editor.

For example, many of our components have the concept of variations in UI and behaviour controlled by a toggle prop – such as a currency input returning an invalid value. At the IDE level, we are now able to enforce a check of the params.invalid flag before accessing the normalised value.

But let’s go further. A lot of teams across the company are completing their accessibility remediation. On top of existing accessibility linters, how can we hint developers towards the most accessible implementation of a component? Here, a label is able to note that it has not been associated with its corresponding input.

Some of the above are extracts of real examples found in our testing.

In addition to the benefits for our JavaScript consumers, this now enables hinting for all TypeScript projects across American Express, which previously had to disabled it due to our incompatibility.

Future

In the latest version of DLS React, type definition-powered autocomplete is enabled for all our components. Upgrade to try it out — we look forward to hearing your feedback!

We see TypeScript as a powerful devtool that projects across the company can take as much advantage of as they choose – whether it’s just the ‘default’ benefits provided by their IDE from third party packages, or as far as typing their entire app.