通过

将 JSLink 自定义迁移到 SharePoint 框架字段自定义工具

  • 项目

建议使用SharePoint 框架 (SPFx) 来扩展和生成 SharePoint 自定义项。 如果使用 JSLink 自定义了 SharePoint 字段和列表视图，则可能想知道将这些自定义项迁移到 SPFx 的优势是什么。

首先，介绍一下 SharePoint 框架扩展的开发选项：

  • 应用程序自定义工具：通过将自定义 HTML 元素和客户端代码添加到“新式”页面的预定义占位符来扩展 SharePoint 的本地“新式”UI。 有关应用程序自定义工具的详细信息，请参阅生成第一个 SharePoint 框架扩展（Hello World第 1 部分）。
  • 命令集：将自定义编辑控制块 (ECB) 菜单项或自定义按钮添加到列表或库的列表视图的命令栏。 可以将任何客户端操作关联到这些命令。 有关命令集的详细信息，请参阅生成第一个 ListView 命令集扩展。
  • 字段自定义工具：使用自定义 HTML 元素和客户端代码自定义列表视图中字段的呈现。 有关字段自定义工具的详细信息，请参阅生成第一个字段自定义工具扩展。

可以利用上述任何选项，具体视自定义目标而定。 例如，字段自定义工具可有效替代 JSLink 字段自定义。

提示

虽然字段自定义工具是 JSLink 的自然迁移路径，但你还应该使用列表和列格式来评估自定义列表视图。 这两种技术都有各自的优点和缺点，其中一种技术可能比另一种技术更易于实现和维护，具体取决于你的方案。

可在此处了解详细信息： 使用列格式自定义 SharePoint

SharePoint 框架是为了扩展 SharePoint 的“新式”体验而构建的。 “新式”团队网站和“新式”通信网站提供“新式”体验，面向任何设备和任何平台。

自定义“新式”列表和库的唯一受支持方法

将旧 JSLink 自定义迁移到 SharePoint 框架 的主要好处之一是，它是唯一受支持的可用选项。 事实上，由于“新式”列表和库的呈现基础结构以及“新式”网站上启用了 无脚本 标志，因此不能依赖于旧的 JSLink 自定义项。 如果真的想要扩展“新式”UI，则需要将 JSLink 解决方案迁移到SharePoint 框架字段自定义工具。

更轻松地访问 SharePoint 和 Microsoft 365 中的信息

