将用户自定义操作和 ECB 菜单项迁移到 SharePoint 框架扩展
SharePoint 框架 (SPFx) 是扩展和生成 SharePoint 自定义项的建议开发模型。 如果使用 SharePoint 功能框架使用用户自定义操作和自定义编辑控制块 (ECB) 菜单项自定义 SharePoint，您可能想知道将它们迁移到 SPFx 的优势是什么？
首先，让我们介绍开发 SharePoint 框架 (SPFx) 扩展时的可用选项：
- 应用程序自定义工具：通过将自定义 HTML 元素和客户端代码添加到“新式”页面的预定义占位符来扩展 SharePoint 的本地“新式”UI。 有关应用程序自定义工具的详细信息，请参阅生成第一个 SharePoint 框架扩展（Hello World第 1 部分）。
- 命令集：将自定义 ECB 菜单项或自定义按钮添加到列表或库的列表视图的命令栏中。 可以将任何客户端操作关联到这些命令。 有关命令集的详细信息，请参阅生成第一个 ListView 命令集扩展。
- 字段自定义工具：使用自定义 HTML 元素和客户端代码自定义列表视图中字段的呈现。 有关字段自定义工具的详细信息，请参阅生成第一个字段自定义工具扩展。
可以利用上述任何选项，具体视自定义目标而定。 例如，应用自定义工具可有效替代用户自定义操作。 命令集 是 ECB 菜单项的相应替代项。 最后， 字段自定义工具 旨在替换 JSLink/客户端呈现 (CSR) 自定义项。
将现有 SharePoint 功能框架自定义迁移到 SharePoint 框架的优势
SharePoint 框架在推出时就已考虑到全新的 SharePoint“新式”体验，不仅可用于“新式”团队网站和“新式”通信网站，还定目标到任何设备和平台。
仅支持自定义无脚本“新式”网站的方法
将旧版 SharePoint 功能框架自定义迁移到SharePoint 框架的主要好处之一是，它是新式网站上唯一受支持的自定义 UI 的技术。
事实上，“新式”网站启用了 no-script 标志，这可以避免执行嵌入到页面中的任何脚本，以及任何用户自定义操作（指外部 JavaScript 或嵌入的 JavaScript）。
旧版用户自定义操作在“新式”UI 中根本不起作用。 使用功能框架生成的 ECB 自定义项是有限的。 只能定义不引用外部 JavaScript 文件或不使用嵌入式 JavaScript 调用的 ECB 项目。 如果真的想要扩展“新式”UI，则需要升级到 SharePoint 框架。
更轻松地访问 SharePoint 和 Microsoft 365 中的信息
要考虑的另一个基本点是，在用户自定义操作和 ECB 自定义的旧模型中，使用 SharePoint 内容和数据并不容易。 这样做的唯一方法是使用 JSOM（SharePoint 的 JavaScript 客户端对象模型）或低级 REST API。 此外，几乎不可能使用 Microsoft 365 的全套服务，除非你自主利用ADAL.JS (Azure Active Directory Authentication Library for JavaScript) 和自定义 JavaScript 代码。
现在，使用 SharePoint 框架 和 SharePoint 框架 扩展，可以轻松且直接地使用 SharePoint REST API 和 Microsoft Graph。 现在可以创建更强大的解决方案，这些解决方案可以使用 Microsoft 365 提供的完整服务生态系统并与之交互。
SharePoint 框架解决方案与 SharePoint 功能框架自定义的相似之处
SharePoint 功能框架用户自定义操作和 ECB 项以及 SharePoint 功能框架自定义项都有一些相似之处。
预配模型
SharePoint 框架扩展和用户自定义操作或 ECB 菜单项解决方案都利用 XML 清单文件，该文件使用 SharePoint 功能框架语法编写;部署基于相同的技术。
作为页面的一部分运行
与 SharePoint 功能框架的用户自定义操作和 ECB 类似，SharePoint 框架扩展也是页面的一部分。 这样一来，这些解决方案既可以访问页面的 DOM，也可以与同一页面上的其他组件进行通信。 此外，开发人员还可以更轻松地生成自适应解决方案，适应可能显示 SharePoint 页面的各种外形规格（包括 SharePoint 移动应用）。
由于 SharePoint 框架扩展作为页面的一部分运行，因此自定义有权访问的任何资源也都可供页面上的其他元素访问。 在使用持有者访问令牌生成依赖于 OAuth 隐式流的解决方案或使用 cookie 或浏览器存储来存储敏感信息时，请务必注意这一点。 由于 SharePoint 框架扩展作为页面的一部分运行，因此同一页面上的其他元素也可以访问所有这些资源。
使用任意库生成扩展
使用用户自定义操作生成页面自定义项时，你可能已使用 jQuery 或 Knockout 等库来实现动态自定义并更好地响应用户交互。 生成 SharePoint 框架扩展时，可以使用任意客户端库来丰富解决方案，这与过去的做法相同。
SharePoint 框架提供的另一个好处是脚本隔离。 即使 Web 部件作为页面的一部分执行，其脚本也会打包为模块，允许同一页上的不同扩展使用不同版本的 jQuery，而不会相互碰撞。 借助这一强大功能，可以专注于实现业务增值，而无需考虑技术迁移和功能妥协方案。
以当前用户身份运行
在使用用户自定义操作和 ECB 菜单项生成的自定义中，无论何时需要与 SharePoint 通信，都只需调用它的 API 即可。 客户端解决方案以当前用户身份在浏览器中运行。通过自动将身份验证 Cookie 与请求一起发送，解决方案可以直接连接到 SharePoint。 无需进行其他任何身份验证（如在使用 SharePoint 加载项时），即可与 SharePoint 通信。
相同的机制适用于在 SharePoint 框架基础之上生成的自定义，即也是在当前已验证用户的上下文中运行，并且无需执行其他任何身份验证步骤，即可与 SharePoint 通信。 安全上下文是当前连接用户的安全上下文，这意味着从安全角度来看，在任何目标网站集中安装任何 SharePoint 框架 扩展时需要小心。
仅使用客户端代码
SharePoint 框架扩展和用户自定义操作或 ECB 菜单项解决方案都是在浏览器中运行，并且都只能包含客户端 JavaScript 代码。 客户端解决方案有许多限制，如无法在 SharePoint 中提升权限，或无法访问不支持使用 OAuth 隐式流进行跨源通信 (CORS) 或身份验证的外部 API。 在这些情况下，客户端解决方案可以使用远程服务器端 API 执行必要操作，并向客户端返回结果。
托管模型自一致性且基于 Microsoft 365
SharePoint 框架扩展和用户自定义操作或 ECB 菜单项解决方案都可以托管在 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 是值得考虑的选项。
SharePoint 框架解决方案与 SharePoint 功能框架自定义的不同之处
不过，这两种开发模型也存在一些显著区别，应在设计解决方案的体系结构时考虑到这些不同之处。
在启用 NoScript 的网站中运行
由于SharePoint 框架解决方案（包括扩展）是通过事先批准的应用目录部署的，因此它们不受无脚本限制的约束，并且适用于所有“新式”网站。
预定义的一组扩展点
虽然用户自定义操作可以嵌入可以更新或更改页面任何部分的 DOM 的 JavaScript 代码，但SharePoint 框架扩展只能自定义“新式”页面支持的区域。
理论上来讲，可以创建应用自定义工具，从而使用 DOM 完全更改页面结构，就像是使用用户自定义操作一样。 SharePoint 框架建议使用结构化程度更高且更可靠的方法来自定义 SharePoint。 SharePoint 框架为开发人员提供了特定的自定义挂钩和占位符。只能使用这些挂钩和占位符，不能使用特定 DOM 元素自定义 SharePoint。
使用 TypeScript 生成更可靠且更易维护的解决方案
使用用户自定义操作或 ECB 菜单项生成自定义项时，开发人员通常使用 JavaScript。 此类解决方案经常不含任何自动测试，且重构代码容易出错。
通过 SharePoint 框架，开发人员可以在生成解决方案时受益于 TypeScript 类型系统。 由于类型系统，在开发期间而不是运行时会捕获许多错误。 此外，还可以更轻松地完成代码重构，因为代码更改受 TypeScript 保护。 由于所有 JavaScript 都是有效的 TypeScript，因此入门门槛较低，可以将纯 JavaScript 逐渐迁移到 TypeScript，从而提升解决方案的可维护性。
默认不访问 SharePoint JavaScript 对象模型
生成经典 SharePoint 用户体验的客户端自定义时，许多开发人员使用过 JavaScript 对象模型 (JSOM) 与 SharePoint 进行通信。 JSOM 为开发人员提供了 IntelliSense，并方便他们轻松访问 SharePoint API，就像客户端对象模型 (CSOM) 一样。 在经典 SharePoint 页面中，JSOM 的核心部分默认显示在页面上，开发人员可以加载其他部分，与 SharePoint 搜索（举个例子）进行通信。
新式 SharePoint 用户体验默认不包括 SharePoint JSOM。 虽然开发人员可以自行加载它，但建议改用 REST API，或在内部使用 SharePoint REST API 的 SharePoint 模式和做法 JavaScript 核心库（PnP JS 库）。 使用 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 不可分割的一部分。