微前端：带有微应用程序的 Windows 克隆版

我计划构建一个在线作品集作为操作系统克隆，我的想法是将其构建为作品集，并将我的不同项目作为应用程序呈现，并能够在运行时添加任何应用程序。

后来我放弃了这个想法，坚持添加任何应用的功能，也就是微前端。操作系统克隆基本上是个噱头。

什么有效

• 文件夹导航
• 照片应用程序
• 新建文件夹并重命名文件夹（不适用于桌面路线，有缺陷！）
• 开始菜单（虽然没有任何可点击的内容）
• 可重新排列的快速应用程序（教程）
• 通知外壳
• 快速操作
• 日历微应用

不工作

• 上传应用程序已停止工作（可能是由于 Heroku 上的空间或类似限制）

什么是微前端

这是一种类似于微服务的设计方法，我们不需要创建一个大型的前端应用程序，而是将其分解成基于相同或不同技术构建的松散耦合的前端应用程序集合，这些应用程序可以协同工作。

起源

几年前，我们的网站/应用往往包含一堆 HTML 或 PHP 文件。大约从 2006 年开始，人们开始使用浏览器 API 将部分 HTML 更新到 DOM 中，从而实现页面的部分或全部更新，而无需重新加载，这些就是迈向 SPA 的第一步。

然后在 2010 年，Angular 诞生并席卷了网络。谷歌推出它时，几乎每个人都对它着迷，它将 SPA 所需的所有优点和必需部分都集中在 Angular 框架中。当时它真的很神奇，现在仍然如此，而且很多事情都发生了变化。过了一段时间，2013 年，Facebook 推出了 React，没过多久，它就占据了上风。2015 年，React 的下载量几乎翻了一番，来源：npmtrends，现在大约是原来的 20 倍，这背后有各种原因，比如虚拟 DOM 使 React 性能更高（尽管 Angular 后来赶上了），学习曲线低，JSX 等。

进展如何

接下来是微前端

一种架构风格，将可独立交付的前端应用程序组合成一个更大的整体。

-马丁·福勒

目标是使不同的团队更容易地进行开发和交付，理想情况下不应该相互依赖，一个应用程序的失败不会影响其他应用程序，最简单的例子可以是在每个路线上加载不同应用程序的导航，而无需重新加载。

用户永远不会知道应用是如何加载的，它们之间是否存在差异或组件。它的行为类似于单页应用 (SPA)，但在后台，可能有多个应用为其提供支持。除了路由之外，它们还可以共存于同一页面，就像移动设备或桌面主屏幕上的小部件一样。

这些小部件属于不同的应用程序，但在同一屏幕上工作并且完全解耦，但如果您将从同一应用程序加载两个小部件，例如待办事项列表和待办事项计数器，则完成列表中的项目也应该减少计数，这里存储的数据正在更新并且其他方法正在监听它，其他方法可以分派事件。

微应用如何在 Web OS 中工作

1. 使用 CRA 模板在 Code Sandbox 上构建任意应用，无需在公共文件夹中添加任何内容。（此问题尚未解决）
2. 压缩应用程序。
3. 使用应用程序管理器上传所需的元数据。
4. 应用程序将安装在操作系统中以供运行时使用。

那里的日历应用程序是以同样的方式上传的！

这一切听起来很酷，但究竟发生了什么？

幕后

有很多方法可以做到这一点，我们只需要使用 Code Sandbox 构建的应用程序代码/包和要挂载的特定 div！

好的，我们需要一个应用程序包，并且我们有一个 zip 文件，然后将其捆绑！

这就是上传应用时的步骤：我解压它，将所需文件复制到 bundle 包中，并复制一份 Webpack 配置，还有一些其他东西。我没有使用 CRA 的 react-script，因为我只需要一个 bundle 包（main.js）！（我们稍后会讲到这一点），必须处理资源文件，这样才能正确加载它们。

构建完应用后，我将其推送到一个带有特定前缀的 bucket 中，该前缀是应用上传时生成的唯一 ID。现在，每当用户点击图标时，主 React 应用都会调用该小应用的 bundle 文件。

现在，每个资产都main.js位于节点应用程序的一个端点后面，该端点依次从存储桶中传输文件，因此即使存储桶 URL 发生变化，我也只需要更新端点的控制器，我可以在这里启用 CDN，因为所有文件都可以更快地交付。

在 UI 端，每当用户点击某个应用时，除了获取main.jsI 之外，还会动态创建一个 div，其中包含挂载该应用所需的 ID。然后，React 应用的 JavaScript 代码就会执行并将自身挂载到该 ID 中。之后，它就和其他 React 应用一样了。由于该应用与操作系统应用不共享相同的上下文，因此它们之间的通信不会直接进行，因此我们需要一些辅助函数来window简化通信。

分块

当我创建整个场景时，我无法弄清楚如何获取特定应用程序的入口点，因为如果一个应用程序有多个块，则需要几个块来启动应用程序，这也可以做到，然后我们需要加载那些 JS 文件/块，而不是只加载单个 JS 文件。

验证

这是一个 POC，所以身份验证并不重要，但有一个选项是与 Google 签名以上传应用。假设一个聊天应用需要用户登录，现在为不同的应用多次验证同一个用户的身份并不能提供良好的体验，这个问题可以通过将用户管理转移到一个单独的应用（主应用）来解决。如果任何其他应用需要身份验证，他们可以共享主应用的访问令牌并获取该特定应用的访问令牌。在服务器端，聊天应用微服务将与主应用服务通信以生成特定于此应用的访问令牌，或者他们可以只为每个应用共享一个令牌。

我在开发过程中尝试过采用高度模块化的方法，这样就可以把所有东西都做成微应用，但目前还没有这样做。这样我们就可以在运行时替换或更新任何应用，并且不同的用户可以为同一功能使用不同的应用，例如文件夹应用。应用只需遵循 CRUD 操作的模式即可，至于具体如何操作则由应用自行决定。

并非每个大型应用都需要拆分成微应用，还有其他方法，甚至像Bit 生态系统这样更容易开发，或者只是一个更好的组件模型！这一切都取决于需求。

欢迎在评论中分享您的想法/反馈！

--EOF--