react ui组件库_如何将大规模React UI组件代码库移至打字稿

最新推荐文章于 2024-08-08 08:10:09 发布

weixin_26705651

最新推荐文章于 2024-08-08 08:10:09 发布

阅读量390

点赞数

文章标签： python vue react ViewUI

原文链接：https://medium.com/bumble-tech/how-to-move-large-scale-react-ui-components-codebase-to-typescript-52e6f3ca1b55

版权

react ui组件库

Hi, my name is Ivan Grekov and I am a frontend developer at Bumble.

嗨，我叫Ivan Grekov，我是Bumble的前端开发人员。

Our frontend team’s main responsibilities are to deliver new user interfaces and support existing ones across our different applications, mostly within Badoo and Bumble websites. At a certain point in time, we started working on more projects in parallel and this resulted in our code needing greater reusability/stability. In order to achieve this, we decided to rewrite our React UI-components to TypeScript.

我们的前端团队的主要职责是在我们的不同应用程序(主要在Badoo和Bumble网站中)提供新的用户界面并支持现有的用户界面。在某个时间点，我们开始并行处理更多项目，这导致我们的代码需要更高的可重用性/稳定性。为了实现这一目标，我们决定将React UI组件重写为TypeScript。

At the start of our project, we had 630 UI-components to convert in different internal UI libraries. I am going to describe how we delivered this project without interrupting feature delivery and organised stage-by-stage onboarding to TypeScript for our UI-engineers, who were new to writing TypeScript.

在项目开始时，我们有630个UI组件可以在不同的内部UI库中进行转换。我将描述我们如何在不中断功能交付的情况下交付该项目，以及如何为我们的UI工程师(这是刚开始编写TypeScript的UI工程师)逐步组织到TypeScript的入职培训。

为什么我们决定这样做 (Why we decided to do it)

Our decision towards TypeScript was based on previous experience of our frontend department who had applied TypeScript in order to have type safety for business-logic shared across some of our projects.

我们对TypeScript的决定是基于我们前端部门的经验，该部门曾使用TypeScript以便在我们的某些项目中共享业务逻辑的类型安全。

Within the frontend department we had expertise in developing and scaling different JavaScript projects and we decided to switch to TypeScript to provide it.

在前端部门内，我们在开发和扩展不同JavaScript项目方面具有专业知识，因此我们决定改用TypeScript来提供它。

We had already separated business logic from UI components, which was of great help during the code support phase for our apps. Once we started creating shareable modules with business logic, our frontend team wrote it in TypeScript.

我们已经将业务逻辑与UI组件分离了，这在我们的应用程序的代码支持阶段提供了很大的帮助。一旦开始创建具有业务逻辑的可共享模块，我们的前端团队便用TypeScript编写它。

Thus our UI-unit had a clear understanding of the benefits of the business logic and we decided to use this approach too. First of all, it helped us with consistency across our codebase — having it in TypeScript. Secondly, we also benefit from type safety for UI-components.

因此，我们的UI单元对业务逻辑的好处有了清楚的了解，因此我们决定也使用这种方法。首先，它帮助我们实现了整个代码库的一致性-在TypeScript中具有一致性。其次，我们还受益于UI组件的类型安全。

Our ultimate goal was to make our apps more reliable and the process of writing code more predictable. Nevertheless, the project proved complex due to another factor — not everyone in our UI-unit had previous experience with TypeScript, so we had to ensure a smooth learning curve for every member of our team. Firstly, we discussed all the benefits we would get with TypeScript:

我们的最终目标是使我们的应用程序更可靠，编写代码的过程更可预测。然而，由于另一个因素，该项目被证明是复杂的-并不是我们UI部门的每个人都有过使用TypeScript的经验，因此我们必须确保团队中每个成员的学习曲线顺畅。首先，我们讨论了使用TypeScript可以获得的所有好处：

