焕然一新：将青少年网站带入现代水疗世界

多年来，网络社区赞同单个分页申请（SPA）架构的益处。几乎任何Web会议或流行的技术博客，你一定会遇到一个关于他们的福利的讨论。它使我们为什么这是一个感觉：每次导航到网站的不同页面时，等待加载和初始化HTML，JavaScript和样式表的完整页面;按需加载小型JavaScript是快速的。SPA也允许我们避免在页面加载之间避免可怕的空白屏幕，而让我们提供更多用户友好的加载屏幕。这使得SPAs比传统架构更适合用于在某些国家/地区的移动网络，甚至是桌面网站的连接环境。如果正确优化，即使是第一页的负载也可以相当瘦;我甚至不会进入着名的财务激励，提供快速浏览体验。简短版本是：得快。

但是，许多SPA讨论不考虑哪些水疗讨论是如何迁移到单页架构的过程。

尤其是当您处理的是一个成熟的应用程序时，它有数百万的用户和成堆的不易理解的代码。这是可以理解的，为什么不谈论太多，许多最有发言权的科技公司往往分为两类之一：要么他们是一个相对较新的初创企业，科技债务按比例很少；要么他们是一个更成熟的FAANG类型，有几乎无限的资源来解决科技债务。

在Ok188bet金宝搏官网Cupid，我们从2004年就开始工作了，有一个相当小的（约30人）工程团队全程为事情提供动力。我们的web代码库早于rubyonrails，当您得知我们的技术栈依赖于一个类似PHP的服务器端呈现框架（我们称之为Pub）时，您可能会感到惊讶（或者相当震惊）。直到最近，我们的产品还是Pub、vanilla JS、jQuery、Coffescript、React、Reflux、Redux等的拼凑，主要依赖服务器端的水合状态来代替适当的api。此外，还有无数可能死掉的代码路径和有条件地注入的有用性值得怀疑的第三方脚本。所以，当我们谈论遗留代码和技术债务时，这就是我们要讨论的问题。

And as many of you know, it’s often difficult to make a business justification for a ground-up rewrite of a product. So how do you take a web application older than some JavaScript programmers and bring it into the modern era? Well, we’ve actually been making significant progress towards this goal for a while now. The fact that React can easily render into an existing app was crucial to helping us start adopting it, as early as mid-2016—and today our product is thankfully almost entirely React-powered. I’m also happy to report that all of our product pages are API-driven (though we’re not quite at the GraphQL-powered utopia we’re striving towards—more on that later). Both of these were slow, gradual transitions that we've been working at for years, and that made our eventual move to a SPA significantly easier.

但是，尽管取得了这么大的进步，直到最近，我们仍然依赖Pub来实时生成每个请求的HTML页面。这使我们无法做一些很酷的事情，比如不让程序员学习一门编造的语言（对招聘非常有用）。所以大约6个月前，我开始一个项目，让我们离开酒吧。我们用我们的移动网络产品开始了这一转变，并在3个月后将这些经验带到了桌面网络。这两个平台的任务清单都很广泛，但相当简单：

• 在编译时生成HTML文件以提供我们的JavaScript捆绑包。
• Ensuring a fast (enough) first paint.
• 使用代码拆分来避免最终得到一个臃肿的包。
• 确定样品板逻辑等更好的抽象，如第三方脚本。
• 更新遗留vanilla javascript工具依靠直接DOM操作进行反应。
• 消除任何未使用的代码，我找到了一路。

在这种大规模迁移的过程中，我发出了一些观察结果，并设计了一种夫妻抽象，我希望您可以在清理旧代码以及编写新代码时发现有用。

追踪死亡代码

因此，让我们从最合乎逻辑的方式开始解决这些项目符号：按字母顺序排列。消除未使用的代码是迁移我们的传统基础架构时的巨大目标。部分这是理想主义的（Yay删除代码！），部分这是务实的（参与少代码转换！）。但是，令人难以置疑的挑战是在遗留的代码对保持我们的网站工作中至关重要的挑战，以及可以安全地删除哪些代码，因为从Okcupid托管期刊和论坛的日子里没有相关（是的，我们曾经做过那样188bet金宝搏官网;不，我不能告诉你为什么我们认为这是一个好主意）。然而，在我们的工具带中有一个非常基本的工具，证明了在弄清楚的代码是运行的并且不是：分析！

有很多代码，我偶然发现了我的工程侵权队已经有了远见，以便将分析事件添加到。当我找到这些时，我会检查他们是否在去年左右被解雇，并在什么卷中被解雇，并判断判断是否可以切除违规代码。This honestly made me want to add an analytic event to every single React component I ever write. Someone talk me out of it.

如果只有一切都像发射分析事件一样简单！

优化第一个油漆

迁移到单个页面应用程序的另一个困难方面是我们的大部分网络应用程序依赖于我们的React应用程序中始终保证的某些数据。虽然这很易于确保使用服务器端数据保健程序，但在移动到静态HTML模板时，这更具挑战性。摆脱所有这些依赖性都会非常繁琐，难以致讨，所以我们必须制定解决问题的策略。最后，我们解决了这样的东西：

// index.js - our main application entry point import React from "react"; import ReactDOM from "react-dom"; import API from "./api"; import Helpers from "./helpers"; import App from "./app"; import AppError from "./app_error"; const root = document.getElementById("root"); // Load the absolute necessities. API.loadCriticalData() .then(() => Helpers.initializeGlobals()) .then(() => ReactDOM.render(, root)) .catch((error) => ReactDOM.render(, root));

它所做的是加载对我们的应用程序绝对重要的数据。然后，通过初始化一些全局库，使数据可供应用程序的其余部分使用。最后，它将应用程序呈现给DOM。如果此过程中的任何操作失败，我们将返回错误状态。

然而，这种方法有一个重要的缺点：在我们等待数据加载时呈现的是什么？我们不想向用户展示一个空白屏幕，而这发生 - 即使它只会每次会话发生一次，也显示用户一个空白屏幕永远不会理想。要打击此功能，我们将使用App Shell填充我们的模板文件：

// index.html