另一个要考虑的基本主题是，在旧版 JSLink 自定义项中，使用 SharePoint 内容和数据并不容易。 执行此操作的唯一方法是使用 JavaScript 客户端对象模型 (JSOM) 或低级别 REST API。 除非使用适用于 JavaScript 的 Azure Active Directory 身份验证库) 和自定义 JavaScript 代码ADAL.JS (，否则几乎不可能使用 Microsoft 365 的完整服务集。

现在，使用 SharePoint 框架 和 SharePoint 框架 扩展，可以轻松且直接地使用 SharePoint REST API 和 Microsoft Graph。 现在可以创建更强大的解决方案，这些解决方案可以使用 Microsoft 365 提供的完整服务生态系统并与之交互。

SharePoint 框架解决方案与 SharePoint 功能框架自定义的相似之处

JSLink 自定义项和 SharePoint 功能框架自定义项都有一些相似之处。

预配模型

SharePoint 框架扩展和用户自定义操作或 ECB 菜单项解决方案都使用 XML 清单文件，该文件使用 SharePoint 功能框架语法编写。 因此，部署依据的技术都相同。 不过，使用新的字段自定义工具，可以自定义字段呈现，但无法自定义列表或库的单一视图呈现。 自定义字段可以在任意数量的列表和库中使用。

作为页面的一部分运行

与用户自定义操作和 SharePoint 功能框架的 ECB 类似，SharePoint 框架扩展是页面的一部分。 这样一来，这些解决方案既可以访问页面的 DOM，也可以与同一页面上的其他组件进行通信。 此外，开发人员还可以更轻松地生成自适应解决方案，适应可能显示 SharePoint 页面的各种外形规格（包括 SharePoint 移动应用）。

由于SharePoint 框架扩展作为页面的一部分运行，因此无论自定义项有权访问什么资源，页面上的其他元素也可以访问。 在使用持有者访问令牌生成依赖于 OAuth 隐式流的解决方案或使用 cookie 或浏览器存储来存储敏感信息时，请务必注意这一点。 由于SharePoint 框架扩展作为页面的一部分运行，因此该页上的其他元素也可以访问所有这些资源。

使用任意库生成扩展

使用用户自定义操作生成页面自定义时，可能使用过 jQuery 或 Knockout 等库，这样做是为了让自定义动态呈现，并更好地响应用户交互。 生成SharePoint 框架扩展时，可以使用任何客户端库来扩充解决方案，就像以前一样。

SharePoint 框架的另一个好处是，可以隔离脚本。 即使将 Web 部件作为页面的一部分执行，它的脚本也会打包为模块。这样一来，即便同一页面上的各个扩展使用不同版本的 jQuery，也不会相互冲突。 借助这一强大功能，可以专注于实现业务增值，而无需考虑技术迁移和功能妥协方案。

以当前用户身份运行

在使用 JSLink 生成的自定义中，无论何时需要与 SharePoint 通信，都只需调用它的 API 即可。 客户端解决方案以当前用户身份在浏览器中运行。通过自动将身份验证 Cookie 与请求一起发送，解决方案可以直接连接到 SharePoint。 无需进行其他任何身份验证（如在使用 SharePoint 加载项时），即可与 SharePoint 通信。

相同的机制适用于在 SharePoint 框架基础之上生成的自定义，即也是在当前已验证用户的上下文中运行，并且无需执行其他任何身份验证步骤，即可与 SharePoint 通信。 安全上下文是当前连接用户的安全上下文，这意味着从安全角度来看，在任何目标网站集中安装任何 SharePoint 框架 扩展时需要小心。

仅使用客户端代码

SharePoint 框架扩展和 JSLink 自定义项都在浏览器中运行，并且只能包含客户端 JavaScript 代码。 客户端解决方案有许多限制，如无法在 SharePoint 中提升权限，或无法访问不支持使用 OAuth 隐式流进行跨源通信 (CORS) 或身份验证的外部 API。 在这些情况下，客户端解决方案可以使用远程服务器端 API 执行必要操作，并向客户端返回结果。

托管模型自一致性且基于 Microsoft 365

JSLink 自定义项的SharePoint 框架扩展和 JavaScript 文件都可以托管在 SharePoint Online 上，并最终托管在 Microsoft 365 CDN 服务中，从而避免对外部服务或托管环境的任何需求。

虽然在 CDN 上托管SharePoint 框架解决方案具有许多优点，但这不是必需的，您可以选择在 SharePoint 文档库中托管代码。 SharePoint 框架包 () 部署到应用程序目录的 *.sppkg 文件，指定SharePoint 框架可在其中找到解决方案代码的 URL。 对于具体的 URL 没有任何限制，只要浏览包含扩展的页面的用户可以从指定位置下载脚本即可。

Microsoft 365 提供公共 CDN 功能，可用于将文件从特定的 SharePoint 文档库发布到 CDN。 Microsoft 365 公共 CDN 在使用 CDN 的优势和在 SharePoint 文档库中托管代码文件的简单性之间取得很好的平衡。 如果你的组织不介意其代码文件公开可用，则使用 Microsoft 365 公共 CDN 是值得考虑的选项。

不过，这两种开发模型也存在一些显著区别，应在设计解决方案的体系结构时考虑到这些不同之处。

在启用 NoScript 的网站以及“新式”列表和库中运行

由于SharePoint 框架解决方案（包括扩展）是通过事先批准的应用程序目录部署的，因此它们不受无脚本限制的约束，并且适用于所有“新式”网站。 正如我们已经看到的，SharePoint 框架的字段定制器在“新式”列表和库中工作，而旧版 JSLink 则不起作用。

字段自定义工具支持仅视图方案

JSLink 自定义不仅可用于自定义列表或库中字段的视图，还可用于自定义单项字段的显示和编辑视图。

在撰写本文时，SharePoint 框架的字段自定义工具只能在列表视图呈现模式下自定义字段的呈现，而在单个项目的显示和编辑视图中，则不能利用自定义。

使用 TypeScript 生成更可靠且更易维护的解决方案

使用 JSLink 生成自定义时，开发人员通常使用的是纯 JavaScript。 此类解决方案经常不含任何自动测试，且重构代码容易出错。

通过 SharePoint 框架，开发人员可以在生成解决方案时受益于 TypeScript 类型系统。 有了此类型系统，就可以在开发期间捕获错误，而无需等到运行时捕获。 此外，还可以更轻松地完成代码重构，因为代码更改受 TypeScript 保护。 由于所有 JavaScript 都是有效的 TypeScript，因此入门门槛较低，可以将纯 JavaScript 逐渐迁移到 TypeScript，从而提升解决方案的可维护性。

默认不访问 SharePoint JavaScript 对象模型

为经典 SharePoint 用户体验构建客户端自定义项时，许多开发人员使用 JSOM 与 SharePoint 通信。 JSOM 以类似于 CSOM) 的 Client-Side 对象模型 (的方式为他们提供 IntelliSense 和对 SharePoint API 的轻松访问。 在经典 SharePoint 页面中，JSOM 的核心部分默认存在于页面上，开发人员可以加载其他部分来与 SharePoint 搜索通信，例如。

新式 SharePoint 用户体验默认不包括 SharePoint JSOM。 虽然开发人员可以自行加载，但建议改为使用 REST API，或者使用 SharePoint 模式和实践 JavaScript 核心库 (PnPJS) ，后者在内部使用 SharePoint REST API。 使用 REST 更为通用，且可以在不同的客户端库（如 jQuery、Angular 或 React）之间进行互换。

Microsoft 没有积极投资 JSOM。 如果希望使用 API，可以使用 PnP JS 库，该库提供流畅的 API 和 TypeScript 类型声明。

将现有自定义迁移到SharePoint 框架扩展

将现有自定义项迁移到 SharePoint 框架 扩展为最终用户和开发人员提供了许多好处。 考虑将现有自定义项迁移到 SharePoint 框架时，可以选择重复使用尽可能多的现有 JavaScript 脚本，或使用 TypeScript 完全重写自定义项。

重用现有脚本

将现有自定义项迁移到 SharePoint 框架 扩展时，可以选择重用现有脚本。 即使 SharePoint 框架建议使用 TypeScript，也可以使用纯 JavaScript，并逐渐转换为 TypeScript。 如果需要在有限时间内为特定解决方案提供支持或预算有限，这种方法可能就可以满足现有需求。

在 SharePoint 框架解决方案中重用现有脚本的方法不一定可行。 例如，鉴于 JavaScript 库的多样性，很难预先判断是能够在 SharePoint 框架解决方案中重用现有脚本，还是需要进行完全重写。 为了确定这一点，只能尝试将不同部分移到 SharePoint 框架解决方案中，并检查这些部分能否按预期正常运行。

重写自定义

如果需要在较长时间内支持解决方案，或者希望更好地利用SharePoint 框架，或者事实证明现有脚本不能与SharePoint 框架一起使用，则可能需要完全重写自定义项。 虽然相对于重用现有脚本而言，这样做的成本更高，但它可以在较长时间内实现更佳效果，即解决方案的性能更优，且更易维护和使用。

将现有自定义重写为SharePoint 框架解决方案时，应从所需功能开始。 若要实现用户体验，应考虑使用 Office UI Fabric，让解决方案看起来是 SharePoint 不可分割的一部分。

另请参阅