Reduced time spent on writing code/checking code. Once a component is written, it can be reused on different projects, which saves time.
减少花费在编写代码/检查代码上的时间。 编写组件后，可以在不同项目中重用它，从而节省时间。
Higher quality production code when we have type checks during the build, rather than in runtime. Most of our React-based apps and projects had already benefited from using prop-types. But the main problem was that these type checks had not been enforced during build and bundling of apps. This meant that if someone was changing API or type for one component, there was a chance of breaking changes. Thus it was resulting in desync between component types on different layers and in turn, bugs or warnings.
在构建期间而不是运行时进行类型检查时，将获得更高质量的生产代码 。我们大多数基于React的应用程序和项目都已经从使用prop-types中受益。但是主要的问题是，在应用程序的构建和捆绑过程中并未强制执行这些类型检查。这意味着，如果有人要更改一个组件的API或类型，则有可能破坏更改。因此，这导致不同层上的组件类型之间的不同步，进而导致错误或警告。

我们一开始所拥有的 (What we had in the beginning)

Our codebase is the basis for several separate projects. We use one code style and code-quality requirement for all of our supported web-apps. These apps’ frontend part is built in React. js.

我们的代码库是几个独立项目的基础。我们对所有受支持的Web应用程序使用一种代码风格和代码质量要求。这些应用程序的前端部分内置在React中。 js。

We divided business-logic and UI-representation following the frontend architecture approach, which was already used in our department. Thus we have 2 component types:

我们按照本部门已经使用的前端架构方法将业务逻辑和UI表示进行了划分。因此，我们有2种组件类型：

containers, which represent business logic in JavaScript
容器，代表JavaScript中的业务逻辑
ui-components, which usually are written as stateless functions.
ui组件，通常被编写为无状态函数。

It helps us to write and refactor UI components without needing to touch business logic, as mentioned before. This provides the benefit of being able to perform experiments and maintenance without holding up feature development.

如前所述，它可以帮助我们编写和重构UI组件，而无需接触业务逻辑。这样做的好处是能够进行实验和维护，而不会阻止功能开发。

Talking of feature development, allow me to introduce the team that works in this unit. It consists of 5 developers whose main area of expertise is user-interfaces. All of the members, including me, have frontend skills including experience with JavaScript and React. js library. However, most of us had no prior experience with TypeScript or never having worked with it before. In light of this fact, this project would achieve an additional objective — colleagues would be expanding their skillset.

说到功能开发，请允许我介绍一下在该部门工作的团队。它由5位开发人员组成，其主要专业领域是用户界面。包括我在内的所有成员都具有前端技能，包括JavaScript和React的经验。 js库。但是，我们大多数人都没有使用TypeScript的经验，或者以前从未使用过它。鉴于这一事实，该项目将实现另一个目标-同事们将扩展他们的技能。

Thus we had a set of goals to achieve and we needed to organise communication between all participants in this project. This was one of my main responsibilities. I was the point of contact on all project-related matters for all the team members. I was also providing on-going progress reports to management to ensure the project remained transparent, with clear expectations and that it achieved the desired end result.

因此，我们有一系列目标要实现，我们需要组织该项目所有参与者之间的沟通。这是我的主要职责之一。我是所有团队成员在所有项目相关事宜上的联络人。我还向管理层提供了持续的进度报告，以确保该项目保持透明，明确的期望并达到预期的最终结果。

Our key objectives for this project were:

我们对该项目的主要目标是：

Onboard team to work with TypeScript
板上团队使用TypeScript
Quickly migrate JavaScript react UI-components to TypeScript
快速将JavaScript react UI组件迁移到TypeScript
Avoid hindering feature development process during migration
避免在迁移过程中阻碍功能开发过程

I started by evaluating our input data. Since we had 5 team members and all of them had different degrees of knowledge of TypeScript and an existing work-load with various ongoing projects, it was important to start transitional work not only with code, but with the team as well.

我首先评估了输入数据。由于我们有5名团队成员，并且所有人都对TypeScript有不同程度的了解，并且现有的工作量与各种正在进行的项目有关，因此，不仅要使用代码，还要与团队一起开始过渡工作，这一点很重要。

I decided to focus on three key areas — code, process and team.

我决定专注于三个关键领域-代码，流程和团队。

When I started planning work on the project and was thinking about how to work with the codebase, I found an application for management method — PDCA to work with the codebase and team. Let’s see how it can be applied.

当我开始计划该项目的工作并考虑如何使用代码库时，我发现了一种管理方法的应用程序-PDCA与代码库和团队一起工作。让我们看看如何应用它。

代码状态评估 (Evaluation of code state)

First of all, when starting a large-scale project you need to know what you are working with. With this in mind, we need to start with generic quality and quantity indexes and measurements:

