Typescript: A guide for faster onboarding process

With growing modules, components, and features, it becomes difficult to maintain consistency across our front-end codebase. Unexpected errors appear frequently, and it hinders our engineers' productivity in general. Moreover, with more engineers involved in our front-end codebase, it becomes a constant challenge to onboard them as seamlessly as possible.

One of our technical strategy principles is simplicity + velocity and to that end, we are not afraid to rip out old code, framework, or patterns or introduce new ones. In this blog post, we write about how we carry out one of our largest migrations, from Javascript to Typescript, and the rationale behind it.

Why did we migrate?

With Typescript, we aim to achieve three things within our team.

• Facilitate better teamwork
• Increase development velocity
• Improve project maintainability

Coming from Javascript codebase, Typescript was chosen because of its backward compatibility and it can be easily integrated into our codebase.

Better facilitate teamwork

Previously with Javascript we had a hard time enforcing developers to use shared functions or libraries, and oftentimes changes in shared functions or libraries cause unintended errors. Moreover, there was no contract between shared models in Javascript which added complexities and difficulties when implementing new components or functions. Typescript eliminates those issues by offering a more concise and consistent way with type in a function or an object.

Take a look at the following code snippet:

Without typescript it will be hard to communicate what was the expectation of certain parameters or objects. It will lead to confusion and affect productivity in general. Typescript facilitates engineers to communicate more clearly and code consistently. In the end, the productivity of our engineers will increase while maintaining good teamwork within the team.

Increase development velocity

Debugging and error tracing have always been a problem when using Javascript. It is difficult to catch an error, and sometimes the problem itself could be prevented if there was a checking process before we compiled the code. Typescript provided type checking in compilation to prevent those small errors which usually slipped from engineers attention in the implementation process.

Although there are still other errors which cannot be caught by the type checking process, in general it saves a lot of time and moreover with consistent standards throughout the codebase it also improves the development velocity in general. Engineers do not have to guess or be afraid when using shared components or libraries. It also encourages engineers to create shared components or libraries which reduce redundancies in the codebase.

Improve project maintainability

Maintaining a legacy codebase possesses a special challenge for engineers. Even the smallest change in the code could potentially break the whole pages or applications. We have to make sure that even the smallest change would not break the function.

Previously with Javascript it was difficult if we change or modify shared functions or libraries as we need to check every caller of the function is safe. Oftentimes, the errors are caught during the runtime and reported by users. It decreases our user experience and potentially could affect the business part of the company. Typescript will immediately catch those kinds of errors, thus a safer refactoring process in our codebase.

Use case:

If we change the function in the first code snippet with the above code, there will be a compilation error and the related functions can be safely refactored too.

How we migrate

The migration itself was pretty straightforward since the guidelines were provided in the typescript official documentation. Our strategy to migrate the codebase started by migrating the smaller parts of our codebase such as hooks, UI components, and utilities. Furthermore, we enforced strict measures by requiring new development of the new feature to be written in typescript. We also applied strategies such as refactoring of the older files which were done gradually to make sure it didn’t hinder our development pace.

Conclusion

As you can see, Typescript offers a direct way to communicate since we as an engineer know exactly what to expect if we call a particular function and know what kind of parameter should be passed to the function. On our scale it means a lot to have such features, engineers can focus more on their development process instead of worrying about errors. It also helps us with the refactoring process, since we can easily determine what kind of behavior we want from our function.

In the end, migrating from Javascript to Typescript is purely because of our need for a more scalable solution with our growing code base and engineers which translates into facilitating teamwork, increasing the development velocity, and improving our project maintainability.

​​Nowadays, we have migrated close to 90% of our frontend codebase to typescript. This migration is one of the largest refactors in the history of our codebase, and it will not be the last. We view the long-term health of our codebase as a collective responsibility of our engineering team and software engineers at OY! are empowered and supported to pursue projects like this.