What is good (and bad) Typescript: experience of UI-developers
Hello, my name is Alexander Chernikov. I lead the development of the UI project “Digital Corporate Bank” - an updated version of Sberbank Business Online, an online bank for legal entities. We are developing a stand-alone client, a mobile application and, in fact, a web client, which will be discussed. In my articles I will share the valuable experience of our team, and specifically in this post I will describe our technological stack and focus on why we chose Typescript as the main language.
The new version of Sberbank Business Online, we write 2.5 years. Next year we are planning to transfer all Sberbank corporate clients to it.
')
So let's start with the stack. We implemented TypeScript, React, Reflux (legacy), Redux, Bluebird Promise and Bootstrap. We write styles on LESS. All this stuff we collect with the help of Babel, Webpack and its plugins. Webpack is still the first version, but we are going to move to the second. Many may ask: why do we need Typescript and Babel at the same time? Firstly, earlier TypeScript was not able to translate everything, and only recently caught up with Babel in this functionality. Secondly, TypeScript does not know how to cache. And babel can store ready-made ES5 scripts in a folder. If the source code has not changed, it immediately takes them from there. When the project is going to take a few minutes, this time saving is very good.
The technology stack is pretty fresh. The guys have to delve into several things at once: for example, in TS, React, Redux, in the project itself and in the terms of our bank. Of the 50-60 people, only 20 percent work in the state, the rest are connected by vendors and often change.
How do we cope with code-review in such conditions? Previously, several of the most experienced developers looked at the code of all the teams, there was such a small pyramid. Now we are trying to evenly distribute the teams. So-called experts have appeared in many teams (they are well-versed in the project, they know what lies where and where), so as not to reinvent the wheel and so on. Accordingly, they review not only the guys from their team, but also from others.
The review is a bit automated and on the pull-request we add labels that need to correspond. Then they will turn green and the OL will automatically merge. There are different labels: Code-style, Expert, Architect, CSS, E2E-test and others. If changing .less files - CSS is added, if any code of a kernel or low-level things changes - Architect is added. To get Expert, you need to recruit at least 2 appruva experts.
And if a person is new to the project or is not very strong in JS, then his code will be very different from what it was before the code-review.
I caught that moment when many wrote on TS and used new features that are transpiled in ES5. But even then, we used TS for typing, for some static code analysis for errors. Yes, you can write the code correctly and correctly in JS, but it will not support you as TS. Someone puts in the minuses that you have to write a lot of TS-code (overhead), i.e. typing, types, interfaces, etc. When we refactored the “old” JS> TS code, elementary errors were detected that would only work at runtime. That comma is not there, then the point is forgotten, then the brackets were closed early, etc., not to mention the inaccessible code and unused arguments, etc. ... When the system is large and the team cannot cover the entire system with tests, TS saves. With 3000-4000 scripts in general it is difficult to imagine how to live without TS.
Of course, when we write code in JavaScript, we can help the compiler and write code, as if we have a typed language: do not override variables, do not write different types to them, always return the same type. The question arises: if babel.js is used in this case, is there then a point in learning TypeScript?
We often argue about this. Some colleagues say: “Why do we need TS? We write the code correctly and conduct thorough code-review, select people at the interview, and indeed the Jedi JS ”. But no one has canceled human factors: laziness, haste, inattention. Nothing prevents to connect TS to your JS-code. If you really do not have a single error, the compiler will not find anything - you can be glad that you have a great team, and the stars have formed as it should. But to be safe from using TS still does not interfere. Moreover, it does not require any special expenses.
In addition, this year in version 1.8 TS made a convenient feature. Now you can check the types in pure JS - just add the “.js” files to the project and allowJs flag. If there is any code that you do not want to check, then you can safely ignore it through the @ ts-nocheck annotation. During code-review, minor bugs are almost impossible to catch, and TS helps save time and effort. Otherwise, you can add a release branch to develop with conflicts in 100 files ... I would like to see how a person coolly presses the MERGE button.
“What about Flow?” You ask. We chose between ES6 and Typescript, nobody knew about Flow then. For those who are interested in what the difference is in their static code analysis, I can advise an interesting report by Ilya Klimov from the HolyJS 2017 Piter conference, where he compares TypeScript and Flow.
In addition to overhead, Typescript has several other drawbacks:
The new version of Sberbank Business Online, we write 2.5 years. Next year we are planning to transfer all Sberbank corporate clients to it.
')
So let's start with the stack. We implemented TypeScript, React, Reflux (legacy), Redux, Bluebird Promise and Bootstrap. We write styles on LESS. All this stuff we collect with the help of Babel, Webpack and its plugins. Webpack is still the first version, but we are going to move to the second. Many may ask: why do we need Typescript and Babel at the same time? Firstly, earlier TypeScript was not able to translate everything, and only recently caught up with Babel in this functionality. Secondly, TypeScript does not know how to cache. And babel can store ready-made ES5 scripts in a folder. If the source code has not changed, it immediately takes them from there. When the project is going to take a few minutes, this time saving is very good.
The technology stack is pretty fresh. The guys have to delve into several things at once: for example, in TS, React, Redux, in the project itself and in the terms of our bank. Of the 50-60 people, only 20 percent work in the state, the rest are connected by vendors and often change.
How do we cope with code-review in such conditions? Previously, several of the most experienced developers looked at the code of all the teams, there was such a small pyramid. Now we are trying to evenly distribute the teams. So-called experts have appeared in many teams (they are well-versed in the project, they know what lies where and where), so as not to reinvent the wheel and so on. Accordingly, they review not only the guys from their team, but also from others.
The review is a bit automated and on the pull-request we add labels that need to correspond. Then they will turn green and the OL will automatically merge. There are different labels: Code-style, Expert, Architect, CSS, E2E-test and others. If changing .less files - CSS is added, if any code of a kernel or low-level things changes - Architect is added. To get Expert, you need to recruit at least 2 appruva experts.
And if a person is new to the project or is not very strong in JS, then his code will be very different from what it was before the code-review.
TypeScript and JavaScript
I caught that moment when many wrote on TS and used new features that are transpiled in ES5. But even then, we used TS for typing, for some static code analysis for errors. Yes, you can write the code correctly and correctly in JS, but it will not support you as TS. Someone puts in the minuses that you have to write a lot of TS-code (overhead), i.e. typing, types, interfaces, etc. When we refactored the “old” JS> TS code, elementary errors were detected that would only work at runtime. That comma is not there, then the point is forgotten, then the brackets were closed early, etc., not to mention the inaccessible code and unused arguments, etc. ... When the system is large and the team cannot cover the entire system with tests, TS saves. With 3000-4000 scripts in general it is difficult to imagine how to live without TS.
Of course, when we write code in JavaScript, we can help the compiler and write code, as if we have a typed language: do not override variables, do not write different types to them, always return the same type. The question arises: if babel.js is used in this case, is there then a point in learning TypeScript?
We often argue about this. Some colleagues say: “Why do we need TS? We write the code correctly and conduct thorough code-review, select people at the interview, and indeed the Jedi JS ”. But no one has canceled human factors: laziness, haste, inattention. Nothing prevents to connect TS to your JS-code. If you really do not have a single error, the compiler will not find anything - you can be glad that you have a great team, and the stars have formed as it should. But to be safe from using TS still does not interfere. Moreover, it does not require any special expenses.
In addition, this year in version 1.8 TS made a convenient feature. Now you can check the types in pure JS - just add the “.js” files to the project and allowJs flag. If there is any code that you do not want to check, then you can safely ignore it through the @ ts-nocheck annotation. During code-review, minor bugs are almost impossible to catch, and TS helps save time and effort. Otherwise, you can add a release branch to develop with conflicts in 100 files ... I would like to see how a person coolly presses the MERGE button.
TypeScript vs Flow
“What about Flow?” You ask. We chose between ES6 and Typescript, nobody knew about Flow then. For those who are interested in what the difference is in their static code analysis, I can advise an interesting report by Ilya Klimov from the HolyJS 2017 Piter conference, where he compares TypeScript and Flow.
Spoons of tar
In addition to overhead, Typescript has several other drawbacks:
- Significantly slow down the build project. But this, again, is exclusively in our specific assembly: Webpack + TS + Babel. Who has the same configuration (+ - babel), I can advise using the ts-loader loader with the transpileOnly flag, and running the TSC in parallel. And in incremental build mode (--watch), keep 2 processes separate: webpack --watch and tsc --watch.
- There are problems with OutOfMemory nodeJS errors, such surprises are especially unpleasant when you need to build a project and release a release in 3-4 days, and you cannot solve them quickly.
- The need to update .d.ts versions for external libraries. Thank God, it's time to end with tsd> typings. And now everything can be downloaded immediately via npm> @types. And what if a new version of the library came out, for example, lodash, and .d.ts is not yet? Then you have to choose: add yourself (to the repository or put the PR on github into the DefinitelyTyped repository) or don't use this feature yet.
- Search for developers with TypeScript experience. These are separate tears of our HR. As far as I know, everyone in the market is now having trouble finding “advanced” frontend developers with experience in writing serious SPA, Angular | React | Vue, Typescript, Redux, etc.
Source: https://habr.com/ru/post/341278/
All Articles