首先，在开始大型项目时，您需要知道您正在使用什么工具。考虑到这一点，我们需要从通用的质量和数量指标及测量入手：

代码量 (Code volume)

In order to roughly calculate the amount of work that will be required we look at how many components we currently have. In our case we used cloc. It gave us the following picture:

为了粗略计算所需的工作量，我们查看了当前有多少组件。在我们的例子中，我们使用了cloc 。它给了我们以下图片：

Of course, this data need some interpretation: in mid-January we had 554 JSX files in one project, comprising 227 components and 227 related to components spec-files with VRT-tests. We already had 62 components transpiled in TypeScript and 62 related to tests.

当然，这些数据需要一些解释：在1月中旬，一个项目中有554个 JSX文件，包括227个组件和227个与组件规格文件相关的带有VRT测试的文件。我们已经有了打字稿transpiled 62个组件和相关测试62。

This data is an excellent transparency marker as regards team progress — every week we were able to measure the progress of the project and compare it against our expectations. We set midday on Friday as the measuring point, since we usually have 2 releases a day Mondays to Thursdays but morning-only releases on Fridays.

这些数据对于团队进度而言是一个极好的透明度标记-每周我们都能够衡量项目进度并将其与我们的期望进行比较。我们将星期五的正午作为衡量点，因为通常星期一至星期四每天有2个发布，而星期五只有早晨发布。

For us, it meant that we were able to measure how many components had been transpiled and shipped to Production on that day. It gave us the opportunity to be flexible and recognise when the team was struggling to keep up or when our focus was shifted to other projects. Also, it meant that we were able to provide regular feedback and communicate our progress to the management, keeping our project expectations from this project transparent.

对我们来说，这意味着我们能够衡量当天有多少组件被移植并运送到生产环境。它为我们提供了灵活的机会，并可以识别团队何时难以跟上进度或何时将重点转移到其他项目上。同样，这意味着我们能够提供定期反馈，并向管理层传达我们的进度，从而使我们对项目的期望保持透明。

测试覆盖率 (Test-coverage)

Coverage is key when measuring changes in the codebase. Any code migration becomes easier with implemented tests. The two most important questions to ask during the initial planning phase are: Do we have tests for the components? What percentage of our components is covered by tests? These are the most important questions during initial planning.

衡量代码库中的更改时，覆盖率是关键。通过实施的测试，任何代码迁移都变得更加容易。在初始计划阶段要问的两个最重要的问题是：是否对组件进行了测试？测试覆盖了我们组件的百分之几？这些是初步计划中最重要的问题。

Visual regression tests are especially helpful in this type of project. They allow you to focus on testing functionality while spending less time on visual tests due to stable coverage.

视觉回归测试在此类项目中特别有用。由于覆盖范围稳定，它们使您可以专注于测试功能，同时减少在视觉测试上的时间。

项目计划 (Project planning)

Planning is an important part of any project. Here we divided the workload across the team and evaluated progress as we progressed. The effectiveness with which we initially planned the project would determine how quickly we would be able to spot the need for adjustments and apply them.

计划是任何项目的重要组成部分。在这里，我们将工作负载分配给了整个团队，并评估了进度。我们最初计划该项目的有效性将决定我们能够多快发现调整需求并加以应用。

探究依赖关系的图 (Graph to explore dependency)

If you know the quantity of codebase you can make some assumptions about the complexity of work, but this is still only one side of the process, and actually just the tip of the iceberg. Let’s look more closely at the complexity factor.

如果您知道代码库的数量，则可以对工作的复杂性做出一些假设，但这仍然只是过程的一方面，实际上只是冰山一角。让我们更仔细地看一下复杂性因素。

Before starting the work with code we need to check how it is interconnected. We need to know which components are codependent and based on it — and set the order of components to work with. For these purposes, we need to create dependency graphs for our components. We used a tool called madge which builds graphs based on project structure. The key feature for us was that madge is able to build graphs based on webpack configuration. This tool also has plenty of options to tune, which helps to create a proper map.

在开始使用代码之前，我们需要检查其如何互连。我们需要知道哪些组件是相互依赖的并基于它—并设置要使用的组件的顺序。为此，我们需要为我们的组件创建依赖图。我们使用了一个名为madge的工具，该工具可根据项目结构构建图形。对我们来说，关键的功能是madge能够基于webpack配置构建图形。该工具还具有许多调整选项，有助于创建正确的地图。

