纽约公共图书馆选择 React 重建其网站

纽约公共图书馆（The New York Public Library）认识到它需要基于 React 框架来重建其数字馆藏网站。最终它选择了 Next.js。

纽约公共图书馆的数字馆藏团队拥有除电子书之外的所有数字内容。其中包括印刷品、照片、视频和音频。

据纽约公共图书馆的软件工程师Emma Mansell介绍，该网站拥有超过 100 万件的藏品，而且图书馆的馆藏每天都会增加。

“我们的馆藏品超过 5400 万件，你知道有句话说得好，藏品越多，责任越大，”她开玩笑说，引用了著名的蜘蛛侠的名言。“我们有一个非常小的团队，我们的资源有限，我们的首要任务是访问，几乎把其他一切都排除在外。”

整个数字部门大约有 80 人，包括产品经理和设计师。

可访问性是第一要务

该图书馆的应用程序和网站都专注于一个目标：让数字馆藏变得触手可及。

“如果某项资料的元数据需要很长时间才能加载，那么进行研究就会非常困难，网站的性能也会很差。”Mansell 说道。“如果某位顾客在谷歌上搜索我们馆藏中的资料，而我们的资料甚至都没有出现，那么你就不能说可以很容易地找到我们馆藏品。”

数字馆藏网站允许对藏品进行搜索和引用。她补充道，它展示了很多细节，虽然浏览这些藏品很有趣，但它是一个严肃的研究工具。

仅仅优化主页的可访问性是不够的。Mansell 说，图书馆必须在所有的网站上都可以访问，并且在各个方面都是可访问的。网站上的每个组件都需要经过单独的可访问性审查。

每个网站的每个页都是量身定制的，以满足 Web 内容无障碍性指南（Web Content Accessibility Guidelines）标准，该指南是万维网联盟的一系列 Web 无障碍性指南（the World Wide Web Consortium）的一部分。

“所有这些网站和应用程序都是为了在各个层面上创建对我们馆藏的访问而构建的，”她说。“我们的技术需要支持幼儿园的孩子阅读他们的第一本书，就像支持在当今国家顶级研究机构工作的学者一样。”

图书馆的堆栈

在所有这些图书馆应用程序和网站之下，纽约公共图书馆有自己的开源设计系统，称为 Reservoir设计系统。她补充道，这是一个可扩展的 React 组件库，包括英雄按钮（Hero Button），每个组件都经过了可访问性审查。Mansell 说，该系统的目标是为纽约公共图书馆数字（NYPL）世界的所有用户提供一致的视觉体验。

但图书馆的一些网站无法使用 Reservoir，因为它们与 React 不兼容。

这个旧的数字馆藏网站是在 2013 年使用Ruby on Rails构建的。尽管它的性能很好，但它的外观已经过时了，不符合图书馆的无障碍性标准。她说，从字体大小到颜色对比度，都需要改进。

他们希望更新网站的设计，使其更现代、更便于访问，并希望使用 Reservoir 来实现这一目标。这意味着他们需要一个React框架。

她说，该网站还部署了 AWS，这是在 Mansell 上任之前做出的决定，因为在2023年大英图书馆遭到黑客攻击后，图书馆对安全问题有着强烈的担忧。

Next.js 与 Express 的对比

该团队需要一个 Node.js 框架来支持工作，并决定在 Express 和 Next.js 之间作出选择。他们最终选择了开源 Next.js，是因为：

• 她说，Next.js 是超轻量级的，开箱即用。由于图书馆的数字馆藏团队规模很小，他们没有足够的人力在前端创建复杂的自定义配置。

• Mansell 表示，纽约公共图书馆没有升级其后端，这一点很重要。“一些拥有图书馆学学位的非常聪明的工程师已经为我们构建了后端。”她说。“我们不会乱动它。我们只想要一些可以点击到位的东西。”

• 她指出，Next.js 也能很好地执行混合渲染，而且纽约公共图书馆也希望转向服务器端渲染。“我们希望将这两种方法很好地结合起来，”她说。

• 最后，实际上也是最重要的一点，纽约公共图书馆数字馆藏团队拥有在 Next.js 版本 9、10 和 11 方面经验丰富的开发人员。

她说：“尽管 Next.js 自这些版本以来实际上已经发生了很大的变化，但我们知道这是一个很好的起点，随着图书馆的数字馆藏和其他网站转向使用 Next.js，我们可以合作并分享知识。”。

组织迁移

她说，第一个挑战是将 Ruby on Rails 应用程序迁移到新的 Next.js 应用程序中。为了使整个网站更易于管理，他们沿着 URL 线将其拆分，以便第一阶段专注于主页和关于页面。

“最初，我们的设想是，让我们把 Ruby 控制器函数一对一地映射到 Next.js API 路由上。”她说。“但我们很快就放弃了。”

Ruby on Rails 使用 MVC 模式，即模型-视图-控制器（MVC）模式，这是一种用于分离应用程序的用户界面、数据和逻辑的Web开发设计模式。然而，Next.js 却有着不同的数据获取方法。

“对 Next.js 的数据获取完全不熟悉。”Mansell 说。“我是作为一名主要使用 React 的开发人员加入的，所以对我来说可能更容易上手，但我们的很多开发人员已经习惯了使用 Ruby on Rails。”

网站的空白 Next.js 基板

团队决定从一个空白的基板开始。起初，该团队使用的是页面路由（Page Router），但随后应用路由（App Router）从测试版推出。这导致团队面临下一个重大决策：他们是否应该切换到相对较新的应用路由？

“我们当时犹豫不决，因为我们无法以真正的意图使用应用路由；也就是说，无法与服务器组件一起使用。”她说。“如果你一直都在非常仔细地倾听的话，你可能已经注意到这一点了，但我们在使用服务器组件方面遇到了很大的障碍，那就是我们自己的设计系统。”

“我们相信这是 Web 开发的未来……一旦我们的设计库准备就绪，我们就可以在这个项目中使用服务器组件了。”

 

——Emma Mansell，纽约公共图书馆的软件工程师

数字馆藏团队正在迁移该网站，以便使用所有已经构建的 Reservoir 组件，但这些组件在服务器端都不起作用，因为设计系统是建立在Chalk UI（一个 CSS 和 JS 库）基础上的。她解释说，这要求一切都在客户端进行。

“我们最终在 App Router 中为我们的每一个页面重新创建了获取服务器端的 props。”她说。“我们基本上是抓取页面组件、服务器组件上的数据，并立即将其传递给页面级组件。”

该团队发现，除了服务器组件之外，Next 14 还有其他好处。例如，路由器（Router）缓存对于数字馆藏团队来说非常重要，它拥有通用的页眉和页脚可以帮助缩短页面加载时间。她说，之前版本中存在的错误边界为团队节省了大量错误处理工作。最后，这一举动也改进了团队的文档，团队发现 Next 14 文档中的加载和 Suspense 更加清晰。

此外她补充说，选择 Next.js 的决定也有象征意义。

“我们是一家非营利组织。事情进展得非常缓慢，所以对我们来说，就如何使用服务器组件展开对话是值得的。”她说。“我们相信这是 Web 开发的未来……一旦我们的设计库准备就绪，我们就可以在这个项目中使用服务器组件了。”

她一边演示新网站，一边补充说，对图书馆来说，进行这样的对话就已经是迈出了一大步。

“它更漂亮，更干净，”她说。“我们对它的性能也很满意，同时它的可访问性也有所提高。”

原文链接：

https://thenewstack.io/new-york-public-library-on-choosing-react-to-rebuild-website/