Using the generated graph, we started with components (see right side of the graph) and specifically those that are the most independent, with no/minimal dependencies. We moved these components to Typescript first.

使用生成的图，我们从组件开始(请参见图的右侧)，尤其是那些最独立，没有/最小依赖项的组件。我们首先将这些组件移至Typescript。

This approach helped us with problems related to component-type complexity and allowed us to distribute work among team members such that issues created by overlapping components or types based on several components’ interfaces, were avoided. Based on this data, updated each week, we were able to build a queue of components to transpile. The graph generated each successive Friday features fewer and fewer dependencies and components left to work with. It was also a good index of the project’s progress and helped with decision-making around pace.

这种方法帮助我们解决了与组件类型复杂性有关的问题，并允许我们在团队成员之间分配工作，从而避免了由于重叠的组件或基于多个组件接口的类型而产生的问题。根据每周更新的数据，我们能够建立起待运输组件的队列。在每个连续的星期五生成的图表具有越来越少的依存关系和可使用的组件。这也是该项目进度的良好指标，有助于按时进行决策。

估计组件复杂度 (Estimating component complexity)

So, you have made a list of components to transpile and listed the tasks required. You have also decided the order in which they will be transpiled — using the dependency graph. But how do you now assign these tasks most efficiently across the team? For this, you need to look at the components and mark them in the task list with certain tags for developers. In our project we introduced the following convention and filtering tags, and shared it across the team:

因此，您已列出了要移植的组件并列出了所需的任务。您还已经确定了使用依存关系图编译它们的顺序。但是，您现在如何在团队中最有效地分配这些任务？为此，您需要查看组件，并在任务列表中为开发人员标记某些标记。在我们的项目中，我们引入了以下约定和过滤标记，并在团队中共享：

TS basic component is one with a simple and straightforward interface and no/minimum dependencies.
TS基本组件是一个具有简单直接接口且无/最小依赖性的组件。
TS component is an average component. where you can find an understandable interface and see the minimum number of dependencies.
TS分量是平均分量。您可以在其中找到一个易于理解的界面，并查看最小的依赖关系数。
TS view is a complex component with a composite interface and possibly a long list of dependencies.
TS视图是一个复杂的组件，具有复合接口，并且可能有一长串依赖项。

Based on how familiar with TypeScript each developer was, and where they were on the learning curve, they started working with basic components, processing to the more complex.

根据每个开发人员对TypeScript的熟悉程度以及他们在学习曲线上的位置，他们开始使用基本组件，然后处理更复杂的组件。

Initially we agreed that I would assign the tasks to the developers. After a while, the more familiar with proceedings the team became, the more independence it developed and team members started working with tasks by themselves.

最初，我们同意将任务分配给开发人员。一段时间后，团队对程序的熟悉程度越高，开发团队就越独立，团队成员开始自己处理任务。

Further questions on component complexity to bear in mind while planning this kind of work include: Can this component be auto-transpiled? Is this component stateless/stateful? Does it have enums/unions in type? Does it require change of type or writing a new type?

规划此类工作时要记住的有关组件复杂性的其他问题包括：该组件可以自动翻译吗？该组件是无状态/有状态的吗？它有类型的枚举/联合吗？是否需要更改类型或编写新类型？

创建项目里程碑 (Creating project milestones)

As I mentioned earlier, your milestones should be data driven, tailored to the size and complexity of your project. Once you have evaluated it, divide it by component number, depending on the size of your team. For me, it was easier to measure progress weekly because of our release cycles, but you could also do it fortnightly or monthly. I opted for Gantt charts to help keep track of time spent on this project. They also helped maintain a level of transparency and facilitated regular reporting.

如前所述，您的里程碑应该由数据驱动，并根据项目的规模和复杂性进行定制。评估后，根据团队规模将其除以组件编号。对我来说，由于我们的发布周期，每周评估进度比较容易，但您也可以每两周或每月进行一次。我选择了甘特图，以帮助跟踪在该项目上花费的时间。他们还帮助保持了一定的透明度，并促进了定期报告。

Before starting actual coding there were several initial steps that needed to be followed:

在开始实际编码之前，需要遵循几个初始步骤：

里程碑0-设置团队知识库 (Milestone 0 — set team knowledge base)

Certain decisions helped us to save time as a team. One of them was that we would work in sync, which we did by sharing knowledge. Each member of the team either had prior knowledge of TypeScript or was on a learning curve in order to speak the same language. Sharing conventions about code-styles in one big document across the team proved highly beneficial and is recommended.

某些决定帮助我们节省了团队时间。其中之一是，我们将通过共享知识来同步工作。团队中的每个成员要么都具有TypeScript的先验知识，要么正处于学习过程中以便说相同的语言。在团队中的一个大文档中共享有关代码样式的约定非常有益，因此建议使用。

Firstly, it saves time because each member can check accumulated knowledge on specific questions instead of having to look it up on the internet.

首先，它节省了时间，因为每个成员都可以检查特定问题上积累的知识，而不必在互联网上查找。

Secondly, during the process team conventions can change over time. This is quite normal. And having open communication about it is also healthy. And having one up-to-date knowledge source is great help.

其次，在此过程中，团队惯例可能会随着时间而改变。这是很正常的。进行公开交流也很健康。并且拥有一个最新的知识源是很大的帮助。

We included different themes and recommendations in our shared knowledge base. Here are just some:

我们在共享的知识库中包含了不同的主题和建议。这里只是一些：

Type conflicts with CSS inlined styles if they are defined as a separate const/object,
如果将类型定义为单独的const / object，则类型会与CSS内联样式冲突，
Use global components, which are not imported and not used in props inside components
使用未导入且未在组件内部的props中使用的全局组件
Use several enums in one, with set of the key for each first value in each enum,
在一个枚举中使用多个枚举，并为每个枚举中的每个第一个值设置一组键，
Use union for an array of predefined values arrays.
将union用于预定义值数组的数组。

One of the main conventions for us was codestyle. Right before starting this project we adopted unified code-style across all our projects with the following toolset for javascript files: eslint, prettier. Whilst previously we might have written different code, now we committed it in just one code-style. This helped a lot during the transfer to TypeScript period. And because it was automated on pre-commit hook it added no extra complexity nor required extra time on the part of the developers.

对我们而言，主要约定之一是代码样式。在开始这个项目之前，我们在所有项目中都采用了统一的代码样式，并为JavaScript文件使用了以下工具集：eslint，更漂亮。以前我们可能编写了不同的代码，但现在我们仅以一种代码样式提交了它。在转换为TypeScript期间，这很有帮助。而且由于它是在预提交钩子上自动执行的，因此它不会增加开发人员的复杂性，也不需要额外的时间。

里程碑1-准备入职 (Milestone 1 — prepare onboarding)

It is important to make sure that onboarding flow suits the team well. At the outset we provided team members with starting reading lists. People were already working on other projects so, at their own pace, once they had completed their preparation they received their first tasks, starting with Typescript components labelled ‘basic’.

确保入职流程适合团队非常重要。首先，我们为团队成员提供了开始阅读清单。人们已经在从事其他项目，因此，按照他们自己的进度，一旦完成准备工作，他们将收到第一个任务，从标有“基本”的Typescript组件开始。

During the review process we provided more data on code convention. At the review stage, developers are already aware of code conventions from the existing shared knowledge base, so the process is fast and this was the case for us as well. Moreover, during checks for major errors during compilation of TypeScript and VRT tests during the review process developers have a safe space for learning and deploying these tasks with less stress. In that case VRT helps not only to maintain high code quality on the project, but also to reduce stress involved in learning new technology, and it also saves time on testing the visual changes.

在审查过程中，我们提供了有关代码约定的更多数据。在审查阶段，开发人员已经从现有的共享知识库中了解了代码约定，因此该过程非常快捷，我们也是如此。此外，在检查过程中检查TypeScript和VRT测试的编译过程中的主要错误时，开发人员可以安全地学习和部署这些任务，而压力较小。在那种情况下，VRT不仅有助于保持项目的高代码质量，而且还可以减轻学习新技术时的压力，还可以节省测试外观更改的时间。

建议：委派任务，跟踪进度 (Advice: Delegate tasks, set track for progress)

As mentioned before, tracking progress with tech tools and the project’s Gantt chart will help you scale a project to your team capacity. If there is potential to finish the project faster by sharing it across developers, you might need to delegate the tech part of work and ask for more people to take part in the project. When based on accurate progress data, such requests are more convincing. With this in mind, we are now set up and ready to start work. Now it is time to start actual coding.

如前所述，使用技术工具和项目的甘特图跟踪进度将帮助您根据团队能力扩展项目。如果有可能通过在开发人员之间共享而更快地完成项目，则可能需要委派工作的技术部分，并要求更多的人参与该项目。当基于准确的进度数据时，此类请求更具说服力。考虑到这一点，我们现在就可以开始工作了。现在该开始实际的编码了。

评估进度 (Evaluating progress)

Having mentioned some of the approaches earlier, I would now like to focus on the most important practices. At this stage of the project it is important to track essential indices regarding the progress of the whole team.

在前面提到了一些方法之后，我现在要集中讨论最重要的做法。在项目的此阶段，跟踪有关整个团队进度的基本指标很重要。

使用可衡量的KPI (Use measurable KPIs)

It might have been mentioned before and sound quite straightforward, but good communication is based on transparency. Transparency in project delivery can be achieved by use of KPIs, understood both by team members and management. For this project we used the following:

之前可能已经提到过它，听起来很简单，但是良好的沟通基于透明度。团队成员和管理层都可以理解，通过使用KPI可以实现项目交付的透明度。对于此项目，我们使用了以下内容：

codebase coverage on production — % of code, which is now in TypeScript, that was deployed.
生产上的代码库覆盖率 -已部署的TypeScript中现在包含的代码百分比。
engagement of UI developers — how many team members are already familiar with technology and use it.
UI开发人员的参与度 -已经有多少团队成员熟悉技术并使用它。
pace of work — how many tasks developers delivered in this period.
工作进度 -在此期间开发人员完成了多少任务。

团队内沟通 (Communicate within the team)

Rather than fixing any specific additional weekly meetings for this project, we used our normal weekly unit retrospective meeting to discuss progress. It took just one hour to discuss each member’s weekly progress within their area of responsibility. During these meetings I would report on project progress and ask if there were any specific issues to address. Most of the time any issues were resolved before the meeting and solutions were shared in team conventions documentation. Also, once a week I would report on our progress to our department management and answer any questions they had.

我们没有为此项目安排任何其他特定的每周会议，而是使用正常的每周单位回顾会议来讨论进度。只花了一个小时就讨论了每个成员在其职责范围内的每周进度。在这些会议期间，我将报告项目进展情况，并询问是否有任何具体问题要解决。大多数情况下，在会议之前解决任何问题，并在团队惯例文档中共享解决方案。另外，我每周一次向我们的部门管理层报告进展情况，并回答他们的任何问题。

更新代码样式 (Update codestyles)

During this project we often found old code patterns and corner-cases and in order to resolve the issues efficiently we shared knowledge via team conventions documentation. I am mentioning this again because it is an important part of the process — share updates across the team as soon as changes appear.

在这个项目中，我们经常发现旧的代码模式和极端情况，为了有效地解决问题，我们通过团队惯例文档共享知识。我再次提到这一点，因为它是流程的重要组成部分-更改出现后立即在团队中共享更新。

定期报告进度 (Report progress on regular basis)

This is an important part of your project-manager role. You need to compare indices regularly and keep your progress data up-to-date.

这是您的项目经理角色的重要组成部分。您需要定期比较索引，并保持进度数据为最新。

I mentioned the tools madge and cloc which we used for purposes of initial evaluation of codebase. At the same time every week I used the same tool-set used in our initial evaluation to collect data which was then compared to assess our team’s progress.

我提到了用于初始评估代码库的madge和cloc工具。每周的同一时间，我使用与初始评估中所使用的工具集相同的工具来收集数据，然后将其进行比较以评估我们团队的进度。

Week on week, you can see how fast you and your team are moving. It is useful to pause from time to time and ask — how we can improve these numbers? Is everything fine or do we need to speed up? And if so, how? Answering these questions certainly helped me to maintain transparency during the project.

您可以每周看到您和您的团队的迁移速度。时不时问一下，这将很有用-我们如何改善这些数字？一切都还好吗？还是我们需要加快速度？如果是这样，怎么办？回答这些问题无疑有助于我在项目期间保持透明度。

结果 (Outcomes)

We finished this process in approximately three months. All our developers are now on board with TypeScript and are writing new components in it.

我们在大约三个月内完成了此过程。我们所有的开发人员现在都可以使用TypeScript并在其中编写新的组件。

Because of how we organise task division, we were able to allocate team time between writing new code and rewriting old code. We were able to balance the task set optimally for each developer every week.

由于我们组织任务划分的方式，我们能够在编写新代码和重写旧代码之间分配团队时间。我们每周都能为每个开发人员最佳地平衡任务集。

It was an important outcome for us because one of our main concerns was about the transition period between JavaScript/TypeScript in codebase and how it affected product delivery. We found that it didn’t stop the development process but it did help make it more transparent.

这对我们来说是重要的结果，因为我们的主要关注点之一是代码库中JavaScript / TypeScript之间的过渡期以及它如何影响产品交付。我们发现它并没有停止开发过程，但确实有助于使其更加透明。

成功的团队入职 (Successful team onboarding)

One of our key goals was to onboard our team and share knowledge about technology. As a result of this project, skillset are now aligned within the team and all members now write in TypeScript.

我们的主要目标之一是加入我们的团队并分享有关技术的知识。作为该项目的结果，现在技能组已在团队中保持一致，并且所有成员现在都使用TypeScript编写。

完全透明的过程 (Fully transparent process)

Every week we synced progress within the team and with management.

每周我们都会同步团队内部和管理层的进度。

The communication procedures established for data exchange within the team, described earlier, helped us a lot. Data gathering for reports didn’t take a lot of time because it was mostly an automated process.

团队内部为数据交换而建立的通信程序对我们有很大帮助。收集报告数据并不需要花费很多时间，因为它主要是一个自动化过程。

更可靠，更快的开发过程 (More reliable, faster development process)

Because certain errors were now caught during build, not during QA-stage or in production, it really made a difference in the development flow. Also, due to prettier/eslint in pre commit hooks, developers are now incapable of making major generic mistakes, so avoiding app function failure.

由于现在在构建过程中(而不是在质量保证阶段或生产过程中)捕获了某些错误，因此确实对开发流程产生了影响。另外，由于pre commit钩子中的漂亮/附加，开发人员现在无法犯主要的通用错误，因此可以避免应用程序功能失败。

好的建议：选择正确的工具集 (Good advice: choose the right toolset)

Whilst it is up to each developer to choose the tools they consider most appropriate during a project, at the same time allow me to provide some advice here — use transpilers, codemods and snippets e. g. this VScode extension from Lyft in one click helps to rename file and move to TypeScript React function components structures and types. It supports React from 16. 3. 14 and can be tuned in order to support newer syntaxis if needed. Although at the time of publishing the article, this extension is archived, but it still works fine for our purposes.

虽然每个开发人员都可以在项目期间选择他们认为最合适的工具，但同时请允许我在此处提供一些建议-使用编译器，codemod和代码片段，例如，Lyft的VScode扩展名可以一键帮助重命名文件并移至TypeScript React函数组件的结构和类型。它从16、3、14开始支持React。如果需要，可以对其进行调整以支持更新的语法。尽管在发布本文时，此扩展名已存档，但对于我们的目的来说仍然可以正常工作。

You also can use specific codemods for transpiling. These are available now on github and npm. As long as it is helpful to transpile components and the quality of code is not compromised, it makes sense to do so and free up time for other work.

您还可以使用特定的codemods进行编译。这些现在可以在github和npm上使用。只要可以帮助移植组件并且不影响代码质量，这样做就有意义，并可以腾出时间进行其他工作。

Thus, this advice might also be equally applicable for any large-scale tech migration process related to Frontend.

因此，此建议也可能同样适用于与Frontend相关的任何大规模技术迁移过程。

最近有关React和TypeScript的文章 (Recent articles related to React and TypeScript)

Here is a list of articles that cover other aspects of moving React UI components to TypeScript. While I was working on this article in the first half of this year, a lot of great material on Typescript was published. I have split the article into 5 groups, depending on what stage of working with TypeScript you are at.

以下是涵盖将React UI组件移至TypeScript的其他方面的文章列表。当我在今年上半年撰写本文时，发布了许多有关Typescript的出色材料。根据您所处的TypeScript工作阶段，我将文章分为5组。

Articles on choosing between JavaScript/TypeScript for codebase:

有关在JavaScript / TypeScript之间选择代码库的文章：