关键的买点

1. 新的JavaScript、CSS、HTML和WebAssembly标准的速度正在加快，以覆盖现代应用程序开发的所有方面。
2. TypeScript的受欢迎程度急剧上升，现在已经进入了GitHub上最受欢迎的10种编程语言，InfoQ今年对很多框架和库进行了调整。
3. WebVR/WebXR和机器学习，推动更好的3D渲染和数据可视化
4. React的采用已经大大增加，但新一波的框架正在获得大量使用，其中包括Vue.js
5. 应用程序的广泛选择，从先进的Web应用程序，到Electron, Ionic和Cordova等混合应用程序，再到React native和NativeScript等完整的本地编译器，为使用Web技术创建有竞争力的应用程序提供了越来越多的灵活性。

在InfoQ上，我们定期更新我们的主题图，以显示我们认为不同的主题在技术采用曲线中的位置。当我们这样做的时候，我们会考虑实践的状态，新兴的想法和我们在网络中听到的事情，以及在聚会、会议、分析师活动等等。我们还考虑了网站的流量模式和出席QCon和其他行业会议的人数。

如果话题是在右手图的一部分,你可能会发现很多现有InfoQ上的内容,我们覆盖了它当它是新的,和经验教训的创新者和早期采用者可以帮助引导个人、团队和组织,因为他们采用这些想法和做法。

曲线的主题左边是我们认为新兴的现在,使用的创新者和早期采用者,我们重点报告和内容将这些想法对我们的读者的注意力,这样他们就可以自己决定他们是否应该探索现在,或者等着看他们如何展开。

这个月我们将讨论JavaScript和Web开发，因为这个快速变化的行业每年需要进行一次以上的更新。这是我们在2018年第一季度回顾的图表。

这是2018年第四季度的修订版

web开发领域对我们来说总是一个有趣的领域，几乎每天都有新的JavaScript框架发布。试图决定哪些是需要关注的，哪些是需要忽略的尤其具有挑战性。开发人员可以从有趣的方法中学习和收集灵感，即使他们目前在日常开发工作中不使用它们。

创新者

从过去几个月的趋势来看，随着浏览器厂商超越最小可行版本，努力提高性能并填补空白，人们对WebAssembly的兴趣持续增长。

CSS Houdini在CSS领域掀起了一场热潮，PostCSS等工具正在挑战SASS、LESS和Stylus等现有的CSS预处理程序。CSS Houdini是我们继续关注的一个领域。

Deno是Node最初的创建者开发的一个新项目。在TypeScript中编写，试图解决Node.js的挑战。这是一个非常早期的项目，但显示了重大的前景。

Dojo是最早的JavaScript工具包之一，可追溯到2004年，今年发布了版本2(以及随后的版本3和4!)这代表了一个使用TypeScript的主要重写，它将Dojo变成了一个现代的、响应式的、标准一致的、基于虚拟dom的框架。新版本在性能和开发人员人机工程学方面比同类产品有了显著的改进，但它还处于采用周期的早期。

js已经成为基于javascript的机器学习的基础库。我们跟踪这个库以及利用它推进JavaScript机器学习状态的项目。

早期采用者

看看我们早期的采用者，我们继续跟踪Flow(用于JavaScript的静态类型检查器)和Elm(用于生成基于JavaScript的web应用程序的替代JavaScript语言)。

自从我们的上一份报告以来，我们已经提升了一些技术到这一类别，由于增加了行业的吸收:

• GraphQL仍然是我们遵循的一个趋势，已经建立了几个库，包括Apollo、Vulcan.js和urql。
• ECMAScript 2018现在是最终版，2019版的工作正在顺利进行。
• WebVR及其未来的替代者WebXR通过HTML、CSS和JavaScript提供了虚拟、增强和混合现实功能。随着标准从VR扩展到XR，目前出现了很大的波动，但是浏览器和JavaScript对这个领域有很大的兴趣。像A-Frame和React 360这样的库通过使用Three.js而流行起来。

我们也增加了一些早期的采用者:

与Elm一样，Reason也是JavaScript的另一种替代方案，它还提供了类型安全性和对JavaScript的流线型转换。

WICG是W3C的Web平台孵化器社区小组，它一直致力于将各种各样的有用标准转化为成果，从交集观察器和调整大小观察器等最终标准，到picture-in-picture和WebUSB等更具实验性的技术。

Web组件在过去几年里不断发展，现在Chrome和Firefox都支持本地组件，Safari也提供部分支持，Edge也在努力。许多框架和库本身也支持web组件，包括Angular、Dojo、ion、Stencil、Svelte和Vue.js。

CSS Next包含了一系列在标准过程中不断改进的CSS，其中许多可能会与PostCSS或CSS Houdini一起使用。

ion4目前处于beta测试阶段，已经经历了重大的变化，将自己从Angular等特定框架中分离出来，并专注于与现代标准保持一致。

NativeScript为Angular和Vue.js用户提供了本地编译选项，用于部署使用web技术编写的移动应用程序。

最后，net .js是一个很有前途的服务器端框架，用TypeScript编写，运行在Node.js之上

早期的多数

在我们的“早期多数”类别中，Vue.js继续发展并获得支持，我们认为它已经跨越了“早期多数”状态的鸿沟。我们看到中国对Vue.js特别浓厚的兴趣，而最近重新设计的InfoQ也利用了这个框架，目前处于测试阶段。Vue.js 3正在积极开发中，包括使用TypeScript重写。

Angular的第7版最近发布了，并在不断改进。

构建和绑定工具通常对于优化生产应用程序非常有用。几乎每个框架都利用一些工具组合来优化性能。

我们已将electronic和TypeScript 提升至早期多数地位。electronic是一个被广泛采用的桌面应用程序外壳，它结合了Node.js和Chromium，为使用web技术的应用程序提供基础设施。

TypeScript是最广泛采用的JavaScript变体，在过去几年中取得了长足的进步，现在大多数JavaScript框架都利用了它的工具和基础结构。根据GitHub最近的一份10年报告，TypeScript本身是十大语言之一，JS的状态调查将TypeScript列为目前使用最广泛的JavaScript变体。

我们在早期多数人类别中直接增加了三个项目:

React Native是一个使用JavaScript和React构建本地移动应用的框架，并迅速成为构建跨平台移动应用的流行方式。

同样，函数式和反应式编程模式主导了关于如何最有效地构建JavaScript应用程序的讨论。像lodash这样的库帮助推广了这些模式。

晚期大众

随着JavaScript生态系统的成熟，现在有一些属于后主流类别的基础技术没有被取代的迹象，但是几乎每个JavaScript开发人员都在使用它们。

我们已经提升了几个项目到我们的后期多数地位。

ide和编辑器通常被广泛使用。在桌面上，VS代码似乎已经在Atom、Sublime Text、WebStorm、甚至vim或emacs上取得了实质性的领先。像CodeSandbox这样的基于浏览器的ide为web浏览器带来了大量的VS代码体验，用于快速开发、试验和共享开发成果。

Babel version 7最近发布了，它在新出现的JavaScript版本和开发人员需要根据需要支持的版本之间提供了默认的转换。

Babel，用于将源代码从JavaScript的新兴版本转换为生产环境中支持的语言特性集的JavaScript转换工具。

React是自jQuery以来应用最广泛的框架，并在不断发展;支持React的新项目几乎每天都会发布。

Node.js 是一个被广泛采用的JavaScript服务器端和命令行环境，NPM是最常用的Node.js包管理器。几乎每个JavaScript项目的命令行和构建工具都使用Node.js，而Node.js在服务器端开发和嵌入式系统中都得到了广泛采用。

Express也在我们的列表中，是使用最广泛的节点。js-based服务器端框架。Webpack也在我们的列表中，它是事实上的构建和绑定工具，也是基于Node.js的。

我们加入HTML5和ES6/2015作为后期的主流，因为几乎所有的web应用程序都使用这些特性作为最低基线。

落后者

我们用落后者来结束我们的报告，虽然它仍然在许多应用程序中使用，但是对于新的开发工作并没有引起很大的兴趣。更新的版本已经取代了ES5和HTML4。Dojo 1。x和角1。x虽然仍在广泛部署，但处于维护模式。jQuery虽然得到了一些改进，但大部分已经被新的HTML和JavaScript特性或更成熟的框架所取代。

结论

JavaScript生态系统正在蓬勃发展，尽管跟上变化的速度可能很有挑战性，但我们相信这个领域中的许多基础部分已经变得稳定，这为创新创造了额外的领域。InfoQ的团队将为您提供JavaScript领域的专家报道，我们欢迎您的反馈、评论和外部文章贡献。

 

本文：https://pub.intelligentx.net/node/810

讨论：请加入知识星球【首席架构师圈】

介绍javascript框架

毫无疑问，JavaScript（JS）在开发者社区中的受欢迎程度多年来呈指数级增长。 原因是它能够允许开发人员以多种方式设计和修改网页，甚至可以为实时网络应用程序添加功能。 JavaScript不仅因其简单性和易用性而受到关注，而且还因其带来的效果 - 效率，安全性和低成本结果而受到关注。

与此同时，先进技术正在推动技术人员为JS的存储库添加新技能。 毫无疑问，JavaScript库/框架市场今天有点乱。 在可用选项方面存在很多噪音，开发人员通常需要通过学习多个库/框架来测试水域，以确定最佳选择。

考虑2018年流行的JS状态调查，其中给出了开发人员当前使用的库的数量：

尽管今天有许多库，但调查结果证明Vue，React和Angular仍然是市场领导者。

1. Vue.js

Vue成为2018年最受欢迎的前端GitHub项目，这一壮举在2018年跟随着117k星和超过29k叉的框架（在撰写本文时）。 Vue.js由他在Google期间参与过许多Angular.js项目的Evan You创建，是Angular.js的轻量级副本，并且也被证明是一种有吸引力的替代品。

开发人员喜欢Vue的主要原因之一是因为它是一个渐进的框架。这意味着它可以优雅地适应开发人员的需求，从3行开始到管理整个视图层。 VueJS可以通过“脚本”标签快速集成到应用程序中，逐渐开始探索空间。

但是Vue特别有效，因为它为Angularjs，Reactjs和Knockout等框架提供了最佳选择和可能性。这使得它成为所有框架的最佳版本，整合在一个干净整洁的软件包中。

让我们来看看使用Vue.js开发的优点和缺点

Vue.js的优点

 

1. 尺寸：这是Vue的最佳亮点之一。 Vue的生产就绪结构令人惊讶地轻巧 - 拉链后只需18kb。与其他主要框架相比，这为其提供了急需的速度和准确性。同时，即使是Vue周围的生态系统也很小而且速度快，因为它允许用户将模板到虚拟DOM编译器以及运行时间分开。
2. 集成能力：Vue提供了最佳的集成功能之一，因为它可用于构建单页面应用程序和复杂的Web应用程序。框架的小型交互式部分可以轻松地与其他框架/库集成，例如Django，Laravel和WordPress。
3. 可扩展性和多功能性：您可以将Vue用作库或完全成熟的框架。由于结构简单，Vue可以很容易地用于开发大型和可重复使用的模板，而且操作简单。
4. 适应性：大多数适应Vue的开发人员都从其他主要框架转向它。由于Vue与React和Angular的相似性，切换周期经常变得很快。
5. 可读性：Vue非常易于阅读和理解，因为功能非常容易访问。此外，可以使用不同的组件来优化HTML块处理。

Vue.js的缺点

 

1. 缺乏资源：由于目前市场份额较小，Vue仍有很长的路要走。相对年龄也增加了常见插件的困境，这使得使用外部工具有点困难。
2. 快速进化：虽然快速开发阶段对于框架来说是好的，但在功能方面却很好，学习曲线也在不断变化。因此，在线资源可能最终过时，文档有时可能是开发人员的唯一资源。
3. 反应性注意事项：文档清楚地说明了一些反应性警告，例如直接从数组中设置项目。这可以通过使用items [key] = value或添加新的data属性来完成。因此，这需要在开发过程中得到有效处理。

2. React.JS

React是另一个流行的JavaScript库，为Facebook提供支持。它于2013年由Facebook开发和开源，很快就开始涉及动态数据处理的大型Web应用程序的开发。

在2019年1月，Facebook通过将创建反应应用程序（用于帮助创建React应用程序的CLI工具）从孵化移动到官方Facebook存储库，扩展了对该库的支持。

React广泛使用的主要情况之一是开发人员需要分解复杂代码并在无错误的环境中重用它们，这些环境能够处理实时数据。与生命周期挂钩相关的元素（如装饰器）有助于增强用户体验。

React利用虚拟DOM帮助它与任何应用程序集成。与其他JS库/框架相比，它还采用JSX来构建组件并有助于开发更多SEO友好的Web页面。

为了帮助您选择最适合您需求的库/框架，让我们来看看React.js开发的优缺点：

React.js的优点

 

1. 易于学习：React在语法方面展示了简单性，涉及大量HTML编写技巧。与Angular不同，它需要精通TypeScript的陡峭学习曲线，因此React对HTML的依赖使其成为最容易学习的JavaScript库之一。
2. 库，而不是框架：React是一个JavaScript库而不是框架。这意味着它提供了一种定义UI组件的声明方法。它还可以与其他库轻松集成。例如，React-Redux库提供了React和Redux库之间的必要粘合。
3. 数据和表示：React提供数据和表示层的完全分离。虽然它确实具有“状态”的概念，但它最好用于存储持续很短时间的存储。
4. DOM绑定：开发人员不必经历将DOM元素绑定到功能的痛苦。 React通过在代码的多个区域中仅使用职责分割绑定来处理此问题。
5. 可重用组件：Facebook开发的React方式使其能够随时重用任何级别的代码组件。这在开发过程中节省了大量时间。这种能力主要增加了设计效率，使开发人员可以轻松处理升级，因为对一个组件所做的任何更改都不会影响另一个组件。
6. 单向数据流：React利用向下数据绑定。这有助于确保对子结构所做的任何更改不会最终影响其父级。这使得代码更加稳定，并且开发人员需要做的就是更改对象，修改其状态并应用更新。

React.js的缺点

 

1. 高度发展的步伐：React的环境非常动态，不断变化。这增加了开发人员不断刷新和学习新技能的责任。这对刚开始的开发人员来说可能是一个令人头痛的问题。
2. JSX作为障碍：React积极利用JSX，这是一种语法扩展，允许将HTML与JavaScript混合。尽管JSX可以保护代码免受注入（以及其他好处），但它确实涉及高度复杂性和陡峭的学习曲线。
3. 搜索引擎优化问题：用户报告了有关搜索引擎优化的问题，因为搜索引擎使用客户端渲染很难索引动态网页。虽然意见主要是推测性的，但专家建议开发人员了解Google和其他搜索引擎的抓取工具是如何体验它们的。

3. Angular.JS

Angular被认为是最强大的开源框架之一。它是一种“一体化”解决方案，旨在为开发人员提供开箱即用的各种选择。从路由到HTTP请求处理和采用TypeScript，一切都已设置完毕。

虽然Angular的学习曲线在早期版本中非常陡峭，但它已在最新版本的Angular 5和6中得到了平滑。通过强大的CLI可以实现这一点，这已经消除了了解低级细节的需要。适用于简单应用。

由Google开发和维护，Angular遵循每6个月发布新版本的计划。最新版本主要集中在增加新功能和提高性能。

以下是Angular.JS开发的优缺点：

Angular 5的优点

1. 文档：Angular 5附带详细的文档。与早期版本的Angular相比，这使新开发人员更容易掌握框架并理解其他项目的代码。
2. 更简单的PWA：渐进式Web应用程序越来越受欢迎，Angular团队已迅速将该功能集成到框架中。 Angular 5也可以获得本机移动应用程序的功能。
3. 构建优化器：Angular 5中的构建优化器删除了所有不必要的运行时代码。这使得应用程序更轻，更快，因为应用程序中JavaScript的大小减少了。
4. 通用状态转移API和DOM：Angular 5已经引入了Universal State Transfer API和DOM支持。这有助于在服务器和客户端版本的应用程序之间共享代码。这有助于提高应用程序的感知性能。
5. 路由器挂钩：现在可以从正在运行的防护装置开始跟踪路由器周期，直到激活完成。
6. 数据绑定和MVVM：Angular 5允许双向数据绑定。这可以最大限度地降低可能出错的风险，并实现应用程序的单一行为。另一方面，模型视图视图模型功能允许开发人员在具有相同数据集的同一应用程序部分上单独工作。

Angular 5的缺点

 

1. 复杂语法：就像Angular的第一个版本一样，Angular 5也涉及一组复杂的语法错误。尽管如此，它使用的是TypeScript 2.4，与其他Angular版本相比，它更难学习。
2. 迁移：从旧版本的Angular迁移应用程序可能是一个问题，尤其是对于大型应用程序。
3. 高流失：尽管Angular在使用方面非常受欢迎，但它也可以用来计算最大程度的流失率。这可能是由于与当今其他流行的替代方案相比，学习曲线更加陡峭。

比较表 - Angular 5 Vs React.js Vs Vue

以下是对2019年最受欢迎的3个JavaScript框架/库的比较的综合外观，让您可以鸟瞰当前的情况：

结论

所有3个框架/库今天都非常流行，并得到健康的生态系统和开发团队的支持。 没有正确的答案，这完全取决于您的个人选择和编程风格，因为每个框架都涉及不同的开发理念。 无论如何，React，Vue和Angular继续主宰JavaScript世界。

另请阅读：Angular vs. React vs. Vue：2018年比较（更新）

您认为哪个JavaScript框架/库最好？ 在评论中与我们分享您的观点！

原文：https://medium.com/cuelogic-technologies/top-3-best-javascript-frameworks-for-2019-3e6d21eff3d0

本文：http://pub.intelligentx.net/node/519

讨论：请加入知识星球或者小红圈【首席架构师圈

 

在过去十年中，JavaScript 框架的数量急剧增加。 Angular 和 React 已成为顶级 JavaScript 框架中的流行选择。 它们允许开发人员在比以往任何时候都更少的时间和更少的代码中创建高质量的 Web 应用程序和移动应用程序。

Angular 被认为是创建单页快速执行应用程序的理想选择。 另一方面，对于需要闪电渲染服务的 Web 和移动应用程序开发项目，React 是一个令人信服的选择。 在好框架和差框架之间进行选择总是更容易。

但是，有两种理想的选择可供选择，很难确定哪一种最适合您的需求。 看看下表，就 Angular 与 React 做出明智的决定。

在本文中，我们将比较 Angular 与 React 2022。让我们探索以下内容：

• 好处
• 缺点， ＆
• 这些框架之间的差异。

它将帮助您做出明智的决定，决定将哪一个用于您的下一个项目。

Angular-确保更快的 SPA 开发

 

由 Google 创建的 Angular 是一个强大的前端框架，可以轻松构建具有基于 HTML 的用户界面的应用程序。 Angular 还提高了 Web 应用程序的速度并减少了代码大小。 Angular 被 NASA、强生、Capital One、沃尔玛等公司使用。

由于它能够从基于 DOM 操作的模板生成干净的 JavaScript 代码——并且由于它是用 JavaScript 本身编写的——与其他框架相比，Angular 拥有卓越的开发性能。

此外，前端开发人员在使用 Angular 2 编写模块时使用 TypeScript 而不是普通的 JavaScript。他们在单元测试中对变量和对象有完整的类型支持。它最终提高了测试质量和生产力。

使用 Angular 的优点

 

• 使用 Angular 的主要好处是它的速度。 Angular 背后的编译器创建高效的代码，这意味着您可以更快地加载您的网站，
• Angular 非常适合 SEO。这也意味着更少的错误，从而节省调试时间。
• 由于更好的错误消息和更详尽的文档，Angularjs 开发人员几乎不需要其他团队成员的帮助（这降低了成本）。
• 此外，由于 Google 是在内部创建的，因此您将获得一个设计精良且安全性高的平台。
• 最后，因为它是一个开源平台，所以如果需要，您可以随时寻求帮助。

使用 Angular 的缺点

 

• Angular 使用双向数据绑定，这在某些情况下可能会出现问题。例如，如果算法输出无意义的值（例如 blargle Fargo），那么您的输出也将没有意义。
• 您有时会发现自己在这样的情况下调试了几个小时，却不知道为什么某些东西不能正常工作。

React - 为应用程序提供高渲染性能

React 是一个用于设计有吸引力的用户界面的 JavaScript 库。与您可能使用过的其他 UI 库不同，React 将您的 UI 视为您可以在应用程序中使用的另一个组件。您不会在代码中编写 HTML；相反，您使用 HTML/JavaScript 构建功能并以您认为合适的方式呈现它们。

这种灵活性还允许组件重用——而不是一遍又一遍地编写（和重写）几个非常相似的 HTML 片段，使用 React，您可以在任何其他需要的地方重用每个组件。因此，当您尝试在有限的时间内完成项目时，您应该聘请 React Native 开发人员。

使用 React 的优点

 

• React 易于学习并使复杂的事情变得简单。
• 它是开源的。
• 您可以将它与任何技术堆栈一起使用，如果您不喜欢现有的技术堆栈，甚至可以将其构建到您的堆栈中。
• 有大量围绕 React 的开发工具可以为开发人员（和最终用户）提供出色、稳定的体验。
• 它被 Facebook、Instagram、Netflix 等公司使用。

使用 React 的缺点

 

• 对于许多库，您必须等待开发人员的更新才能获得错误修复或新功能。作为开发人员，这可能很麻烦并且会降低您的工作效率，因为您可能需要在每次更新时进行调整。
• 它的文档很差，因此很难将新团队成员加入开发团队。

介绍了这两种技术的优缺点后，让我们来探讨这两种技术之间的区别。

学习曲线：分析最简单的应用程序

与其最著名的竞争对手 React 相比，Angular 的学习曲线相对陡峭。虽然使用这两个框架都需要对 HTML 和 JavaScript 有基本的了解，但 Angular 还需要 Typescript 和 RXJS 的知识。

与 Angular 相比，你会更快地使用 React，因为它使用更直接的语法并且主要坚持构建组件来创建应用程序。

但是，假设您熟悉 Java 或 C++ 等面向对象的编程语言，或者之前曾在其他语言或平台上广泛使用过 OOP 概念。在这种情况下，您可能会发现开始使用 Angular 比使用 React 更容易。

所以，赢家是：真正的赢家取决于你的编码能力。

框架大小：选择较轻的框架以提高应用程序性能

随着时间的推移，JavaScript 框架的规模不断扩大。已知最早的 JavaScript 框架是 Dojo，它于 2001 年左右推出，总下载大小为 9MB。如今，流行的图书馆要大得多。 Angular 2 + Rx 的下载大小为 766K。相比之下，React 0.14.5 + React DOM + Redux 的大小为 139K。

选择框架时，请记住它需要由用户下载并安装在客户端计算机上。除了下载之外，考虑用户需要多久更新他们的库也很重要。当给定的更新涵盖安全补丁或错误修复时尤其如此。

那么，谁是赢家：React 无疑是这里的赢家。

DOM 模型：确保更快的开发速度

在 Angular 中，元素是活动的，它们不会创建任何 HTML DOM 副本。在 React 中，Virtual DOM 用于使用树差异进行快速渲染。这意味着每次对 UI 进行更新时，它都会检查已更改的内容并仅更新需要更新的内容。

这种方法适用于处理小的数据更改，例如从元素按顺序出现的列表或表格中添加/删除项目。这就是为什么重要品牌更喜欢在他们的用户界面 (UI) 开发中使用 React，因为与 Angular JS 相比，它使用更少的带宽使应用程序加载更快。

那么，谁是赢家：React

可扩展性：通过不断增长的 LCB 获得出色的性能

您可以使用这些框架中的任何一个。如果您期待制作可以处理大量数据的应用程序，您可以获得完美的性能。

例如，聊天应用程序或电子邮件应用程序必须选择 Angular。其背后的原因是 Angular 使用多种形式的数据绑定系统，这可以防止不必要的开销，以跟上所有更改。

React 遵循基于组件的架构，允许您使用小块代码构建应用程序。如果应用程序将发生重大变化，那么只更新该块而不是整个应用程序是毫不费力的。

那么，谁是赢家：Angular。

开发人员可用性：提供负担得起的项目开发

 

资料来源：Stack Overflow 开发者调查

与主要竞争对手 Angular 相比，React 最显着的优势之一是更多的开发人员知道如何使用它。 根据 2021 年 7 月的 Stack Overflow 调查，36.8% 的受访者表示他们在项目中使用过 React，而 Angular 的这一比例仅为 26.5%。

它使您可以接触到更多有使用 React 经验的开发人员，如果您决定使用它，可以加快开发速度。 随之而来的是，如果你可以聘请一位对 React 了如指掌的经验丰富的开发人员，而不仅仅是一个知道的足以应付的人。

这将比使用其他技术的经验不足但同样熟练的开发人员花费更多。 因此，Angular 开发人员的费用比 React 开发人员的费用更实惠。 背后的原因是一个简单的事实，即 Angular 比 React 早三年推出。

那么，谁是赢家：Angular。

顶级品牌的使用：看看全球企业更喜欢什么

作为其主要目标之一，React 是帮助团队构建大型应用程序，而不会因复杂的工具集和陡峭的学习曲线而感到不知所措。 Facebook 的开源库允许您使用组件而不是经典的 Web 视图来构建应用程序。

它有助于防止功能和视觉复杂性的臃肿，有时感觉就像永远爬山一样。如果您决定将来扩展到移动或原生应用程序开发，更轻的组件还可以更轻松地在平台之间迁移。

一些使用 React 构建的世界级应用程序包括 Facebook、Netflix、Instagram 等。

另一方面，Angular 旨在帮助我们创建和维护大型 Web 应用程序。它可以处理从简单的数据视图到复杂的单页应用程序 (SPA) 的所有内容。由于它的特性和易用性，开发人员喜欢在几乎所有可能的平台上使用 Angular！

Gmail、福布斯和 PayPal 是一些信任 Angular 的顶级品牌。

最后的要点

 

• React 的体积比 Angular 小得多，占用空间更轻。
• React 遵循虚拟 DOM 模型。
• Angular 确保创建可扩展的应用程序。
• Angular 开发人员的小时费率相对较低。

在阅读了我所有的比较数据之后，您现在可以决定哪个框架更适合您的项目或公司。对于这两个框架中的哪一个会获胜，没有答案。 Angular 和 React 各有利弊。

由您和您的团队决定哪一个将使您的项目更易于访问和舒适。我希望我的帖子能帮助您了解这些框架是如何相互叠加的。

 

原文：https://enlear.academy/angular-vs-react-in-2022-83a2ac15230c

本文：https://jiagoushi.pro/node/1981

今年年初，如果你告诉我我会发布使用 Redux 的推荐，我会当着你的面笑。 然而我们来了。

状态

状态是确定应用程序将如何呈现的持久信息。

我们将讨论以下类型的状态：

• 本地状态：指的是在 React 组件中持久化的状态。
• 全局状态：指的是所有组件都可以访问的全局存储中持久化的状态。
• 服务器状态：指在服务器上持久化的状态。 （为了这个对话 - 在客户端缓存中自动管理，使用像 React Query 这样的工具。）

Redux

Redux 由 Dan Abramov 和 Andrew Clark 于 2015 年创建，作为跨整个 React 应用程序管理和提供状态的解决方案。 Redux 创建一个名为 Store 的全局状态，并允许您将组件连接到 Store 以访问全局状态。 Redux 有助于防止 prop 钻取，并使跨多个组件的状态管理变得更加容易。

但是经典的 Redux 有很多痛点，包括：

• 陡峭的学习曲线
• 一个臭名昭著的样板问题
• 缺乏标准架构——没有 2 个 Redux 实现是相同的； 很少有人是好的
• 糟糕的 TypeScript 支持

Redux 工具包

2019 年 10 月，Redux Toolkit 1.0 发布。

“Redux Toolkit 是我们官方的、固执的、包含电池的工具集，用于高效的 Redux 开发。 它旨在成为编写 Redux 逻辑的标准方式，我们强烈建议您使用它。”— Redux 团队

Mark Erikson 的 RTK 愿景旨在解决上述问题，并最终取得了成功。

在我看来，让 RTK 有价值的两大特性是 createSlice 和固执己见的 Style Guide。

切片是您在配置store时定义最终传递给 combineReducers 的功能状态的地方。

 

import { createSlice } from '@reduxjs/toolkit';

const initialState: {
  mode: 'light' | 'dark';
} = {
  mode: 'light',
};

export const themeSlice = createSlice({
  name: 'theme',
  initialState,
  reducers: {
    toggleThemeMode: (state) => {
      state.mode = state.mode === 'light' ? 'dark' : 'light';
    },
  },
});

export const { toggleThemeMode } = themeSlice.actions;
export default themeSlice.reducer;

但即使有了RTK，我仍然没有被卖掉。 这在很大程度上是因为在 RTK 发布前后，服务器状态工具也是如此。

服务器状态工具

2019 年，SWR 和 React Query 被引入 React 社区。 Vercel 创建的 SWR 和 Tanner Linsley 创建的 React Query 都解决了相同的问题：获取、缓存、同步和更新服务器状态。

服务器状态旨在保持服务器上的单一事实来源，可能会持久保存在数据库中，并消除维护和同步服务器派生状态与全局状态的需要。

由于将服务器状态抽象为查询工具时保留的全局状态很少，因此几乎没有理由使用 Redux。剩余的全局状态（如果有）可以通过上下文轻松管理。此时此刻，我强烈主张避免使用 Redux，支持使用 Server State 工具 + Context。

但随后 RTK 做出了回应。

RTK查询

2021 年 6 月，Redux Toolkit 添加了一个非常强大的工具，使 Redux 成为一个更可行的解决方案：RTK 查询。

与 SWR & React Query 类似，RTK Query 是一种管理服务器状态的数据获取和缓存工具。

使用 RTKQ 的一大好处是它可以与您的 Redux Store 集成。与 RTKQ 的每次交互都会调度一个 Redux Action。这允许所有 Redux Reducers 甚至 Redux DevTools 都可以看到每个交互。对于任何与 Redux 集成的工具（如 Sentry）来说，这都非常强大。

所以现在 RTK 有一个服务器状态解决方案，决定因素归结为您希望如何管理应用程序中剩余的全局状态。此时，您可以创建 Redux Slice，也可以使用 Context。两种解决方案的样板数量大致相同。然而，Redux 确实有一些好处。

 

• 首先是开箱即用的性能。如果您曾经阅读过任何关于 Context 的文章，您就会知道它作为状态管理解决方案通常不被鼓励。这是因为如果您没有正确使用 Context，很容易在您的应用中产生性能问题
• 。
• 第二个是拥有单个 Provider 的想法——而不是使用 Context，在这种情况下，每个功能都需要一个 Provider，所有这些都可以出现在组件树中的任何位置。

结论

我不敢相信我会这么说，但我现在喜欢 Redux。多亏了 Redux Toolkit 和新发布的 RTK Query，实现 Redux 实际上是非常愉快的，使用它你会收获很多，尤其是在企业环境中。

原文：https://engineering.udacity.com/react-state-management-in-2022-return-o…

本文：http://jiagoushi.pro/node/1615

你好，开发者。 如果您是初学者并且不知道您必须学习哪个前端框架，那么您来对地方了。 今天，我将告诉你 2022 年你可以学习的 5 大前端框架。

在软件行业，有很多前端框架，但我选择了 5 个框架来学习以记住未来的范围。

在开始之前，我们必须了解一些我将在本文中使用的定义 -

MVC架构——

模型-视图-控制器是一种软件设计模式，通常用于开发用户界面，将相关的程序逻辑划分为三个相互关联的元素。 这样做是为了将信息的内部表示与信息呈现给用户和被用户接受的方式分开。

— Wikipedia

 

Single Page Application （单页面应用)

单页应用程序是一个web应用程序或网站，它通过使用web服务器的新数据动态重写当前网页来与用户交互，而不是web浏览器加载整个新网页的默认方法。

— Wikipedia

Two-way data binding (双向绑定)

双向绑定为应用程序中的组件提供了共享数据的方法。使用双向绑定在父组件和子组件之间同时侦听事件和更新值。

— Angular Docs

TypeScript -

TypeScript是一种由Microsoft开发和维护的编程语言。它是JavaScript的严格语法超集，并向语言中添加可选的静态类型。TypeScript是为开发大型应用程序和JavaScript的跨组件而设计的。

— Wikipedia

让我们从“2022年要学习的五大前端框架”开始。

5. Backbone.js

它是最容易学习的框架之一。如果您是初学者，那么您可以很容易地学习这个框架。在骨干的帮助下。js，我们可以轻松构建单页应用程序。该框架还遵循MVC（模型、视图和控制器）体系结构。

Backbone.js 的优点和缺点:

• 它是最快的JavaScript框架之一，而且非常轻量级。
• 没有现成的结构可用， `create react app`。

4. Ember.js

Ember.js于2011年开发。它是一个基于组件的框架，支持双向数据绑定。它具有非常高效的体系结构。这是一个组织良好的框架。

Ember.js的利弊

• 它是一个非常快速、组织良好的JavaScript框架，具有良好的文档。
• Ember.js有一个小社区，语法理解起来很复杂，更新速度也很慢。

3. Vue.js

Vue.js是一个简单的基于组件的单页应用程序开发框架。它消除了Angular开发者面临的所有复杂性。你可以这么说vue.js是Angular和React的混合体（但这并不完全正确）。

Vue的优点和缺点。

• 它的两个主要优点是体积小、重量轻，并且还提供了可视DOM。它支持双向数据绑定。在Vue的帮助下，我们可以构建web应用程序、移动应用程序和PWA（渐进式web应用程序）。js。它还支持TypeScript（JavaScript的超集）。该框架还以优化应用程序性能而闻名。它还提供了设计应用程序结构的灵活性。
• 组件不稳定，它有一个较小的社区。

2. Angular

每当我们谈论前端框架时，我们都必须提到Angular。这是谷歌在2016年开发的一个非常著名的框架。它是一个完全基于类型脚本的框架，支持双向数据绑定。它的体系结构基于MVC，双向数据绑定提供了模型和视图之间更好的数据同步。

Angular的优点和缺点：

• Angular作为构建单页应用程序的框架很容易学习。借助它，我们可以构建web应用程序、移动应用程序和PWA应用程序。宝马、XBOX和Fobos等大公司都使用它。Angular拥有一个庞大而优秀的社区。
• 这是一个完全动态的解决方案，这意味着有许多解决方案可以完成一个简单的任务，从而产生一个较长的学习曲线。这就是为什么我把它放在这个列表的第二位。在非常大规模的应用中，我们有时可能会遇到优化问题。

1. React

如果你是初学者，想学习前端框架，我会推荐 React。 React 是 2022 年最流行的框架之一，也是最容易学习的框架之一。 React 由 Facebook 开发，现在是开源的。 React 支持虚拟 DOM 功能，这是所有前端框架中独一无二的。当你想要构建一个高流量的应用程序并且想要一个稳定的性能时，它会是最好的框架。

React 的优缺点：

 

• 它是基于组件的框架，我们可以通过它与团队协作，也可以重用组件。 React 提供了一个开发工具，我们可以通过它轻松调试和查找错误。
• React 以恒定的速度更新，这就是为什么它的文档不太好。如果您是初学者，您也可能会遇到一些问题。它使用一些人不理解的 JSX，并将其视为骗局。

感谢您阅读本文，不要忘记关注我以阅读更多此类文章。如果您觉得这个故事对您有帮助并认为对其他人也一样，您也可以与您的朋友分享这个故事。

原文：https://javascript.plainenglish.io/top-5-frontend-frameworks-to-learn-i…

本文：http://jiagoushi.pro/node/1610

当开始一个新的web开发项目时，许多开发人员都有一个问题:“什么工具是最合适的?”

显然，JavaScript是骨干，因为今天它提供了创建前端的广泛功能。但是人们在选择框架时面临着两难，因为JS中有很多框架，而且每个框架都有突出的特性。

通常，争论都是基于三个框架——Angular。js,反应。js和Vue.js。所以现在，我们将考虑它们的优缺点以及它们在开发者中的受欢迎程度。

开发人员的选择

Stackoverflow

首先，我们分析了主题调查，即JavaScript和Stackoverflow的状态。他们每年提供关于各种框架的流行程度和发展状况的最准确的信息。

Most popular web frameworks. Source of the image

尽管Vue.js发展迅速,该框架在评级中仅排名第七(在所有受访者和专业人士中)。React.js和Angular.js分别位居第二和第三。

值得注意的是，从总体结果来看，React.js赶上了第二的位置，而专业开发人员分别把angle .js放在了第二的位置。

Most loved frameworks. Source of the image

然而，开发人员喜欢使用React.js和Vue.js,，同时，Angular.js实际上是在列表的最后。React.js恰好是那些以前从未在这些框架的帮助下开发应用程序的人最希望学习的。紧随其后的是Vue.js和Angular.js。

NPMtrends

技术栈或框架的重要开发指标之一是下载的数量。NPM trends提供了每个工具最精确的统计数据，不仅包括下载数量，还包括Github的数据。

Downloads of Angular.js, React.js, and Vue.js. Source of the image

 

如您所见，React.js在这方面远远领先于它的竞争对手。与2018年相比，Angular.js的下载量减少了很多。从2019年年中开始，这一数字仍未突破100万大关。Vue.js的势头正在逐渐增强。具体来说，在2019年初，这个数字不超过500 thous。现在这个指标一直都在超过100万。

Frameworks rating on Github. Source of the image

这些指标反映了Stackoverflow的调查结果。Vue。js和反应。js的评分显著高于Angular.js。这就是下载的巨大差异的原因。

JavaScript的状态

这份年度报告是JavaScript和所有相关工具最重要的开发指标。

Frameworks rankings according to State of JavaScript 2019. Source of the image

开发人员主要满足于react.js和vue.js的工作过程。 Angular.js只有38%满足了他们的需求。同样，只有23%的开发人员对Angular有特殊的兴趣。与此同时，Vue.js和React.js的该指标分别为64%和61%。

Opinions on frameworks. Source of the image

关于框架的结果是相似的。大多数受访者要么对Angular.js不感兴趣，要么以前用过，但不想再用它工作了。React.js非常流行，大多数被调查者继续使用这个框架来解决他们的任务。

Stats of frameworks usage by company size. Source of the image

值得注意的是，相对较小的公司更喜欢React.js和Vue。而主要的开发人员(超过100名和1000名员工)更可能使用Angular.js。尽管如此，这些指标大致相等。

优点，缺点，特殊方面

现在让我们分别考虑每个框架:

• 在什么情况下，选择是不明显的?
• 为什么开发者更喜欢React.js?
• 使用每个框架时会遇到什么问题?

为什么React.js ?

React.js已经连续三年蝉联所有收视率第一。一些开发人员对这个框架毫无怨言，因为它发展迅速，而且越来越可持续。

React.js is the most used tool of JavaScript. Source of the image

事实上，值得注意的是，React.js不是一个框架，而是一个库。但是它具有广泛的功能，因此可以经常使用该工具，而不需要进行额外的集成。前端的效果不会因此而降低。

React.js是Facebook在2013年发布的，其目的是将用户界面划分为一组组件，以简化开发过程。

React.js是一个非常饱和的框架。在大多数情况下，开发人员对它只会说些恭维的话。

然而，Facebook最近发布了太多的更新，这使得一些工具过时了。许多开发人员喜欢这个过程。但在大多数情况下，社区抱怨这是因为他们必须不断掌握新技术。

值得注意的是，React.js专家在当今美国是最受欢迎的。2020年5月est. LinkedIn上活跃的query response .js有超过30000个职位空缺，实际上有4000个。

React.js受欢迎的一个关键原因是有信誉的公司Facebook的支持。Instagram、Whatsapp和Twitter等服务目前都在这个框架的基础上工作。他们都是非常快，有一个迷人的外表。这确保了对React.js的高度信任。

尽管有多个好处，只有少数情况下，当这个框架将是最合适的:

• 快速开发小型企业级应用;
• 创建SPA或跨平台应用程序;
• 扩展现有应用程序的功能。

这并不意味着React.js在其他情况下是坏的。这更像是选择性选择会更可取。

为什么Vue.js ?

Vue.js是近年来的一个发现。它突然从一个普通的框架变成了一个最受专业人士喜爱的框架。

The popularity of Vue.js over time. Source of the image

值得注意的是，它的普及是在没有大公司支持的情况下发展起来的。市场巨头们只是在Vue.js暴涨之后才开始关注它。这就是为什么它成为了React.js和angle .js长期对立的第三个框架。

Vue.js因为拥有大量的特殊方面而脱颖而出。有些甚至会出现缺点，例如，vue.js非常灵活。然而，在一个大团队中从事一个大项目的情况下，它可能会引发大量的错误。

在Vue.js开始展示其独特的特性后，许多市场巨头如Gitlab, WizzAir, EuroNews都关注了它。Grammarly完全是在Vue的基础上创建的，阿里巴巴和小米在2018年宣布完全过渡到Vue.js。

此外，这种框架在今天的亚洲市场需求很大。因此，更多的讨论和使用技巧都是中文的。你不懂那门语言?你必须把自己限制在用英语写文档和推荐。

尽管这个框架突然流行起来，但对开发人员的需求并没有增加到同样的程度。具体来说，LinkedIn上的Vue.js查询只有8000个职位空缺，实际上大约有4000个。

在什么情况下，vuei .js会是更好的选择?

• 开发“智能”和高性能应用程序;
• app的早期进入市场;
• 创建像Grammarly这样的小型轻量级应用程序。

为什么Angular.js ?

Angular.js 一直是开发用户界面的最佳选择。所以它成为了流行的stack MEAN的一部分。

Interest in Angular.js over time. Source of the image

尽管如此，在过去的几年里，开发人员一直在抱怨这个框架与竞争对手相比存在不足。因此，许多公司逐渐放弃使用Angular.js。

在很大程度上，由于新的web开发趋势的出现，这种框架失去了它的流行。Angular.js的团队没有在新版本的框架中实现所需的功能。这就是为什么我们看到Vue.js和React.js在今天变得越来越受欢迎的原因。如果超出了这三种框架的范围，那么Angular.js有时就不如其他工具(例如，Svelte)。

然而，Angular.js仍然被用来支持许多流行的网站和web应用程序。它们包括《卫报》、UpWork、PayPal和索尼。他们都是主要的网站，Angular.js证明了自己很好。

最有趣的是对Angular.js专家的需求。尽管受欢迎程度和估计的下降，需求实际上是在同一水平上的反应。js。具体来说，LinkedIn上有30000个职位空缺，Indeed上有超过5000个。

在什么情况下需要注意Angular.js?

• 创建大规模应用程序;
• 需要非常可伸缩的架构;
• 创建信使和其他应用程序«实时»;
• 使用TypeScript编写代码。

结论

根据统计数据、调查结果和各种报告，我们可以得出结论，2021年的最佳选择是React.js。第二名是Vue.js和Angular.js以较大的优势位居第三。

但是如果你从统计数据中抽象化，只考虑上下文的使用，那么就目前而言，没有最好的框架。无论如何，每种框架都有其优点和缺点，同样，每种框架都有很多的崇拜者和反对者。

选择权在你。

 

原文：https://merehead.com/blog/angular-vs-react-vs-vue-best-choice-2021/

本文：http://jiagoushi.pro/node/1267

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

 

大约一年前，开发人员主要讨论是否应该将Angular或React用于他们的项目。 但是在2018年的过程中，我们看到了对第三个名为Vue.js的玩家的兴趣增长。 期待2019年，这篇文章是一个全面的指南，也许是适合你的解决方案：Angular vs React vs Vue。

如果您是开发项目的开发人员而无法决定使用哪个JavaScript框架，那么本指南应该可以帮助您做出决定。

我们将介绍Angular，Vue和React的各个方面，以了解它们如何满足您的需求。 这篇文章不仅仅是Angular vs React vs Vue的指南，而是旨在提供一个结构来帮助判断前端JavaScript框架。 如果新框架明年到来，您将确切知道要查看的参数！

*在这篇文章中，我们假设您具有JavaScript的基本知识，并且也使用了JavaScript框架。

第1部分：Vue vs React与Angular的简史

在我们进入技术细节之前，让我们先谈谈这些框架背后的历史 - 只是为了更好地理解他们的哲学及其随时间的演变。

…

How it all started ?

 

由Google开发的Angular于2010年首次发布，使其成为最古老的。 它是基于TypeScript的JavaScript框架。 2016年Angular 2的发布发生了重大转变（以及原来名称中的“JS”的丢弃 -  AngularJS）。 Angular 2+被称为Angular。 虽然AngularJS（版本1）仍然有更新，但我们将重点讨论Angular。 最新的稳定版本是Angular 7，于2018年10月发布。

 

 

Vue，也称为Vue.js，是该组中最年轻的成员。 它是由前谷歌员工Evan You在2014年开发的。在过去两年中，Vue的受欢迎程度大幅下降，尽管它没有大公司的支持。 目前的稳定版本是2.17，于2018年8月发布.Vue的贡献者得到了Patreon的支持。 目前处于原型设计阶段的Vue 3计划转向TypeScript。

 

 

由Facebook开发的React最初于2013年发布.Facebook在其产品（Facebook，Instagram和WhatsApp）中广泛使用React。 目前在16.X的稳定版本，于2018年11月发布。

以下是Angular vs React vs Vue的简短摘要，包括它们的状态和历史：

Angular vs React vs Vue的历史

The history of Angular vs React vs Vue

	Angular	React	Vue
Initial release	2010	2013	2014
Official site	angular.io	reactjs.org	vuejs.org
Approx. size (KB)	500	100	80
Current version	7	16.6.3	2.17
Used by	Google, Wix	Facebook, Uber	Alibaba, GitLab

许可证?♂️

在使用开源框架之前，请确保通过其许可证。 有趣的是，所有三个框架都使用MIT许可证，即使在专有软件中，也会对重用提供有限的限制。 在使用任何框架或软件之前，请确保您了解许可证的含义。

以下简单的英文术语是MIT许可证的快速摘要。

...

人气?

由于“有角度”和“反应”是常用词，因此很难从Google趋势中了解它们的受欢迎程度。 虽然，他们受欢迎的一个很好的代表是他们的GitHub存储库获得的明星数量。 Vue的明星数量突然发生变化发生在2016年中期，最近，Vue一直在那里，React是最受欢迎的框架。

Angular，React和Vue的GitHub项目中的星数

让我们来看看Angular vs React vs Vue的就业市场情况，这也是衡量人气的一个很好的指标：

...

Angular vs React与Vue?♂️的就业市场

表明就业市场趋势的最佳数据来源是各种工作委员会。

从2018年末的趋势可以看出，需要Angular或React技能的工作数量大致相同，而Vue的工作数量仍然只是这个数字的一​​小部分（约20％）。这份清单绝对不是详尽无遗的，但可以很好地描述整个科技行业。

如果您从目前的就业市场的角度严格看待，最好的办法是学习Angular或React。但是，鉴于Vue在过去两年中越来越受欢迎，项目可能需要一些时间才能使用Vue，或者采用Vue的新项目达到成熟度级别，这些项目需要更多的开发人员。

第2部分：社区和发展

现在您已熟悉每个框架的历史和趋势，我们将查看社区以评估这些框架的开发。我们已经看到，对于所有框架，过去四个月都发布了一个主要版本，这表明开发正在全面展开。

让我们看看Angular vs React vs Vue关于GitHub存储库的统计信息：

	Angular	React	Vue
# Watchers	3.3k	3.7k	5.7k
# Stars	43k	71k	122k
# Forks	11k	16k	17k
# Commits in last month	446	339	81
# Contributors	798	1.8k	240

Vue拥有大量的观察者，明星和分叉。这表明它在用户中的受欢迎程度及其在比较Vue与React时的价值。但是，Vue的提交和贡献者数量低于Angular和React。

一种可能的解释是，Vue完全由开源社区驱动，而Angular和React在Google和Facebook员工中占有很大比例，为存储库做出了贡献。

从统计数据来看，这三个项目都显示出重要的开发活动，这在将来肯定会继续下去 - 只是这些统计数据不能成为不决定使用其中任何一项的基础。

第3部分：迁移

当您使用您选择的框架时，您不必担心框架更新会出现并弄乱您的代码。虽然在大多数情况下你不会遇到从一个版本到另一个版本的许多问题，但重要的是要注意脉冲，因为一些更新可能更重要，需要调整以保持兼容性。

Angular计划每六个月进行一次重大更新。在任何主要API被弃用之前还有六个月的时间段，这使您有两个发布周期（一年）的时间来进行必要的更改（如果有的话）。

谈到Angular vs React，Facebook表示稳定性对他们来说至关重要，因为像Twitter和Airbnb这样的大公司使用React。通过版本升级通常是React中最简单的，使用react-codemod等脚本可以帮助您进行迁移。

在迁移的FAQ部分中，Vue提到如果从1.x迁移到2，则90％的API都是相同的。有一个迁移帮助工具可以在控制台上运行，以评估应用程序的状态。

第4部分：使用Vue与Angular vs React

这里有一些重要的特征，主要是整体尺寸和加载时间，可用组件和学习曲线。

大小和加载时间⏲️

库的大小如下：

• Angular: 500+ KB
• React: 100 KB
• Vue: 80 KB

尽管框架的大小存在显着差异，但与平均网页大小（2018年的2 + MB）相比，它们仍然很小。此外，如果您使用流行的CDN加载这些库，则很可能用户已将库加载到其本地系统中。

...

组件?️

组件是所有三个框架的组成部分，无论我们是在谈论Vue，React还是Angular。组件通常获取输入，并根据它更改行为。此行为更改通常表现为页面某些部分的UI更改。组件的使用使得重用代码变得容易。组件可以是电子商务站点上的购物车或社交网络上的登录盒。

 Angular:

在Angular中，组件称为指令。指令只是DOM元素的标记，Angular也可以跟踪和附加特定的行为。因此，Angular将组件的UI部分分离为HTML标记的属性，以及它们以JavaScript代码形式的行为，这就是在查看Angular vs React时将其区分开来的原因。

 React:

有趣的是，React结合了UI和组件的行为。例如，下面是在React中创建hello world组件的代码。在React中，代码的相同部分负责创建UI元素并指示其行为。

 Vue:

在Vue中，UI和行为也是组件的一部分，这使得在查看Vue vs React时更加直观。此外，Vue是高度可定制的，它允许您在脚本中组合UI和组件的行为。此外，您还可以在Vue中使用预处理器而不是CSS，这是一项很棒的功能。在与其他库（如Bootstrap）集成时，Vue非常棒。

为了比较同一个应用程序在不同库中的外观，这里有一篇关于在React和Vue上创建相同的待办事项列表应用程序以及对比两个框架的差异的精彩帖子。

...

学习曲线?

那么学习这些框架有多难？

 Angular:

Angular有一个陡峭的学习曲线，考虑到它是一个完整的解决方案，掌握Angular需要你学习像TypeScript和MVC这样的相关概念。尽管学习Angular需要时间，但投资在理解前端如何运作方面会产生效益。

 React:

React提供了一个入门指南，可以帮助您在大约一小时内设置React。文档是彻底和完整的，可以解决StackOverflow上已经存在的常见问题。 React不是一个完整的框架，高级功能需要使用第三方库。这使得核心框架的学习曲线不那么陡峭，但取决于您使用其他功能所采用的路径。但是，学习使用React并不一定意味着您正在使用最佳实践。

 Vue:

Vue提供更高的可定制性，因此比Angular或React更容易学习。此外，Vue与Angular和React在功能方面有重叠，就像使用组件一样。因此，从两者中的任何一个过渡到Vue都是一个简单的选择。然而，Vue的简单性和灵活性是一把双刃剑 - 它允许糟糕的代码，使得调试和测试变得困难。

尽管Angular，React和Vue具有重要的学习曲线，但它们在掌握时的用途是无限的。例如，您可以将Angular和React与WordPress和WooCommerce集成，以创建渐进式Web应用程序。

 

Angular vs React vs Vue：谁赢了？

在这篇文章的最后，让我们回顾一下每个框架的特征，试图回答这个问题：Angular vs React vs Vue：你应该选择哪一个？

angular 是最成熟的框架，在贡献者方面有很好的支持，是一个完整的包。

然而，学习曲线陡峭，Angular的开发概念可能会推迟新的开发人员。

对于拥有大型团队和已经使用TypeScript的开发人员的公司而言，Angular是一个不错的选择。

额外?以下是您可能感兴趣的一些Angular管理信息中心模板。

 

 

React已经足够成熟并且拥有来自社区的大量贡献。它正在获得广泛认可。 React的就业市场非常好，这个框架的未来看起来很光明。

对于开始使用前端JavaScript框架，初创公司和喜欢灵活性的开发人员而言，React看起来是个不错的选择。与其他框架无缝集成的能力为那些希望在代码中具有一定灵活性的人提供了极大的优势。

 

vue 是竞技场的新手，没有大公司的支持。

然而，在过去的几年里，它作为Angular和React的强大竞争对手取得了很好的成绩。这可能是很多中国巨头如阿里巴巴和百度选择Vue作为他们的主要前端JavaScript框架。

但是，未来它的作用还有待观察，并且有理由谨慎对待它。如果您喜欢简单，也应该像灵活性一样，Vue应该是您的选择。

额外?以下是一些您可能感兴趣的使用Bootstrap构建的Vue管理模板。

 

Angular vs React vs Vue辩论的答案是，没有绝对正确的选择，你可能已经预料到了。

这些库中的每一个都有其自身的优点和缺点。根据您正在进行的项目以及您的个人要求，其中一项将比其他项目更合适。在决定之前进行自己的研究始终是关键，特别是如果你打算从事商业活动而不是个人项目。

 

原文：https://www.codeinwp.com/blog/angular-vs-vue-vs-react/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

2018年的Angular、React和Vue

不可否认的事实是，web开发和定制软件开发的虚拟世界在过去十年中一直处于蓬勃发展的技术进程中。说到前端，JavaScript一直在主导这一进程。

这种流行带来了大量的JavaScript框架。本指南的目的是深入了解两个如此广泛使用的框架——Angular和Vue——以及一个库——React。

这篇文章写起来很有挑战性，但是我们确信您在过去一定遇到过处理JavaScript框架的问题，而且很有可能，您一定对使用哪个框架感到困惑。

如果你在Angular、React和Vue之间犹豫不决，我们可以帮助你。

本指南分为以下部分-

• 1. 关于框架
• 2. 框架的重要性
• 3.框架的成熟度
• 4. 框架的未来
• 5. 社会质素
• 6. 基本的编程概念
• 7. 易于使用大型应用程序
• 8. 比较性能

好了，让我们切入正题，比较下面的三个。

1. 关于框架

Angular:

Angular是一个基于TypeScript的JavaScript框架，由谷歌开发和维护。其他使用Angular的知名公司有:Wix、Weather.com、Forbes等。

React:

React被称为“构建用户界面的JavaScript库”，是由Facebook开发和维护的。其他使用React的知名公司有:Uber、Twitter、Netflix、沃尔玛等。

Vue:

2014年由前谷歌员工Evan You开发并发布。使用Vue的知名公司有:阿里巴巴、任天堂、GitLab等。

虽然Angular和React已经成为大公司的热门产品，但Vue是一个独力的团队，由于它部署的模型-视图-视图-模型(MVVM)架构模式，它迅速蹿升到时尚的地位。

由于MVVM促进了开发过程中的图形用户界面与业务逻辑或分离结束逻辑的分离，因此Vue正迅速成为构建交互式web应用程序接口的首选语言。

这些框架的重要性

Angular:

• 简单和快速:MVC框架，能够执行复杂的任务和建立依赖之间的控制器和模板
• DOM有标记:在Angular中，标记直接定位在HTML记录中。这个流看起来是这样的:HTML → > DOM — ->> Engine
• 依赖处理:Angular在处理依赖方面非常出色。可以将应用程序隔离到独立的模块中，这些模块之间可能存在条件，也可能不存在条件。
• 简单易读的角模板,主要部署HTML标记👇👇👇。

React:

• 单向的:单向的数据流最终会使代码更加稳定。
• 虚拟DOM:虚拟Dom的存在有助于提高用户体验和开发速度。下一页中的代码片段。
• 开放源码:全世界的开发人员都为这个框架做出贡献。像批处理和修剪这样的特性已经成为了社区的贡献。
• React更好的开发速度👇👇👇

Vue

• 语法:Vue部署的语法应该是简洁流畅的。例如,@keyup.enter.preven = “do Stuff” 可以处理任何需要的事件。
• 学习曲线:在Vue项目中引入新的开发人员非常容易。使用单文件组件，学习曲线很平滑，可以很容易地检查代码库。
• Swift:开发者可以通过引用ring to快速浏览任何项目的存储关于模板、CSS、数据模型、生命周期钩子、映射的Vue提取、监视器等的.Vue文件。
• 声明式模板:简单的HTML模板，无需了解其他编程语言即可阅读。下一页中的代码片段。
• 可读的HTML模板，即使不了解其他语言👇👇👇

框架的成熟度

选择正确的框架是JavaScript项目成功的关键。在做决定时，重要的是要考虑系统是帮助了新元素的添加还是使其复杂化了。当我们谈到这些框架的成熟度时，可以通过GitHub社区的响应来衡量。以下是一些重要的数字，可以帮助你正确看待问题:

*编制时的统计资料

NPM Trends提供了以下图表，显示了在过去两年中，这些框架的NPM包的下载数量。

如果将Github明星绘制在图表上，就会出现一个有趣的趋势。

其他重要的因素

Angular

• 每6个月更新一次
• 每一版本的弃用期为6个月
• 从Angular 4开始的长期支持版本
• 简单的更新过程
• 捆绑提供的完整框架

React

• 稳定的API，如Facebook的设计原则所描述的那样
• 脚本可以从当前的API转移到新的API。例子——react-codemod
• 简单的迁移
• 平滑升级
• 稳定的主版本独立但快速移动的库

Vue

• 在小应用程序中在在版本升级的时候提供类似的API
• 协助升级migration-helper-tool
• 在迁移大型应用程序的版本时遇到的问题

很明显，Vue的人气一路飙升，已经超过了Angular，而且很快就会超过React。此外，这三个框架都在MIT许可下可用。虽然参与React开发的核心开发者的数量还没有正式公布，但是Angular在团队页面上列出了37个贡献者，Vue列出了22个核心开发者和14个社区合作伙伴。

要得出结论，Angular和React是成熟的框架，因为它们被大规模采用了。作为一个新兴的市场参与者，Vue虽然还处于发展阶段，但在知名度上已经处于领先地位。

框架的未来

前景:

为了更好地判断这些技术的发展方向，让我们来看看它们目前的状态。根据Stackoverflow 2017年的调查，JavaScript仍然是最受网络开发者欢迎的语言。

这也适用于其他提到的职业。

在JavaScript框架中，React被证明是66.9%的开发者的首选。相对而言，Angularjs的支持率较低，为51.7%。

感知和满意度:

另外，根据StateofJS前端框架调查，Vue的认知度只有94%，而Angular和React的认知度几乎是100%。但是说到满意度，使用过Angular 1的开发人员中有多达40%不打算再次使用它。这与React和Vue的读数形成鲜明对比。

因此，不可否认的事实是，随着开发人员在其他流行框架中寻找更多的支持，Angular的受欢迎程度正在迅速下降。另一方面，React似乎是目前这三家公司的市场领导者，赢得了社会的信任，前景光明。

但Vue也一样。考虑到它的新生状态，它已经获得了迅速的吸引力，就GitHub社区而言，它的受欢迎程度甚至接近于超过React。

从目前的发展趋势和数据来看，Angularjs的发展是非常受欢迎的，并将持续增长。React是目前的市场领导者，但Vue的牵引力和受欢迎程度将对其构成强烈挑战。

社区的质量

Angular

它拥有一个庞大的用户社区，仅上个月的下载量就在150万到200万之间。此外，GitHub上超级活跃的社区意味着你总会有人帮助你解决遇到的问题。可以探索一系列与不同版本的Angular兼容的解决方案，包括来自资深开发人员的建议。

React

仅过去一个月，它的下载量就达到了1000万次。React得到了Facebook、WhatsApp和Instagram等巨头的支持，也不缺少经验丰富的开发人员的帮助。和Angular一样，React too也吹嘘自己拥有一个令人印象深刻的GitHub社区，在那里人们随时准备伸出援助之手。尽管如此，值得注意的是，React建议使用JSX，它是使用XML语法扩展的JavaScript的修改版本。如果您以前没有使用过JSX，那么由于它的复杂性，这可能会在一开始就造成问题。所以要做好主动依赖社区帮助的准备。

Vue

Vue的社区被认为比React和Angular的社区小得多，因为它是最新的市场参与者。然而，一两年内情况可能会大不相同，因为Vue很可能最终成为最流行的JavaScript框架。

容易找到开发人员

在招聘和寻找合适的人才方面，情况发生了一些变化。

虽然它是开发人员的热门选择，但是如果您使用React，要找到一个有才华的开发人员并不容易，因为找到一个可以修改JSX的开发人员是一项挑战。然而，有一些外包软件开发公司专门从事Javascript和React开发

使用HTML模板被证明相对容易得多。

因此，如果你打算使用Angular或Vue，你可以选择雇佣那些能够快速学习这些框架的优秀HTML开发人员。直接找到一个有才华的Angular或Vue开发人员并不是什么大问题，因为学习曲线是从HTML衍生而来的，而HTML在市场上已经拥有了丰富的人才库。

如果你已经有了一个内部的开发团队，或者对面向对象的开发背景更感兴趣，那么Angular就是最合适的选择。

Angular、React和Vue的基本编程概念

语言:

每个框架使用不同的脚本语言。

• Angular使用了TypeScript。TypeScript是微软开发的一种流行的开源编程语言。它积极地涉及到一些关键的概念，比如静态类型，它提供了一些特定的功能，包括自动重构、跳转到定义等等。
• react将其重点放在了JavaScript ECMAScript 6 (ES 6)上，简单地说，这是JavaScript的一个版本。
• 类似地，Vue使用了JavaScript ES 5。

模板:

要选择正确的框架，您需要弄清楚您是想使用JSX还是HTML。

Angular和Vue都是基于标准的HTML模板和组件，它们简化了结构和代码重用。另一方面，对于新开发人员来说，JSX可能是一个巨大的问题。让我们看看每个-JSX的优点和缺点:

JSX优点缺点

• JSX在代码完成和编译时更好
• 由于打字错误引起的错误很容易被发现，因为React不会编译打字错误并打印打字错误所在的行号。
• React将HTML放到JavaScript中，这更好，因为JS总是更强大
• 因为它是JavaScript + XML + HTML的组合，所以对新开发人员来说是一个障碍
• 与HTML模板相比，具有复杂的特性
• UI模板和内联JavaScript逻辑之间没有界限

 

HTML优点缺点

• 将视图层与框架的其余部分区分开来
• 能够试验各种技术以获得最佳性能
• 视图的动态和静态部分的清晰分离
• 与JSX相比，调试过程更加困难
• 基于模板的方法，而不是组件

易于使用大型应用程序

各自框架的功能根据需要开发的应用程序的大小而不同。

许多开发人员认为Angular 3不适合处理大型复杂的应用程序。如果复杂性较低，那么它被证明是完美的，但是随着应用程序规模的扩大，问题开始增加。

例如，游戏应用程序通常很大，并且涉及到DOM操作。此外，在涉及太多数据绑定的应用程序中，如果表数超过2500,Angular 1就会变得很慢。

另一方面，如果你打算扩大这个应用程序的规模，React被证明是最好的选择。这一点得到了证实，Facebook、WhatsApp和Instagram都在使用React，而且它们都是全球范围内的大型应用程序。使用React可以轻松开发具有服务器端呈现的可维护架构。

开发人员还认为Vue在处理大型应用程序时很有帮助。框架在学习曲线上遵循了精益的方法，这马上就超过了Angular这样的框架的复杂性，后者常常被证明是新开发人员和大型应用程序开发人员难以接受的。

关于渲染速度和性能测试，为了更清晰，这里有一个图表列出了这三种性能基准测试。

比较性能

Parameter	Angular	React	Vue
Recommended Language	TypeScript	JS, JSX	JS, Vue
Architecture Flexibility	No	Yes	Yes
Logic Separation	Good	Good	Good
Rendering Speed	Slow	Fast	Fast
Most Known Architecture	MVC	Flux	Flux

---

Parameter	Angular	React	Vue
Server Side Rendering	Yes	Yes	Yes
CLI	Yes	Not Official	Yes
Debugging Tools	Yes	Yes	Yes
Testing	Jasmine and Karma	Developer’s Choice	Karma and Mocha, Jest
Data Library	No	No	No

---

Parameter	Angular	React	Vue
Mobile Build	Ionic	React-Native	Weex
Code Reusability	Yes	No, Only CSS	Yes, HTML and CSS
Size	143k	43k	23k
Code Stability	Yes	Yes	Yes
Bootstrap Integration	Yes	Yes	Yes

DIY -自我测试:

如果您想自己执行测试，可以使用以下相关命令:

Angular	React	Vue
$ npm install -g @angular/cli $ git clone https://github.com/mikpetr/angular -performance-test.git $ cd angular-performance-test $ npm install $ ng build -prod $ npm install -g http-server $ cd dist $ http-server	$ git clone https://github.com/mikpetr/r eact-performance-test.git cd react-performance-test npm install npm run dev Browse to http://localhost:8080	$ git clone https://github.com/mikpetr/v ue-performance-test.git $ cd vue-performance-test $ npm install $ npm run build $ cd dist $ npm install -g http-server $ http-server

 

由ITNext编译的这些测试的性能是在谷歌Chrome性能工具计算时间的帮助下进行的，时间从点击按钮开始，到渲染过程结束。这是测试结果*。

性能测试——Vue渲染时间1191ms

 

性能测试- Angular渲染时间931毫秒

 

性能测试-反应渲染时间1819毫秒

• Angular 5框架的大小相当臃肿。
• React和Vue具有虚拟dom，可以提高性能。
• Vue拥有最深的内存分配。

 

 

 

原文：https://www.cuelogic.com/blog/angular-vs-react-vs-vue-a-2018-comparison

本文：http://jiagoushi.pro/node/1273

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

不！我将通过直接评论Ceddy Muhoza最热门的回答来回答，但首先我会尽力阐明他真正想说的话，但是大多数开发者都不想承认自己：“我学会了React，现在停止了时间，让没有更好的技术让我的知识过时！“幸运的是，技术史证明了这种意见只是一个小小的挫折。恕我直言React很棒，比AngularJS（v1）好得多，但Angular 2+是前端开发的未来。它体现了软件开发的良好实践，它会像任何其他技术一样，在它变得过时时死亡，并且如果它的开发人员没有“反应”并继续前进，它将会在React之后。通过评论最受欢迎的答案，我将试着阐述为什么我认为这一点，事实，没有情感或偏好。

• “重新发明轮子，Angular v1和Angular v2是两种不同的巨大物种。”
  • 发明新的更好的做事方式并不是重新发明轮子。这叫做进步。恕我直言他们只犯了一个错误 - 根本称它为Angular。 v1和v2是不同的世界：v1是前端开发的过去，v2 +未来的开始。
• “将开发人员锁定在盒装解决方案中，2018年请让社区为您的框架添加自己的东西！”
  • 你只是在传播错误的信息。在这里你去： angular/angular。把自己弄出来。我相信你会添加大量有用的功能。任何人都可以公开发布Angular模块，任何人都可以将它们添加到项目中。那里有很多这样的模块。很高兴称它为框架。事实上，这是JS的第一个真正的框架，包括React在内的所有其他框架在技术上都只是库。
• “双向数据绑定是2013年的一个非常糟糕的错误，React帮助我们意识到了这一点！”
  • 误传。 Angular 2+没有内置的双向数据绑定。只有一个指令实现它，它是一个非常方便的功能，而不是一个bug。它就像魅力一样。这里有更多关于它的信息。
• “类型，装饰，以及反应性，可观察的状态管理，所有这些对于初学者来说非常困难！”
  • 我同意，也建立高级Web应用程序不适合初学者。如果您计划更改“初学者”状态，这些内容是您可能需要学习的内容。说实话并不难。如果需要几个小时才能理解的东西对你来说很难，你可能应该选择其他工作。它并不那么难，当你学习它时，你会发现这些东西有多强大，它们如何帮助你编写成熟的应用程序，以及它们如何帮助你的同事理解你实际写的东西。 Typescript使JS成为一种美观而严肃的编程语言。 RxJS（Observables）真棒。 Thinkster建议您查看RxJS的JavaScript代码，就像Henry Ford的汽车制造装配线一样。学习它，你会看到我在说什么。
• “Angular仍然试图让HTML变得更强大，你可以将HTML与JS进行比较吗？”
  • 比较他们的是你。苹果和橘子老兄。老实说，我不知道你的意思。
• “简单来说，React，Vue都致力于为JS提供动力，另一方面，Angular 2继续将”JS“放入HTML中。 React将“HTML”放入JS。“
  • 又一个错误的信息。您不会在Angular中将HTML放入HTML中。这让他们分开了。保持演示远离逻辑一直是一个很好的做法，不仅在前端，而且在软件开发中。 HTML没有任何问题，React也会让你知道。 Angular的模板系统也遵循在Blade和类似的不同模板引擎中证明的良好实践。它简单而有力。
• “你需要花几天时间来学习我们庞大的框架。”
  • 像你拥有的任何其他有用的知识一样，你必须获得它。不要害怕它，真的不是那么难。我个人花了更多时间来理解React。
• “我们记得谷歌吗？”
  • 我不知道这与你的观点有什么关系。在“Angular dying？”这个问题的背景下，这是一个巨大的争论，即当网络行业中最强大的公司支持时，它不会轻易死亡。不要忘记Angular应该与TS一起使用，TS是Microsoft的产品。我个人不太喜欢大公司，但质疑他们的工程权威只是一种无知。
• “很多人选择Angular是因为他们听说它是Google创建的工具，因此它必须是主要用于Google的前端应用程序框架？他们在这个假设中会错。事实上，Google信任Closure，用于您熟悉和喜爱的大多数应用程序，包括搜索，新闻，Gmail等。“
  • Angular 2于2016年9月14日发布。我认为，切换到谷歌生产应用程序的全新技术是一项庞大且极其昂贵的工作。
• “我们是谷歌，我们根本不放弃，所有开发者都已经信任我们了。”
  • 见8
• “战斗结束了：React赢了！”
  • 在技​​术开发中，战斗永远不会结束。但是，对于你作为那些2的用户而言，战斗本身是无关紧要的。知道这两者并做出明智的决定非常有用，而不是你在这里做的事情。有许多类型的项目，其中React更合适，反之亦然。
• “人们常常声称Angular对企业来说更好，这就是这个框架所谓的最佳点。但是，此声明并非由实际生产结果或历史本身支持。今天生产的Angular 2/4企业成果很少。“
  • 同样，Angular 2于2016年9月14日发布。当我们谈论社区和专家数量时，它是新技术并且仍然落后于React。由于Angular是自以为是，更严格，并且它实施了应用程序架构和开发的良好实践，因此对于大型项目，在团队工作，文档化，单元测试以及适当的类似测试，它实际上更加实用。在大型应用程序中，它甚至表现出比React更好的性能。
• “没有一些公司将大型代码库从React / Redux迁移到Angular 2/4并且看到生产力，可维护性或性能提升的例子。”
  • 只有当React正在死亡时，这种昂贵的操作才有意义，而且绝对不是。它仍然是非常稳定和强大的库。
• “在Google的制作中，Angular的使用率极低。谷歌的网站属性依赖于快速下载和执行，这是Angular没有发挥作用的东西。“
  • 同样，它是年轻的框架，我没有任何来自谷歌的内部信息，但我相信它正在被更多地使用，并且它们坚定地支持它。快速下载与JS框架应用程序的使用无关。 Angular的执行时间非常好，而且随着新的更新，它会变得更好。
• “我们是谷歌，所以！”
  • 他们是大恶的公司，不是，不是我的专业领域，不想进入政治，但谷歌为这个世界带来了许多革命性和有用的工具，而Facebook，React背后的公司，带来了真正的零实际价值这个世界，除了可能来自React本身。

结论，请学习React和Angular并做出明智的决定，不要让你的朋友/家人根据互联网上懒惰抱怨者的意见而错过伟大的事情，因为所有错误的理由和无知而讨厌东西。

 

原文：https://www.quora.com/Has-Angular-started-to-slowly-die

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

快速总结:-您曾经为优化应用程序的服务器通信而奋斗过吗?或者发现在应用程序中处理自动同步很困难?你来对地方了。作为顶级前端框架之一，Angular会主动处理这个问题。让我们来讨论一下Angular的一些关键好处和广泛应用的用例。

Angular和用例的13个主要好处

Angular从一开始就走过了漫长的道路。谷歌的Angular团队会随着浏览器的不断发展和支持不同功能的能力而不断升级框架。现在，它是开发功能丰富的web应用程序的首选选择之一。

它的用户界面和功能一次又一次地被一些公司和开发人员社区所认可。多亏了Angular的商业优势，仅在美国就有超过72,924个网站使用这个框架进行网站开发。

开发人员了解开发单页面应用程序(SPA)的主要挑战和缺点。虽然最初Angular开发的好处更多地是为了解决这个挑战，但它逐渐演变为解决一些问题，包括移动优化、渐进的web应用程序开发等等。

我们在Simform从事各种大大小小的项目。虽然有些人使用Angular，但很多人使用React，还有很多人在探索Vue。还有一些人仍然在使用jQuery。这篇文章是针对那些考虑将Angular和TypeScript作为前端工程选择的人。让我们更深入地探讨一下社会的优势和劣势，以帮助你更好地评估你的决定。

Angular对Web开发的好处

如果你想聪明地构建轻量级应用程序，Angular是你最好的选择。这个基于类型的框架使您能够创建干净、可维护和易于测试的交互式spa。

快速链接:

• 自动同步与双向数据绑定
• 优化服务器通信
• POJO模型以消除外部依赖
• Angular测试-一个完整的部分
• Angular材质-一个全面的现代UI
• Angular和单页面应用程序
• 代码一致性和健壮的生态系统
• 模型-视图-视图-模型(MMVC)体系结构来统一独立的结构
• 增强性能的下一代渲染器
• 活跃的社区和容易访问的信息
• 通过代码可重用性提高生产力
• 设计开发流程
• 易于使用的
• 什么时候使用Angular
• 什么时候不用Angular

 

自动同步与双向数据绑定

由于大多数框架都提供单向数据绑定，这个特性使Angular比其他框架更有优势。那么如何处理双向数据绑定呢?

它在模型和视图之间同步数据。因此，当数据被更改或修改时，这两个组件会自动更新。更重要的是，这是实时发生的，避免了开发人员将额外的精力投入到手工修改中。

其他的web框架通过脆弱的事件监听器和处理程序来实现双向数据绑定，与之不同的是，Angular让这个过程成为其体系结构中不可或缺的功能。因此，几乎不需要顺序回调来处理修改后的数据或开发人员干预。

优化服务器通信

使用Angular，缓存变得毫无问题!

Angular通过创建静态文件来减少cpu的额外负担。此外，框架中对API调用的响应时间非常快。

引用一个Angular应用程序，我们可以看到它在文档对象模型中呈现页面，以供用户操作使用。与其他技术栈不同，该框架仅通过生成静态应用程序页面来减少其工作量。它提供了一个全面快速的用户体验，并且不让用户等待，直到应用程序完全交互。

POJO模型以消除外部依赖

Angular使用了简单的旧Javascript对象(POJO)模型，使代码结构方便且独立。这样，我们就不用在程序中添加复杂的函数或方法了。此外，它消除了对外部框架或插件的依赖。

由于POJO需要的编码更少，用Angular加载构建的应用程序更快，并且提供了优秀的用户访问性，这个模型使我们能够保持代码的整洁，使框架面向目标。

Angular测试-一个完整的部分

测试是Angular框架不可分割的一部分。Angular中的所有JavaScript代码都需要经过一系列测试。在测试中提供的便利允许我们从头开始开发项目并无缝地测试组件。

多亏了Angular中的依赖注入。它管理所有的作用域和控制器。由于这种依赖关系，Angular中的单元测试功能可以通过向控制器中注入模拟/虚拟数据来强制依赖注入来执行测试。这个过程之后是对输出及其行为的评估。更有趣的是，Angular也有模拟HTTP提供者，可以将来自服务器的假响应推送到控制器中。

Angular材质-一个全面的现代UI

Angular材料遵循谷歌的材料设计指南。它提供了内置组件，如导航元素、布局、按钮、指示器和数据表。

此外，Angular Material不仅仅是创建一个赏心悦目的用户界面，它还开发了像谷歌这样的应用程序。例如，谷歌drive、Android OS、Gmail等应用已经成为用户的日常需求。

Angular和单页面应用程序

任何单页面应用程序的平稳运行有两个方面。一种方法是，当页面加载时，所有必需的JavaScript、CSS和HTML代码都在一个实例中检索。第二种是根据用户的行为和动作在需要时进行检索。

在用户浏览应用程序时，任何时候都不会重新加载页面，这涉及到与服务器之间的动态通信。然而，所有这些复杂性都可以很容易地由Angular处理。如果你的产品理念是围绕着开发一个彻底的单页应用程序，那么选择Angular来开发它将是你最好的选择。

代码一致性和健壮的生态系统

任何强大的开发环境要想成功，代码一致性是关键。多亏了Angular CLI和文档风格指南，它们都在先锋级别上推动了一致性。

Angular CLI工具可以让开发者创建初始项目，运行测试，并在同一个项目中添加不同的特性，同时让整个团队保持在同一个页面上。我发现开发人员经常感谢Angular提供的样式指南。通过这种方式，团队之间的交流变得舒适，并且不太可能被误解。

多亏了框架的健壮生态系统，它为开发人员社区提供了依赖注入和其他资源。

模型-视图-视图模型(MMVC)体系结构来统一独立的结构

Angular通过结合MMVC架构和双向数据绑定来简化开发结构。实际上，这个框架只需花很少的时间就可以更新视图层中对数据所做的更改，反之亦然。因此，这就是为什么大多数开发人员在构建大型应用程序时更青睐Angular。

由于框架将业务逻辑与UI组件隔离开来，开发人员更有信心设计出具有流畅业务逻辑的整洁用户界面。由于控制器在模型和视图组件之间建立了最快的通信。因此数据的显示会尽可能快。

提升性能的下一代渲染器

这个新的Angular引擎是关于它超优化的捆绑包大小、加载速度和组件的动态加载。

Ivy renderer的目标是无与伦比的代码调试和用户友好的应用程序体验。它使框架具有可访问性，并通过使框架成为一个功能丰富的平台来减少文件大小，从而设置了一个示例。由于它是在NG-CONF 2018中引入的，所以它并不是完整的，但目前，Angular 8发挥了它最好的作用。随着Angular 9的发布，现代的Angular引擎将呈现出完整的形式。

活跃的社区和易于获取的信息

从一开始，Angular就因其众多的优势而成为开发人员和工程师的最爱。有了学习资料、参考文档、常见问题解答等资源池，对于那些想要充分利用它的人来说，Angular很容易集成。

Angular可以加入的杰出社区:

• Dev.to提供了一个非常棒的社区
• Stackoverflow一直是开发者的最爱
• Twitter有很多Angular的支持句柄，但是你会发现这里this 的一切都是Angular提供的
• AngularAir 为最新更新和发言者
• 您可以订阅nng-newsletter 的更新，就在您的收件箱!

通过代码可重用性提高生产力

对于开发人员来说，在构建应用程序时不考虑文件大小过大的问题，还有什么比这更宝贵的呢?

有了Angular，开发人员可以投入更少的时间和精力，因为它可以重用代码，简化开发过程。它带来了更短的代码更多的功能，使它。对于背靠背进行类似项目的团队来说是高效的。

设计开发流程

有了这个优势，程序员在开发应用程序和添加标记时可以避免使用CSS/HTML标记，而不会破坏应用程序。在开发过程中，他们所要做的不是重新安排代码，而是在代码周围移动相应的元素。

易于使用的

Angular在编码方面的灵活性是其他框架无法比拟的，因为它的设计架构很简单。就灵活性而言，它允许初学者开始并无缝地修改他们的应用程序项目。此外，Angular可以很好地处理加载了大量特性和组件的web应用程序。开发人员还能要求什么?

所以，这些就是Angular的优势，到目前为止，我们相信你已经理解了Angular在满足web开发需求方面的潜力。

什么时候使用Angular

作为一个完整的软件堆栈，Angular是庞大的。它使开发人员能够用最简单的工作构建尽可能多的应用程序。让我们看看一些流行的用例:

视频流媒体应用，如Youtube PlayStation 3应用

任何喜欢玩视频游戏的人都不会错过ps3上的YouTube版本。考虑到YouTube的巨大人气，它需要一个框架

自从谷歌拥有了Angular，他们便利用它在PlayStation 3上发布了一个全新版本的Youtube。这个通用框架帮助谷歌重新设计了PS3体验，取代了传统的操作方式，成为一个彻底的现代操作方式。他们把鼠标移动换成了基本的按键。有了Angular的可访问性，就可以广泛地利用像Youtube PS3这样的本地应用的功能。

Angular在创建YouTube PS3上的平滑滚动和视频回放方面做出了更大的贡献。这是Angular提供的最新的超现代和精简的体验，玩家们都亲眼目睹了这一点。

电子商务应用，如T-Mobile

T-Mobile发现它的客户在连接到应用程序时必须等待内容加载。所以为了让它更快更少麻烦，他们使用了Angular来减少服务器端渲染的时间。

此外，他们还使用了Angular，以便能够将HTML解析用于搜索引擎的目的。他们还自动更新站点，无缝地实现了动态页面组成。

这家领先的电信企业在其电子商务应用上获得了巨大成功，其搜索引擎流量也非常可观。使用Angular，他们修改了应用程序的布局，并将其转换为一个运行流畅的应用程序。

实时数据应用，如weather.com

实时天气更新的热门网站之一是weather.com。Angular的成功要归功于它的多用途模块和目录功能，这些功能使它能够加载到桌面和智能手机设备上，利用这个小部件的特性。该框架允许开发人员根据设备的定制需求创建灵活的小部件。通过Angular技术获取实时数据并动态展示到互联网上。

用户生成内容门户网站——Upwork和纽约时报。

用户生成的网站需要高水平的安全和管理。Angular通过引入内部HTML来显示用户生成的内容，并内置一个杀毒软件DomSanitizer - DomSanitizer -作为一个安全特性，让事情变得简单起来。但是，当您使用带有内联样式的元素时可能会遇到麻烦，因为这样做会删除样式。

Angular支持用户生成内容网站需要处理的大技术问题。例如，用户原创内容网站Upwork和需要无限滚动的网站如纽约时报就是两个著名的例子，它们使用Angular作为后台来处理沉重的页面。这些网站看起来很容易获取和渲染在几秒钟内，而不会牺牲其单个页面应用程序的特性。

《卫报》等网站提供最新新闻和内容

《卫报》信息丰富，随时更新。感谢Angular技术栈为使用RxJS扩展设置了一个示例。它允许开发者创建无限滚动的搜索结果。守卫者所持有的巨量是另一个级别的，但它在角后端运行平稳。

什么时候不用Angular

Angular是超级英雄的，但仍然有一些地方使用Angular可能不会给你带来好处。

让我们看看它们是什么?

静态内容网站:

较小的目标和静态内容的小网站。这些类型的网站最好使用有限的技术堆栈，不需要使用Angular，因为这种技术只会增加额外的代码块，而这不是网站或特定项目所需要的。例如:登录页面、信息性网站、事件页面等。

有限的资源和初创企业:

对于小团队和有限的资源来说，Angular并不是一个好主意。Angular需要熟练的可用资源，以便在大型项目中快速解决问题。此外，该技术不应用于小型项目;它们可以使用其他可用的框架构建，不需要太多技术上的便利。

Microservices design选择了灵活的编码方式，允许您选择工具，而不考虑项目的不同模块。但是Angular是一个完整的解决方案，拥有所需的所有工具，因此不提供选择其他外部工具的灵活性。你需要携带所有项目不需要的东西。所以，如果你计划使用微服务设计架构，并且还想使用Angular，你应该迭代你的计划。

游戏应用程序和重型分析应用程序

Angular不适合游戏应用程序。其他框架，如React，可以用于在游戏中创建高度交互的UI。这是因为Angular会在每个文档对象模型改变位置之前检查它。

该框架不能很好地处理繁重和复杂的数学分析，比如游戏应用程序。尽管Linkedin、Upwork、Netflix都是用Angular构建的，但当涉及到数学处理过于复杂的问题时，不要选择Angular。

结论

我们的前端开发人员喜欢这个一直处于领先地位的框架，因为它维护了一致的代码结构、双向数据绑定、使用普通的旧javascript对象模型的代码可重用性。

Angular使开发人员能够编写结构简单的代码，而不需要第三方或外部支持。它通过更好地简化测试配置简化了代码的编写。

我已经试着解释了Simform的Angular团队给我们的所有理由，为什么他们会与这个框架紧密联系在一起。我很乐意参与您对不同前端框架的研究和分析。

 

原文：https://www.simform.com/key-benefits-angular-use-cases/

本文：http://jiagoushi.pro/node/1287

讨论：请加入知识星球【首席架构师智库】或者小号【jiagoushi_pro】或者QQ群【11107777】

 

原帖可以在Github上找到。未来的学习指南将在那里更新。如果你喜欢你正在阅读的东西，给它打一颗星吧!?

公司是东南亚(SEA)领先的运输平台，我们的使命是利用公司最新的技术和人才，推动SEA前进。截至2017年5月，我们每天处理230万次乘车，我们正在快速增长和招聘。

为了跟上Grab惊人的增长，我们的网络团队和网络平台也必须增长。幸运的是，或者不幸的是，在Grab上，web团队已经跟上了最新的最佳实践，并在我们的web应用程序中集成了现代JavaScript生态系统。

的结果是,我们的新员工或后端工程师,他们并不一定了解现代JavaScript的生态系统,可能会感到被接二连三的新事物,他们必须学习只是为了完成他们的特性或web应用程序的bug修复。前端开发从未像今天如此复杂和令人兴奋的。每隔一天就会出现新的工具、库、框架和插件，还有很多东西需要学习。必须引导web团队的新成员接受前端的这种演化，学会轻松地在生态系统中导航，并尽可能快地向用户交付代码。我们提出了一个学习指南，介绍我们为什么要做我们所做的，以及我们如何处理前端的规模。

本学习指南的灵感来自于“治愈JavaScript疲劳的学习计划”，在某种意义上，我们建议针对前端开发的每个方面学习特定的库/框架，这些库/框架基于当前认为最适合于Grab的内容。我们解释了为什么选择某个库/框架/工具，并提供了学习资源的链接，让读者能够自己学习。对于其他用例可能更好的备选方案也提供了参考和进一步的自我探索。

如果您的公司也在探索现代的JavaScript堆栈，那么您可能会发现本学习指南对您的公司也很有用!您可以根据自己的需要随意调整它。我们将根据最新的工作和选择，定期更新本学习指南。

-抓取Web团队

必备条件

• 理解核心编程概念。
• 熟悉基本的命令行操作，熟悉源代码版本控制系统，如Git。
• 有网络开发经验。使用Ruby on Rails、Django、Express等框架构建了服务器端呈现的web应用程序。
• 了解网络是如何工作的。熟悉web协议和约定，如HTTP和RESTful api。

表的内容

• 单页面应用程序(温泉)
• 新时代的JavaScript
• 用户界面
• 状态管理
• 编码与风格
• 可维护性
  • 测试
  • LintingJavaScript
  • LintingCSS
  • 类型
• 构建系统
• 包管理

某些主题可以跳过，如果你有之前的经验。

单页面应用程序(SPA)

如今，Web开发人员将他们开发的产品称为Web应用程序，而不是网站。虽然这两个术语之间没有严格的区别，但web应用程序往往是高度交互和动态的，允许用户执行操作并接收其操作的响应。传统上，浏览器从服务器接收HTML并呈现它。当用户导航到另一个URL时，需要刷新整个页面，服务器为新页面发送新的HTML。这称为服务器端呈现。

但是在现代的SPAs中，使用的是客户端呈现。浏览器从服务器加载初始页面，以及整个应用程序所需的脚本(框架、库、应用程序代码)和样式表。当用户导航到其他页面时，不会触发页面刷新。页面的URL通过HTML5 History API更新。新页面所需的新数据(通常为JSON格式)由浏览器通过对服务器的AJAX请求检索。然后，SPA通过JavaScript动态地更新页面，它在初始页面加载时已经下载了这些数据。这种模式与本地移动应用程序的工作方式类似。

好处:

1. 这款应用的响应速度更快，而且由于页面刷新，用户在页面导航之间看不到flash。
2. 服务器需要的HTTP请求更少，因为对于每个页面加载，不必再次下载相同的资产。
3. 清晰地分离客户端和服务器之间的关注点;您可以轻松地为不同的平台(如移动平台、聊天机器人、智能手表)构建新客户端，而无需修改服务器代码。您还可以独立地修改客户端和服务器上的技术堆栈，只要API契约没有被破坏。

缺点:

1. 由于加载多个页面所需的框架、应用程序代码和资产，初始页面加载较重。
2. 在您的服务器上还需要完成另一个步骤，即将其配置为将所有请求路由到单个入口点，并允许客户端路由从那里接管。
3. SPAs依赖于JavaScript来呈现内容，但并不是所有搜索引擎都在爬行期间执行JavaScript，它们可能会在您的页面上看到空的内容。这无意中损害了你的应用程序2的SEO。

虽然传统的服务器端呈现应用程序仍然是一个可行的选择，但清晰的客户机-服务器分离更适合大型工程团队，因为客户机和服务器代码可以独立开发和发布。当我们有多个客户端应用程序访问同一个API服务器时，这一点在Grab上尤其明显。

随着web开发人员现在构建的是应用程序而不是页面，组织客户端JavaScript变得越来越重要。在服务器端呈现的页面中，通常使用jQuery片段向每个页面添加用户交互性。然而，在构建大型应用程序时，jQuery是不够的。毕竟，jQuery主要是一个用于DOM操作的库，它不是一个框架，它没有为你的应用定义一个清晰的结构和组织。

JavaScript框架的创建是为了在DOM上提供更高层次的抽象，允许您将状态保存在内存中，而不是DOM中。使用框架还可以重用推荐的概念和构建应用程序的最佳实践。团队中有框架经验但没有应用程序经验的新工程师会发现更容易理解代码，因为代码是按照他熟悉的结构组织的。流行的框架有很多教程和指南，利用来自同事和社区的知识和经验可以帮助新工程师快速上手。

研究的链接

• 单页应用:优点和缺点
• (R)Evolution Web开发

新时代的JavaScript

在深入了解构建JavaScript web应用程序的各个方面之前，熟悉web语言—JavaScript或ECMAScript非常重要。JavaScript是一种非常通用的语言，您还可以使用它来构建web服务器、本地移动应用程序和桌面应用程序。

在2015年之前，最后一次主要更新是2011年的ECMAScript 5.1。然而，近年来，JavaScript在短时间内突然出现了巨大的改进。2015年，ECMAScript 2015(以前称为ECMAScript 6)发布了，并引入了大量的语法结构，以减少编写代码时的笨拙。Auth0编写了很好的JavaScript历史。到目前为止，并不是所有的浏览器都完全实现了ES2015规范。Babel等工具使开发人员能够在他们的应用程序中编写ES2015，而Babel将这些工具转换为ES5，以便与浏览器兼容。

熟悉ES5和ES2015是至关重要的。ES2015仍然相对较新，很多开源代码和Node.js应用程序仍然是用ES5编写的。如果在浏览器控制台中进行调试，则可能无法使用ES2015语法。另一方面，我们将在下面介绍的许多现代库的文档和示例代码都是用ES2015编写的。在Grab，我们使用ES2015(与Babel Stage-0预置一起)来支持JavaScript未来提供的语法改进，到目前为止我们一直很喜欢它。

花一两天时间复习ES5和探索ES2015。ES2015中使用较多的特性包括“箭头和词法This”、“类”、“模板字符串”、“析构”、“缺省/Rest/Spread操作符”和“导入和导出模块”。

预计持续时间:3-4天。您可以像学习其他库并尝试构建自己的应用程序一样学习/查找语法。

研究的链接

• Learn ES5 on Codecademy
• Learn ES2015 on Babel
• Free Code Camp
• ES6 Katas
• You Don’t Know JS (Advanced content, optional for beginners)

 

用户界面-React

如果最近几年有任何JavaScript项目在前端生态系统中掀起了一场风暴，那就是React。React是一个由Facebook的聪明人创建的开源库。在React中，开发人员为他们的web界面编写组件并将它们组合在一起。

React带来了许多激进的想法，并鼓励开发人员重新思考最佳实践。多年来，web开发人员一直被教导要分别编写HTML、JavaScript和CSS。React的做法正好相反，建议您用JavaScript编写HTML和CSS。这听起来像一个疯狂的想法，但经过尝试后，它实际上并不像听起来那么奇怪。作为前端开发场景的原因正在向基于组件的开发范式转变。React的特点:

• 说明性的——你描述你想在视图中看到什么，而不是如何实现它。在jQuery时代，开发人员必须想出一系列操作DOM的步骤，才能从一个应用程序状态切换到下一个应用程序状态。在React中，只需更改组件中的状态，视图就会根据状态更新自身。通过查看render()方法中的标记也很容易确定组件的外观。
• 功能-视图是一个纯粹的道具和状态的功能。在大多数情况下，React组件由支柱(外部参数)和状态(内部数据)定义。对于相同的道具和状态，会产生相同的视图。纯函数易于测试，功能组件也是如此。在React中进行测试很容易，因为组件的接口定义良好，可以通过向组件提供不同的道具和状态并比较呈现的输出来测试组件。
• 可维护性——以基于组件的方式编写视图可以促进可重用性。我们发现定义组件的proptype可以使React代码自文档化，因为读者可以清楚地知道使用组件需要什么。最后，您的视图和逻辑在组件中是自包含的，不应该受到影响，也不应该影响其他组件。这使得在大规模重构过程中很容易对组件进行移位，只要向组件提供相同的支持即可。
• 高性能——您可能听说过React使用虚拟DOM(不要与影子DOM混淆)，当状态发生变化时，它会重新呈现所有内容。为什么需要虚拟DOM?虽然现代JavaScript引擎速度很快，但从DOM读写却很慢。React在内存中保持DOM的轻量级虚拟表示。重新呈现一切是一个误导的术语。在React中，它实际上是指重新呈现DOM在内存中的表示，而不是实际的DOM本身。当组件的底层数据发生更改时，将创建一个新的虚拟表示，并与以前的表示进行比较。然后将差异(所需的最小更改集)打补丁到实际的浏览器DOM。
• 易学-学习反应很简单。与此相比，React API表面相对较小;只有几个api需要学习，而且它们不经常更改。React社区是最大的社区之一，随之而来的是充满活力的工具生态系统、开源的UI组件以及大量的在线资源，可以帮助你开始学习React。
• 开发人员经验—有许多工具可以改进React的开发经验。React Devtools是一个浏览器扩展，允许您检查组件、查看和操作其道具和状态。使用webpack热重载允许您在浏览器中查看代码更改，而不必刷新浏览器。前端开发包括大量的代码调整、保存和刷新浏览器。热重新加载帮助您消除最后一步。当有库更新时，Facebook提供codemod脚本来帮助您将代码迁移到新的api。这使得升级过程相对轻松。向Facebook团队致敬，感谢他们的奉献精神，使React的开发体验变得非常棒。

多年来，出现了比React性能更好的新视图库。React可能不是最快的库，但就生态系统、整体使用体验和好处而言，它仍然是最好的库之一。Facebook也在努力加快反应速度，重写了底层的和解算法。React引入的概念教会了我们如何编写更好的代码、更易于维护的web应用程序，并使我们成为更好的工程师。我们像这样。

我们建议在React主页上阅读关于构建井字游戏的教程，以了解React是什么以及它的功能。更多深入学习，请查看评价较高的免费课程，React Router的创建者提供的React基础知识，他们是React社区的专家。它还涵盖了React文档中没有涵盖的更高级的概念。Facebook的Create React应用程序是一个工具，可以用最少的配置搭建一个React项目，强烈推荐用于启动新的React项目。

React是一个库，而不是框架，它不处理视图下面的层——应用程序状态。稍后再详细介绍。

预计持续时间:3-4天。尝试建立简单的项目，如待办事项列表，黑客新闻克隆与纯反应。你会慢慢地对它产生好感，并可能在这个过程中遇到一些问题，而这些问题不是React能够解决的，这就引出了我们的下一个话题……

研究的链接

• React Official Tutorial
• React Fundamentals
• Simple React Development in 2017
• Presentational and Container Components

选择

• Angular
• Ember
• Vue
• Cycle

状态管理-Flux/Redux

随着应用程序越来越大，您可能会发现应用程序结构变得有点混乱。整个应用程序的组件可能不得不共享和显示公共数据，但没有优雅的方式来处理React。毕竟，React只是一个视图层，它并没有规定如何在传统MVC模式中构建应用程序的其他层，比如模型和控制器。为了解决这个问题，Facebook发明了Flux，这是一个应用架构，通过利用单向数据流来补充React的可组合视图组件。在这里阅读更多关于Flux的工作原理。综上所述，流量分布具有以下特点:

单向数据流-使应用程序更可预测的更新可以很容易地跟踪。

关注的分离——通量体系结构中的每个部分都有明确的职责，并且是高度解耦的。

在声明式编程中工作得很好——存储可以向视图发送更新，而不需要指定如何在状态之间转换视图。

由于Flux本身不是一个框架，开发人员已经尝试了很多Flux模式的实现。最终，一个明显的赢家出现了，那就是Redux。Redux结合了Flux、Command pattern和Elm体系结构的思想，是目前开发人员与React一起使用的事实上的状态管理库。其核心概念是:

应用程序状态由一个简单的旧JavaScript对象(POJO)描述。

发送一个操作(也是一个POJO)来修改状态。

减速器是一个纯函数，它采用当前状态和动作来产生一个新的状态。

这些概念听起来很简单，但是它们非常强大，因为它们使应用程序能够:

在服务器上呈现它们的状态，在客户端启动它们。

跟踪、记录和回溯整个应用程序中的更改。

轻松实现撤销/重做功能。

Redux的创建者Dan Abramov非常仔细地为Redux编写了详细的文档，并为学习基本和高级Redux创建了全面的视频教程。它们是非常有用的学习资源。

视图和状态的结合

虽然Redux不一定要与React一起使用，但强烈推荐使用Redux，因为它们彼此配合得很好。React和Redux有很多共同的想法和特点:

功能组合范式- React组合视图(纯函数)，而Redux组合纯还原剂(纯函数)。给定相同的输入集，输出是可预测的。

很容易推理——你可能听过这个词很多次，但它到底是什么意思呢?根据我们的经验，React和Redux简化了调试。由于数据流是单向的，因此更容易跟踪数据流(服务器响应、用户输入事件)，并且很容易确定问题发生在哪个层。

分层结构——app / Flux架构中的每一层都是纯功能，职责明确。为它们编写测试非常容易。

开发经验——在开发过程中，我们花了很多精力来创建工具来帮助调试和检查应用程序，比如Redux DevTools。

您的应用程序可能必须处理异步调用，如发出远程API请求。redx -thunk和redx -saga就是为了解决这些问题而创建的。它们可能需要一些时间来理解，因为它们需要理解函数式编程和生成器。我们的建议是，只有在你需要的时候才去处理它。

React - Redux是Redux的官方React绑定，非常简单易学。

预计时间:4天。egghead课程可能有点耗时，但值得花时间。在学习了Redux之后，您可以尝试将其合并到您已经构建的React项目中。Redux是否解决了您在pure React中遇到的一些状态管理问题?

Study Links

• Flux Homepage
• Redux Homepage
• Egghead Course - Getting Started with Redux
• Egghead Course - Build React Apps with Idiomatic Redux
• React Redux Links
• You Might Not Need Redux

Alternatives

• MobX

用样式- CSS模块编码

编写好的CSS是困难的。在能够编写可维护和可伸缩的CSS之前，需要多年的经验和挫败感来解决问题。具有全局名称空间的CSS基本上是为web文档设计的，而不是真正为偏爱组件体系结构的web应用程序设计的。因此，有经验的前端开发人员设计了一些方法来指导人们如何为复杂的项目编写有组织的CSS，比如使用SMACSS、BEM、SUIT CSS等。然而，这些方法所带来的样式的封装是由约定和指导方针强制执行的。一旦开发人员不遵循它们，它们就会中断。

幸运的是，前端的生态系统中充斥着各种工具，而不出意料的是，人们发明了一些工具来部分解决大规模编写CSS的一些问题。“大规模”意味着许多开发人员都在同一个项目中工作，并且使用相同的样式表。目前还没有社区同意用JS编写CSS的方法，我们希望有一天能像Redux一样在Flux实现中脱颖而出。现在，我们指望CSS模块。CSS模块是对现有CSS的改进，旨在解决CSS中全局命名空间的问题;它使您能够编写默认情况下是本地的并封装到组件中的样式。此功能通过工具实现。用CSS模块,可以编写大型团队的模块化和可重用的CSS,而不必担心冲突或覆盖应用程序的其他部分。然而,在一天结束的时候,仍在CSS模块编译成正常globally-namespaced CSS的浏览器识别,它仍然是重要的学习生的CSS。

如果你是一个完全的CSS初学者，Codecademy的HTML和CSS课程将是一个很好的介绍你。接下来，阅读Sass预处理器，这是CSS语言的扩展，增加了语法改进，并鼓励了样式的可重用性。学习上面提到的CSS方法，最后学习CSS模块。

预计持续时间:3-4天。尝试使用SMACSS/BEM方法和/或CSS模块设计应用程序的样式。

Study Links

• Learn HTML & CSS course on Codecademy
• Intro to HTML/CSS on Khan Academy
• SMACSS
• BEM
• SUIT CSS
• CSS Modules Specification
• Sass Homepage
• A pattern for writing CSS to scale

Alternatives

• JSS
• Styled Components

可维护性

读代码比写代码更频繁。在Grab尤其如此，在那里团队规模很大，我们有多个工程师在多个项目中工作。我们高度重视代码的可读性、可维护性和稳定性，有几种方法可以实现这一点:“广泛的测试”、“一致的编码风格”和“类型划分”。

测试- - Jest + Enzyme

Jest是Facebook的一个测试库，旨在让测试过程无痛苦。与Facebook项目一样，它提供了一种开箱即用的良好开发体验。测试可以并行运行以获得更快的速度，并且在监视模式下，只运行更改文件的测试。我们喜欢的一个特性是“快照测试”。Jest可以保存React组件和Redux状态生成的输出，并将其保存为序列化文件，这样您就不必自己手动生成预期的输出。Jest还具有内置的模拟、断言和测试覆盖率。一个图书馆来统治他们所有人!

React附带了一些测试工具，但是通过类似于jquery的API，通过Airbnb提供的酶可以更容易地生成、断言、操作和遍历React组件的输出。建议用酶测定反应组分。

Jest和酶使编写前端测试变得有趣和容易。因为定义了明确的职责和接口，所以React组件和Redux操作/缩减器相对容易测试也很有帮助。对于React组件，我们可以测试给定一些道具，呈现所需的DOM，并在某些模拟用户交互时触发回调。对于Redux还原器，我们可以测试给定的一个先验状态和一个动作，会产生一个结果状态。

Jest和ase的文档非常简洁，通过阅读它们应该就足够了。

预计持续时间:2-3天。尝试为你的React + Redux应用程序编写Jest +Enzyme!

Study Links

• Jest Homepage
• Testing React Apps with Jest
• Enzyme Homepage
• Enzyme: JavaScript Testing utilities for React

Alternatives

• AVA
• Karma

Linting JavaScript - ESLint

linter是一个静态分析代码并发现代码问题的工具，它可以潜在地防止bug /运行时错误，同时强制执行一种编码风格。在拉请求审查期间，当审查人员不必对编码风格留下挑剔的评论时，可以节省时间。ESLint是一个用于linting JavaScript代码的工具，具有高度可扩展性和可定制性。团队可以编写自己的lint规则来执行自定义样式。在Grab中，我们使用Airbnb的eslin -config- Airbnb预置，它已经在Airbnb的JavaScript风格指南中配置了通用的良好编码风格。

在大多数情况下，使用ESLint就像调整项目文件夹中的配置文件一样简单。如果您不为ESLint编写新的规则，那么就没有什么可学习的。当错误出现时，请注意它们，并将其谷歌，以找到推荐的样式。

预计持续时间:1/2天。没什么可学的。添加ESLint到您的项目，并修复linting错误!

Study Links

• ESLint Homepage
• Airbnb JavaScript Style Guide

Alternatives

• Standard
• JSHint

Linting CSS - stylelint

正如前面提到的，好的CSS是出了名的难写。在CSS上使用静态分析工具有助于保持我们的CSS代码质量和编码风格。对于linting CSS，我们使用stylelint。与ESLint一样，stylelint以一种非常模块化的方式设计，允许开发人员打开/关闭规则并为其编写自定义插件。除了CSS之外，stylelint还能够解析SCSS，并且对Less提供了实验支持，这降低了大多数现有代码库采用它的障碍。

一旦你学会了ESLint，考虑到他们的相似之处，学习stylelint将是毫不费力的。手写笔目前被Facebook、GitHub和Wordpress等大公司使用。

手写笔的一个缺点是，自动修复功能还没有完全成熟，只能修复有限数量的规则。然而，这个问题应该随着时间的推移而改善。

预计持续时间:1/2天。没什么可学的。将stylelint添加到项目中并修复linting错误!

Study Links

• stylelint Homepage
• Lint your CSS with stylelint

Alternatives

• Sass Lint
• CSS Lint

Types - Flow

静态类型在编写应用程序时带来了许多好处。它们可以在早期捕获代码中的常见bug和错误。类型还可以作为代码文档的一种形式，提高代码的可读性。随着代码库的增长，我们看到了类型的重要性，因为它们在我们进行重构时给了我们更大的信心。当清楚每个对象持有什么类型的值和每个函数期望什么时，将团队的新成员加入到项目中也更容易。

向代码中添加类型需要在增加冗长性和语法学习曲线之间进行权衡。但这种学习成本是预先支付的，并随着时间的推移摊销。在复杂的项目中，代码的可维护性很重要，并且处理代码的人员会随着时间的推移而变化，向代码中添加类型带来的好处要多于坏处。

向JavaScript添加静态类型的两大竞争者是Flow (Facebook)和TypeScript(微软)。到目前为止，还没有明确的赢家。现在，我们已经做出了使用流的选择。我们发现与TypeScript相比，Flow的学习曲线更低，并且将现有的代码库迁移到Flow所需的工作相对较少。Flow由Facebook打造，与React生态系统的整合性更好。无论如何，从Flow转移到TypeScript并不十分困难，因为语法和语义非常相似，我们将在以后重新评估这种情况。毕竟，使用一个总比不使用强。

Flow最近更新了他们的文档站点，现在已经很整洁了!

预计持续时间:1天。流非常容易学习，因为类型注释感觉像是JavaScript语言的自然扩展。向您的项目中添加流注释，并利用类型系统的强大功能。

Study Links

• Flow Homepage
• TypeScript vs Flow

Alternatives

• TypeScript

Build System - webpack

这一部分将会很简短，因为设置webpack可能是一个冗长乏味的过程，而且可能会让那些已经被前端开发中需要学习的大量新内容压得喘不过气来的开发人员感到厌烦。简单地说，webpack是一个模块绑定器，它将前端项目及其依赖项编译成一个最终的包，然后提供给用户。通常，项目已经设置了webpack配置，开发人员很少需要更改它。从长远来看，理解webpack仍然是一件好事。这是由于webpack的功能，如热重载和CSS模块是可能的。

我们发现由生存js的webpack演练是学习webpack的最佳资源。这是对官方文档的一个很好的补充，我们建议先进行演练，然后在需要进一步定制时参考文档。

预计持续时间:2天(可选)。

Study Links

• webpack Homepage
• SurviveJS - Webpack: From apprentice to master

Alternatives

• Rollup
• Browserify

Package Management - Yarn

 

如果您查看一下node_modules目录，您会对其中包含的目录数量感到震惊。每个babel插件lodash函数都是一个独立的包。当您有多个项目时，这些包在每个项目中都是重复的，它们在很大程度上是相似的。每次在新项目中运行npm安装时，这些包都会被一次又一次地下载，即使它们已经存在于计算机中的其他项目中。

在通过npm安装安装的包中也存在不确定性的问题。我们的一些CI构建会失败，因为在CI服务器安装依赖项时，它会对一些包含中断更改的包进行小的更新。如果库作者尊重semver，而工程师假设API契约一直受到尊重，就不会出现这种情况。

纱线解决了这些问题。通过纱线安装包的不确定性问题。锁定文件，并确保在所有机器上的node_modules中，每个安装都得到完全相同的文件结构。纱线在您的计算机中使用了一个全局缓存目录，以前下载过的包不必重新下载。这也支持离线安装依赖项!

最常见的纱线命令可以在这里找到。大多数其他的纱线命令类似于npm，可以使用npm版本。我们最喜欢的命令之一是纱线升级-交互式，这使得更新依赖项变得非常容易，特别是在现代JavaScript项目需要如此多的依赖项的时候。一定要去看看!

npm@5.0.0于2017年5月发布，它似乎解决了纱线想要解决的许多问题。一定要注意!

预计持续时间:2小时。

Study Links

• Yarn Homepage
• Yarn: A new package manager for JavaScript

Alternatives

• Good old npm

旅程才刚刚开始

祝贺你走到这一步!今天的前端开发是困难的，但它也比以前更有趣。到目前为止，我们所介绍的内容将帮助任何新工程师快速掌握我们的技术。还有更多的东西需要学习，但是在本质上建立一个坚实的基础将有助于学习其余的技术。这个有用的前端web开发人员路线图显示了各个方面可用的替代技术。

我们的技术决策是基于快速成长的Grab工程团队所看重的——前端代码库的可维护性和稳定性。这些决策可能适用于较小的团队和项目，也可能不适用于较小的团队和项目。评估什么对你和你的公司最有效。

随着前端生态系统的发展，我们正在积极探索、试验和评估新技术如何使我们成为一个更高效的团队，并提高我们的生产力。我们希望这篇文章能让你了解我们在Grab使用的前端技术。如果你对我们正在做的事情感兴趣，我们正在招聘!

感谢Joel Low, Li Kai和Tan Wei Seng审阅了本文的草稿。

原帖可以在GitHub上找到。未来的学习指南将在那里更新。如果你喜欢你正在阅读的东西，给它打一颗星吧!?

More Reading

General

• State of the JavaScript Landscape: A Map for Newcomers
• The Hitchhiker’s guide to the modern front end development workflow
• How it feels to learn JavaScript in 2016
• Roadmap to becoming a web developer in 2017
• Modern JavaScript for Ancient Web Developers

Other Study Guides

• A Study Plan To Cure JavaScript Fatigue
• JS Stack from Scratch
• A Beginner’s JavaScript Study Plan

Footnotes

1. This can be solved via webpack code splitting. ↩

2. Universal JS to the rescue! ↩

 

原文：https://engineering.grab.com/grabs-front-end-study-guide

本文：https://pub.intelligentx.net/node/804

讨论：请加入知识星球或者小红圈【首席架构师圈】

在web开发中，mashup(计算机行业术语)是一个web页面或web应用程序，它使用来自多个源的内容来创建单个新服务，并显示在单个图形界面中。例如，用户可以将其图书馆分支的地址和照片与谷歌映射相结合，以创建地图mashup。这个术语意味着简单、快速的集成，经常使用开放的应用程序编程接口(open API)和数据源来产生丰富的结果，而这些结果不一定是产生原始数据源数据的原始原因。mashup这个术语最初来自于英西印度群岛的俚语，意思是喝醉了，或者描述某人或某事没有达到预期的功能。在最近的英语中，它可以指音乐，人们无缝地将一首歌曲的音频和另一首歌曲的音轨结合在一起，从而创造出新的东西。

mashup的主要特征是组合、可视化和聚合。使现有数据对个人和专业使用更有用是很重要的。为了能够永久地访问其他服务的数据，mashup通常是客户端应用程序或在线托管。

在过去的几年里[什么时候?，越来越多的Web应用程序已经发布了api，这些api使软件开发人员能够以SOA的方式轻松地集成数据和功能，而不是自己构建它们。可以认为mashup在社交软件和Web 2.0的发展中扮演着积极的角色。Mashup组合工具通常非常简单，可供最终用户使用。它们通常不需要编程技能，而是支持GUI小部件、服务和组件的可视化连接。因此，这些工具为Web的新愿景做出了贡献，用户可以在其中做出贡献。(需要澄清)

术语“mashup”并不是由任何标准设置机构正式定义的.

历史

Web历史的更广泛背景为mashup的开发提供了一个背景。在Web 1.0模型下，组织将消费者数据存储在门户网站上，并定期更新它们。他们控制了所有的消费者数据，消费者必须使用他们的产品和服务来获取信息。[引文需要]

Web 2.0的出现引入了一些Web标准，这些标准在传统的竞争对手之间得到了普遍和广泛的采用，从而打开了消费者数据。与此同时，mashup出现了，允许混合和匹配竞争对手的api来开发新服务。

第一个mashup使用映射服务或照片服务将这些服务与任何类型的数据组合起来，从而产生数据的可视化。最初，大多数mashup是基于消费者的，但最近[什么时候?混搭将会被谁看到?这是一个有趣的概念，对企业也很有用。业务mashup可以将现有的内部数据与外部服务组合起来，以生成关于数据的新视图。

混搭的类型

mashup有许多类型，比如业务mashup、消费者mashup和数据mashup。最常见的mashup类型是面向普通大众的消费者mashup。

业务(或企业)mashup定义将其自身的资源、应用程序和数据与其他外部Web服务组合在一起的应用程序。他们将数据集中在一个单一的演示中，并允许企业和开发人员之间的协作行动。这对于敏捷开发项目非常有效，因为敏捷开发项目需要开发人员和客户(或客户代理，通常是产品经理)之间的协作来定义和实现业务需求。企业mashup是安全的、视觉上丰富的Web应用程序，它公开来自不同内部和外部信息源的可操作信息。

使用者mashup在浏览器中组合来自多个公共源的数据，并通过一个简单的浏览器用户界面对其进行组织。[5](例如:Wikipediavision结合了谷歌地图和Wikipedia API)

与消费者mashup相反，数据mashup将类似类型的媒体和来自多个源的信息组合成单一表示。所有这些资源的组合创建了一个新的、独特的Web服务，它最初不是由任何一个源提供的。

通过API类型

mashup也可以根据它们使用的基本API类型进行分类，但其中任何一种都可以相互组合或嵌入到其他应用程序中。

数据类型

• 元搜索引擎使用的索引数据(文档、网络日志、图像、视频、购物文章、工作……)
• 制图和地理数据:地理定位软件，地理可视化
• 提要、播客:新闻聚合器

功能

• 数据转换器:语言翻译，语音处理，网址缩短器…
• 沟通:电子邮件，即时消息，通知…
• 可视化数据绘制:信息可视化，图表
• 安全相关:电子支付系统，身份识别…
• 编辑器

Mashup的推动者

在技术领域，mashup enabler是一种工具，用于将不兼容的IT资源转换为可以轻松组合的形式，从而创建mashup。Mashup使能者允许使用强大的技术和工具(例如Mashup平台)来将数据和服务组合到新的资源类型中。mashup启用程序的一个示例是一个从电子表格(不能轻松用于创建mashup)创建RSS提要的工具。许多mashup编辑器包括mashup推动者，例如Presto mashup连接器、Convertigo Web Integrator或Caspio Bridge。

Mashup推动者也被描述为“使Mashup成为可能的服务和工具提供者”。[引文需要]

历史

早期的mashup是由热情的程序员手工开发的。然而，随着mashup变得越来越流行，公司开始创建用于构建mashup的平台，这些平台允许设计人员通过连接mashup组件来可视化地构建mashup。

Mashup编辑器极大地简化了Mashup的创建，极大地提高了Mashup开发人员的工作效率，甚至向最终用户和非it专家开放了Mashup开发。标准组件和连接器使设计人员能够轻松地以各种复杂的方式组合mashup资源。然而，Mashup平台在扩展Mashup可以访问的资源范围方面做得很少，而且还没有将Mashup从对结构化数据和开放库(RSS提要和公共api)的依赖中解放出来。

Mashup启用程序不断发展，以解决这个问题，提供了将其他类型的数据和服务转换成mashable资源的能力。

Web资源

当然，并不是所有有价值的数据都位于组织内部。事实上，对于业务智能和决策支持最有价值的信息通常来自组织外部。随着富internet应用程序和在线Web门户的出现，越来越多的业务关键流程(例如订购)可以在线使用。不幸的是，这些数据源很少以RSS格式聚合内容，而且很少有这些服务提供可公开访问的api。因此，Mashup编辑器通过提供启用程序或连接器来解决这个问题。

数据集成的挑战

在集成来自不同来源的数据时，有许多挑战需要解决。这些挑战可以分为四组:文本/数据不匹配、对象标识符和模式不匹配、抽象级别不匹配、数据准确性

文本数据不匹配

大部分数据是用文本来描述的。人类的语言常常是含糊不清的——同一家公司可能在几个变体中被提及(例如IBM、国际商业机器公司和蓝色巨人)。这种模糊性使得与结构化数据的交叉链接变得困难。此外，用人类语言表达的数据很难通过软件程序来处理。数据集成系统的功能之一是克服文档与数据之间的不匹配

对象标识和独立的模式

结构化数据有各种各样的格式。因此，将数据提升到公共数据格式是第一步。但是，即使所有数据都以一种通用的格式提供，但在实践中，数据源在如何表述本质上相同的事实方面是不同的。这种差异存在于单独的对象级别和模式级别。作为对象级别不匹配的一个示例，请考虑以下内容:SEC使用所谓的中央索引键(Central Index Key, CIK)来识别人员(ceo、cfo)、公司和金融工具，而其他来源(如DBpedia (Wikipedia的结构化数据版本))使用uri来识别实体。此外，每个源通常使用自己的模式和特性来说明本质上相同的事实。因此，必须使用方法来协调对象和模式的不同表示。

抽象级别

数据源提供不兼容的抽象级别的数据，或者根据与某个扇区相关的分类法对其数据进行分类。由于数据是在不同的抽象层次(如个人、公司、国家或部门)发布的，为个人观点而聚合的数据可能与来自统计部门的数据不匹配。此外，在地理汇总方面也存在差异(例如，来自一个来源的区域数据和来自另一个来源的国家一级数据)。一个相关的问题是使用当地货币(美元对欧元)，为了使来自不同来源的数据具有可比性并便于分析，必须对这些货币进行协调。

数据质量

在自动集成来自自治数据源的数据时，数据质量是一个普遍的挑战。在开放环境中，数据聚合器对数据发布服务器几乎没有影响。数据常常是错误的，并且组合数据常常会加重问题。特别是在执行推理(从现有数据自动推断新数据)时，错误的数据可能会对结果数据集的整体质量造成毁灭性的影响。因此，一个挑战是数据发布者如何协调以修复数据或黑名单站点中无法提供可靠数据的问题。需要的方法和技术:检查完整性和准确性;突出、鉴定和确证证据;评估一个给定命题为真的概率;等同市场部门或公司之间的权重差异;设立清算所，以提出和解决相互竞争(可能相互冲突)的数据提供者之间的争端;并与可能来源和质量可疑的混乱的错误Web数据交互。总之，标识、数量、标记和分类中的错误会严重妨碍系统对这些数据进行操作。

Mashup和门户网站

mashup和门户都是内容聚合技术。门户是一种较老的技术，被设计为对传统动态Web应用程序的扩展，其中将数据内容转换为标记的Web页面的过程分为两个阶段:生成标记“片段”和将片段聚合为页面。每个标记片段由一个“portlet”生成，门户将它们组合成单个Web页面。portlet可以本地托管在门户服务器上，也可以远程托管在单独的服务器上。

门户技术定义了一个完整的事件模型，包括读取和更新。在门户上对聚合页面的请求被转换为构成页面的所有portlet上的单个读取操作(本地的“呈现”操作、JSR 168 portlet或远程的“getMarkup”操作、WSRP portlet)。如果在门户页面上的任何portlet上按下了submit按钮，那么它将被单独转换为该portlet上的更新操作(本地portlet上的processAction或远程WSRP portlet上的performBlockingInteraction)。更新之后立即对页面上的所有portlet执行读操作。

门户技术是关于服务器端表示层聚合的。它不能用于驱动更健壮的应用程序集成形式，比如两阶段提交。

mashup与门户在以下方面有所不同:

	Portal	Mashup
分类	较老的技术，使用定义良好的方法对传统Web服务器模型的扩展	使用更新的、定义松散的“Web 2.0”技术
哲学/方法	通过将Web服务器的角色划分为标记生成和标记片段聚合两个阶段来实现聚合	使用不同内容站点提供的api以另一种方式聚合和重用内容
内容相关性	聚合面向表示的标记片段(HTML、WML、VoiceXML等)	可以操作纯XML内容，也可以操作面向表示的内容(如HTML)
位置的依赖关系	传统上，内容聚合是在服务器上进行的	内容聚合可以在服务器上进行，也可以在客户机上进行
聚合的风格	“沙拉吧”风格:聚合的内容“并排”显示，没有重叠	“大熔炉”风格-个别内容可以以任何方式组合，导致任意结构的混合内容
事件模型	读取和更新事件模型是通过特定的portlet API定义的	CRUD操作基于REST架构原则，但是不存在正式的API
相关标准	Portlet行为由标准JSR 168、JSR 286和WSRP控制，尽管门户页面布局和门户功能是未定义的，并且是特定于供应商的	基本标准是作为REST或Web服务交换的XML。RSS和Atom是常用的。更具体的mashup标准(如EMML)正在出现。

 

门户模式存在的时间更长，并且有更大的投资和产品研究。因此，门户技术更加标准化和成熟。随着时间的推移，mashup技术的日益成熟和标准化可能会使它比门户技术更受欢迎，因为它与Web 2.0和最近的面向服务的体系结构(SOA)联系得更紧密。预计[7]新版本的门户产品最终将添加mashup支持，同时仍然支持遗留portlet应用程序。相比之下，Mashup技术预计不会提供对门户标准的支持。

业务mashup

Mashup在业务环境中的使用正在扩展。业务mashup对于集成业务和数据服务非常有用，因为业务mashup技术提供了快速开发新集成服务的能力，可以将内部服务与外部或个性化信息相结合，并通过用户友好的Web浏览器界面将这些服务呈现给业务用户

业务mashup与消费者mashup在与业务计算环境的集成级别、安全性和访问控制特性、治理以及使用的编程工具(mashup编辑器)的复杂性方面有所不同。业务mashup和消费者mashup之间的另一个区别是，在商业软件即服务(SaaS)中使用业务mashup的趋势越来越明显。

许多业务mashup技术的提供者都添加了SOA特性。

Mashup的体系结构方面

mashup的架构分为三层:

• 演示/用户交互:这是mashup的用户界面。所使用的技术有HTML/XHTML、CSS、JavaScript、异步JavaScript和Xml (Ajax)。
• Web服务:可以使用API服务访问产品的功能。使用的技术有XMLHTTPRequest、XML-RPC、JSON-RPC、SOAP和REST。
• 数据:处理发送、存储、接收等数据。使用的技术有XML、JSON和KML。

在体系结构上，有两种类型的mashup:基于web的和基于服务器的。基于web的mashup通常使用用户的web浏览器来组合和重新格式化数据，而基于服务器的mashup在远程服务器上分析和重新格式化数据，并将数据以最终形式传输到用户的浏览器

mashup似乎是外观模式的变体。这是一种软件工程设计模式，它为更大的代码体提供了一个简化的接口(在本例中，代码使用不同的api聚合不同的提要)。

mashup可以与作为服务(SaaS)提供的软件一起使用。

经过几年的标准开发，主流企业开始采用面向服务的体系结构(SOA)，通过将不同的数据作为离散的Web服务提供来集成它们。Web服务提供开放的、标准化的协议，以提供从各种平台(操作系统、编程语言、应用程序)访问信息的统一方法。可以重用这些Web服务来在组织内部和跨组织提供全新的服务和应用程序，从而提供业务灵活性。

 

讨论：请加入知识星球【首席架构师圈】

前段时间我们发表了一篇文章，比较了Angular和React。 在那篇文章中，我们展示了这些框架的优缺点，并建议在2018年为特定目的选择什么。 那么，2019年前端花园的情况如何呢？

JavaScript框架正在以极快的速度发展，这意味着今天我们经常更新Angular，React和该市场上的其他玩家版本 -  Vue.js.

我们分析了全球需要特定框架知识的开放职位数量。 作为消息来源，我们采用Indeed.com并根据超过60,000个工作机会获得以下分配。

考虑到以下数据，我们决定分享每个前端框架的主要优点和缺点，并帮助技术专业人员或工程师根据他们的开发需求选择最佳的。

Angular的利弊

Angular是一个超级英雄的JavaScript MVVM框架，成立于2009年，非常适合构建高度交互的Web应用程序。

Angular的好处：

创建的Angular与Typescript一起使用。并且对它有特殊的支持。

Angular-language-service  - 允许在组件外部HTML模板文件中进行智能和自动完成。

新功能，例如来自CLI的一代基于Angular的npm库，基于Angular的WebComponents的生成和开发。

详细的文档，允许为个人开发人员获取所有必要的信息，而无需询问他的同事。但是，这需要更多的时间进行教育。

单向数据绑定，可为应用程序启用单一行为，从而最大限度地降低可能出错的风险。

MVVM（Model-View-ViewModel），允许开发人员使用同一组数据在同一个应用程序部分上单独工作。

通常使用模块和模块化依赖注入与组件相关的功能。

专为最佳项目可扩展性而创建的结构和体系结构

Angular的缺点：

与React和Vue.js相比，各种不同的结构（注射器，组件，管道，模块等）使得学习起来有点困难，React和Vue.js只考虑了“组件”。

根据不同的基准测试，性能相对较慢。另一方面，它可以通过利用所谓的“ChangeDetectionStrategy”轻松解决，它有助于手动控制组件的渲染过程。

使用Angular的公司：

 Microsoft, Autodesk, MacDonald’s, UPS, Cisco Solution Partner Program, AT&T, Apple, Adobe, GoPro, ProtonMail, Clarity Design System, Upwork, Freelancer, Udemy, YouTube, Paypal, Nike, Google, Telegram, Weather, iStockphoto, AWS, Crunchbase.

React的利弊

React是一个JavaScript库，于2013年由Facebook开源，非常适合构建任何规模和规模的现代单页应用程序。

React的好处：

由于其简单的设计，使用JSX（类似HTML的语法）进行模板化和高度详细的文档，因此易于学习。

开发人员花费更多时间编写现代JavaScript，而不必担心特定于框架的代码。

非常快，礼貌的React的虚拟DOM实现和各种渲染优化。

对服务器端呈现的强大支持，使其成为面向内容的应用程序的强大框架。

借助`create-react-app`应用程序生成器，支持一流的渐进式Web应用程序（PWA）。

数据绑定是单向的，意味着更少的不必要的副作用。

Redux是在React中管理应用程序状态的最流行的框架，易于学习和掌握。

React实现了功能编程（FP）概念，创建了易于测试和高度可重用的代码。

使用Microsoft的TypeScript或Facebook的Flow可以使应用程序类型安全，两者都具有对JSX的本机支持。

在版本之间迁移通常非常容易，Facebook提供“codemods”来自动化大部分过程。

在React中学到的技能可以（通常直接）应用于React Native开发。

React的缺点：

React是不受干扰的，让开发人员可以选择最好的开发方式。这可以通过强有力的项目领导和良好的流程来解决。

社区对在React中编写CSS的最佳方式存在分歧，在传统样式表（CSS模块）和CSS-in-JS（即情感和样式组件）之间进行划分。

React正逐渐远离基于类的组件，这可能成为开发人员更容易使用面向对象编程（OOP）的障碍。

最初将模板与逻辑混合（JSX）可能会让一些开发人员感到困惑。

使用React的公司：

 Facebook, Instagram, Netflix, New York Times, Yahoo, Khan Academy, Whatsapp, Codecademy, Dropbox, Airbnb, Asana, Atlassian, Intercom, Microsoft, Slack, Storybook, and many more.

 

Vue.js的优点和缺点

Vue.js是一个JavaScript框架，于2013年推出，非常适合创建高适应性的用户界面和复杂的单页面应用程序。

Vue.js的好处：

赋予HTML权力。这意味着Vue.js与Angular有许多相似的特性，这有助于通过使用不同的组件来优化HTML块处理。

详细文档。 Vue.js具有非常周密的文档，可以为开发人员设置学习曲线，并且仅使用HTML和JavaScript的基本知识就可以节省大量时间来开发应用程序。

适应性强。它提供了从其他框架到Vue.js的快速切换周期，因为它在设计和架构方面与Angular和React相似。

很棒的整合。 Vue.js可用于构建单页面应用程序和更困难的应用程序Web界面。主要的是，较小的交互式部件可以轻松集成到现有基础设施中，而不会对整个系统产生负面影响。

大规模。 Vue.js可以帮助开发相当大的可重用模板，根据其简单的结构，可以在没有为其分配额外时间的情况下制作模板。

小巧的尺寸。 Vue.js的重量可以保持在20KB左右，保持其速度和灵活性，与其他框架相比，可以实现更好的性能。

Vue.js的缺点：

缺乏资源。与React或Angular相比，Vue.js的市场份额仍然很小，这意味着该框架中的知识共享仍处于起步阶段。

过度灵活的风险。有时，Vue.js在整合到大型项目时可能会遇到问题，但仍然没有可能的解决方案经验，但它们肯定会很快到来。

使用Vue.js的公司：

Xiaomi, Alibaba, WizzAir, EuroNews, Grammarly, Gitlab and Laracasts, Adobe, Behance, Codeship, Reuters.

结论

对于真正的工程师来说，选择哪个框架没有太大的区别，因为它只需要一些时间来适应新的框架。在我们公司，我们在React和Angular中积累了大量专业知识，但Vue.js也在其中。每个框架都有自己的优点和缺点，这意味着在产品开发过程中每个案例都应该有正确的选择。

 

原文：https://medium.com/@TechMagic/reactjs-vs-angular5-vs-vue-js-what-to-choose-in-2018-b91e028fa91d

本文：http://pub.intelligentx.net/react-vs-angular-vs-vuejs-what-choose-2019-updated

讨论：请加入知识星球或者小红圈【首席架构师圈】

快速总结:为项目选择正确的javascript框架或库是CTO和项目经理的基本任务。然而，选择的范围很大程度上取决于几个因素，如项目时间、学习曲线、框架性能和团队规模。这篇文章旨在指导他们选择正确的javascript框架(或库):React vs Vue。

React vs Vue -选择正确框架的CTOs指南

这是一个值得你考虑的案例!

Rever Inc.，一家硅谷公司，在构建他们的最后一个MVP之前，将将近10,000行Angular.js代码移植到了Vuejs上。

好吧，他们需要使用的Angular版本的发布被延迟了，这是不可预见的，他们等不起，因为这会浪费时间和资源。

 

直接引用Luis Elizondo (Rever的工程总监)的话——

在为我们评估正确的选择框架之前，我必须亲自动手，所以我给了React和Vue.js几天时间来回顾每个不可能被谷歌回答的决策点。由于我对它们一无所知，在两天结束时，我将重新评估我在重写我们将要迁移的实际项目的某些部分时走了多远。

在评估了两个框架之后，Luis和他的团队决定使用Vue，因为他们发现Vue比React更容易使用。

现在想象你自己处于一个类似的情况，你的1000个小时的努力都是徒劳的，这不是你自己的错。

考虑到项目的截止日期很紧，太多的产品经理和CTO落入了一个常见的陷阱——他们选择了一个让他们轻松开始的框架，而没有考虑框架随时间的影响。然而，他们很快就意识到最好事先评估用例并选择合适的框架，以避免任何类型的问题。

在这篇博客文章中，我将比较React和Vue的几个因素，这些因素将帮助我们评估需要的正确技术。

在进行深入的比较之前，你可以先问自己一些问题，这样你就可以对这个问题有一个全面的了解。这些问题只是帮助你评估React和Vue之间正确框架的因素。

React vs Vue: CTO和项目经理的比较因素

• 代码有多干净和直观?
• 框架支持模块化吗?
• 开始使用这个框架有多容易?它是否支持JS导入?
• 框架的测试和调试方面有多好?
• 我的队友和我能够轻松地学习这个工具吗?
• 框架在性能方面是如何脱颖而出的?
• 从项目开始算起，在5-10年以上的时间里，这些代码会给我带来更多的麻烦吗?或者在那些年里，我将被一个几乎无法维护的遗留应用程序所束缚?
• 框架支持服务器端呈现吗?
• 框架适合轻量级还是重量级应用程序?
• 这些框架的顶级实用程序是什么?什么时候使用它们是正确的选择?

现在你有了问题，让我们通过将这些因素与React和Vue并置来深入研究问题的实质，了解它们的区别。

React和Vue的代码质量比较

代码有多干净和直观?

首先:能够让您快速浏览大型项目代码的框架应该是理想的选择。

显然，对于许多CTO和项目经理来说，一切都归结为“代码通过测试的速度有多快，以及这些测试如何处理类型”。

请注意，要提高代码质量，还有很多事情需要考虑。例如，单元测试、linting和类型检查是我的团队和我在Simform积极执行的事情。

我不会在这里拐弯抹角地提到所有这些实践。因为我相信类型检查确实能提高代码质量，所以让我们比较一下Reactjs和Vuejs，看看它们是否支持任何方式的类型检查。

React的静态类型检查

React确实利用了JavaScript ES6基础作为代码语法，但是它是否支持编译时的类型检查之类的功能呢?

嗯，是的!

你可以用Flow来做静态检查，它是Facebook开发人员开发的TypeScript的替代品。它允许您向代码中添加类型，然后在构建(编译)时删除它们，以保留正常的Javascript代码。

[注:如果你喜欢TypeScript，但仍然想使用React，那么你最好去，因为TypeScript对JSX有很好的支持，这可能就是微软在最新版本的office中使用它的原因]

Vue中的静态类型检查

Vue还利用Javascript ES6语法来编写代码。然而，当涉及到静态类型检查时，在Vue中使用Typescript就不是那么简单了。有一些课程是关于如何将Typescript和Vue一起使用的，但是在复杂的项目中是否值得考虑仍然不清楚。

幸运的是，您可以将flow与Vue集成并启用静态类型检查。

React和Vue的模块化

框架支持模块化吗?

根据模块化原则，您的应用程序必须划分为独立的模块，每个模块代表单一的目的或功能。这一原则也被称为单一责任原则。

“做一件事并把它做好”——Unix哲学

让我们用一个简单的现实生活用例来理解模块化:

假设您的代码库包含一组专门为API编写的服务。现在，如果您的客户端需要您从应用程序中删除整个API功能，重要的是您要将这些服务保存在一个单独的模块中，以便在不破坏应用程序的情况下轻松删除这些服务。这就是您需要框架中的模块化的地方。模块化使得在应用程序很大的情况下，可以很容易地插入新特性，而更复杂的特性应该随着版本的每次更改而迭代。

模块化的React

在React中，应用程序的每个部分都要处理组件。

在React中支持模块化的一种理想方式是确保应用程序的每个组件在理想情况下只做一件事。即使组件在增长，更好的方法是将其进一步分解为更小的子组件。

通过将代码库分割成小的、自包含的块，它使React应用程序开发比Angular更直观。您可以单独开发和测试模块，这使得添加特性和识别错误变得更容易。

模块化的Vue

Vue利用了“单文件组件”的概念。这似乎是在分离关注点方面的权衡，因为您的脚本、模板和样式将在一个文件中，但在三个不同的有序部分中。

学习曲线- React和Vue

我和我的同事能够轻松地学习这个工具吗?

React的学习曲线

我观察到许多开发人员声称，如果使用Vue，他们在React中所做的事情会更好、更容易。但是所有这些声明对我来说都没有意义。对我来说，Vue更像是一个简单的JavaScript，还有一些新的想法，单向数据流、组件和事件驱动的模型。

Vue的学习曲线

在学习曲线方面，Vue胜过了其他Javascript框架。您只需要一些像样的JS技能或对ES6的良好理解就可以使用Vue。总的来说，即使使用文档本身，学习起来也容易得多。

开发者友好性和易用性

开始使用这个框架有多容易?

当涉及到开发时，框架应该更容易启动。比较Reactjs与Vuejs或任何其他框架的一种方法是，确定在有项目需求时启动它们的容易程度。

要为您的项目选择正确的框架，您需要确定您和您的团队想要在JSX还是HTML上工作。为了给您一个初步的概述，我想强调一下，基于标准HTML模板和组件的框架通常易于结构和代码重用。然而，新开发人员更有可能发现难以处理JSX。

React:开发者友好性和易用性

React希望您构建组件而不是模板，因为组件是最可重用的，并且对单元测试友好。它依赖于JSX, JSX允许您混合UI模板和JavaScript。但是在一天结束的时候，你会觉得你是在Javascript上工作。使用JSX可以极大地促进开发，因为它允许React显示更有用的错误和警告消息。

由于UI和JS代码不能在React中分离，所以关于样式的使用只有一个问题。

说到风格，你有多种方法来开始:

• 使用webpack提取您的导入' my '.css语句转换成样式表
• 或者使用 “CSS in JS”库

当涉及到React项目时，它更像是一个狂野的西部，您拥有一个庞大的库和工具生态系统来补充您的应用程序。就我个人而言，我真的很喜欢这样，但是对于开发者来说，如果他们有很多选择的话，做出正确的选择并不总是那么容易。此外，React没有明确的规则或规章。每次应用程序的体系结构必然要改变时，您都必须选择不同的内容。这使得事情的范围很容易出错。

Vue:开发者友好性和易用性

Vue被称为“进步web框架”是有原因的，因为有不同的特性会影响正在开发的应用程序的大小。Vue还提供了一个CLI和与webpack等构建工具集成的包。在这种环境中编写组件的最首选方法是单文件组件，即带有模板、脚本和样式标记的文件。

我过去与几家公司合作过，当被问及选择Vue的原因时，他们给出的理由只是他们的开发人员觉得Vue更容易学习。Vue减少了初级开发人员和高级开发人员之间的差距，从而使他们在项目中很好地协作。它甚至对项目也有好处，因为它完成时bug更少，投放市场的时间更短。

测试和调试

框架的测试和调试方面有多好?

在React中测试和调试

测试:Facebook推荐Jest来测试React代码。下面是Jest和Mocha 的比较——还有一篇文章是关于如何在Mocha 中使用Enzyme 的。Enzyme 是Airbnb使用的一个JavaScript测试工具(与Jest、Karma和其他测试运行程序一起使用)。如果您想阅读更多内容，这里有一些关于在React中进行测试的老文章(这里和这里)。

Vue的测试和调试

测试:目前，Vue缺乏任何重要的测试指导，但Evan在他的2017预览中写道，团队计划在这方面工作。他们建议使用Karma。Vue与Jest一起工作，还有Vue test Utils.。

调试:与调试任何其他web应用程序一样，Vue中的调试变得更加容易。您可以利用开发工具、断点、调试器语句等来调试应用程序源代码。还有这个vVue.js devtools ，这样您就可以轻松地调试Vue应用程序。

在React和Vue中支持服务器端呈现

框架支持服务器端呈现吗?

如果web应用程序的目标是优化高搜索引擎，服务器端呈现是一个基本要求。由于任何多页面应用程序都可以由几个较小的spa组成，因此框架拥有这个选项是一个重要的标准。

以下是AirBnB的开发团队对服务器端渲染的看法:

首先，与客户端呈现相比，服务器端呈现具有更好的用户体验。用户获取内容的速度更快，当JS失效或禁用时，网页更容易访问，搜索引擎也更容易索引它。

React中的服务器端呈现

目前，React缺乏关于SSR的官方文件。React API支持一个名为ReactDOMServer的对象，当您希望以HTML代码的形式显示组件时，该对象非常方便。此外，学习如何使用诸如React Router和Redux这样的库，以便在没有任何问题的情况下执行服务器端呈现，也是很重要的。React团队宣布官方支持将很快发布。还有一个框架可以用来创建一个React SSR应用程序，叫做Next.js。因此，React启用了SSR，但没有官方支持，并且使用了额外的第三方包。

Vue中的服务器端呈现

还有一个官方发布的Vue.js指南，用于构建在服务器上呈现的Vue应用程序。该指南放置在一个特殊的领域，与Vue文档分开。它非常详细，并且假设用户已经熟悉Vue，并且对Node.js和Webpack有一定的了解。此外，文档引用了 Nuxt.js，是社区发布的框架，是Vue中对SSR的更高层次的解决方案。它提供了某些附加特性，但是，它限制了开发人员对应用程序结构的直接控制。

Reactjs与Vuejs中的代码可维护性

从项目开始算起，在5-10年以上的时间里，这些代码会给我带来更多的麻烦吗?

几年前，我的一个客户要求转移到一个框架，以便现在和将来的开发团队能够围绕代码工作。很明显，对于他们来说，拥有一个高可维护性的框架是多么重要。在比较框架时，代码的可维护性应该是最重要的方面之一。

也就是说，现在让我们比较一下在代码可维护性方面React和Vue是如何结合在一起的。

React的可维护性

至于React，虽然通往0.14系列的道路也很坎坷，但从React 15开始，Facebook开始以一种更负责任的方式专注于做出突破性的改变。即将到来的破坏性更改现在会在您的应用程序中发出弃用警告，并给您时间迁移到新的api。

当前的稳定版本(第16版)改变了一些核心的生命周期方法，但也正式稳定了一些长期使用的“实验”api，这意味着在达到这一点后，未来的更新会更容易。

由于React在工具上的反应更轻，虽然一些破坏性的更新可以自动化，但不是所有事情都可以。这意味着一些更新可能会比其他的更痛苦，尽管在核心库中的改进通常是值得的。

React的一个明显的烦恼是，旧版本文档的删除，使得现有(和潜在的未来)项目的维护更加困难，除非您保持最新。

Vue的可维护性

考虑到Vue的增长速度，决定Vue是否可以用作长期运行的框架将是未来的事情。我不会详细介绍这个方面，但是有一篇有趣的文章是关于Vue的可维护性因素以及它是如何应对的。

React vs Vue -性能和内存消耗

框架在性能方面是如何脱颖而出的?

说到性能，我想用这个简单的一行代码来说明我的情况:

“每个框架的绩效评估都很重要，它绝对应该是评估一个框架的重要前提指标。””

如果你还想知道这些框架在性能方面的突出之处，那么你可以通过这个综合的研究，在DOM操作的基础上对Reactjs和Vue的性能和内存消耗进行基准测试。这项研究是使用一个基准工具执行的，该工具测量了使用这些框架完成大量DOM操作事件所需的时间。

对React和Vue的性能进行基准测试

基准测试研究中包含的DOM操作基于研究这些框架在操作表行方面的性能。对这一行进行的操作是:

• 向表中添加10行，
• 向表中添加1000行，
• 每隔10行更新一次表，
• 在表中选择一行，并且
• 从表中删除一行

当涉及到React和Vue的内存评估时，该研究利用了Chrome Profiler，它可以让你对网页的JavaScript堆进行快照。

拍摄了两个快照来演示在以下时间的内存使用情况:

• 在执行任何操作之前加载页面
• 在表上执行5个添加10、5个添加1000和5个更新操作之后

研究结果如下:

React性能和内存消耗

性能:如图所示，当DOM更新越来越大，需要更新更多数据时，React的虚拟DOM似乎获得了回报。这就是大多数React出现的性能问题。React在删除和添加1000指标上的性能最好。

内存消耗:React的初始内存占用与Angular非常相似。从初始状态8.3 MB的内存消耗到DOM操作之后15.1 MB的内存消耗，您可以看出响应DOM操作操作的计算开销相当大，但它们仍然可以。

Vue性能和内存消耗

性能:在大多数情况下，Vue的性能与React一样好，比如添加10、更新和选择指标，很可能是这样，因为Vue还利用虚拟DOM来操作操作。

Vue在性能方面反应滞后的唯一区别是增加了1000个指标，这是因为DOM操作操作数量的增加。

内存消耗:Vue在初始状态时的内存占用是7.6，考虑到它是纯JavaScript语言，这比React和Angular都要好。然而，一旦执行了DOM操作，这个值就会增加到16.1，这比React和Angular都要大。

可扩展性——Reactjs vs Vue

框架是否足够成熟，可以构建可伸缩的应用程序?

当谈到可伸缩性时，唯一重要的是您的解决方案如何处理请求的累积数量，以及在负载突然达到峰值时它的显著行为是什么。由于大多数基于JavaScript的web应用程序都是为大量用户设计的，因此评估您选择的解决方案是否具有可扩展性就变得非常有意义。话虽如此，让我们看看React和Vue是否满足可伸缩性预期。

React构建可伸缩的web应用程序

React只是一个用于在页面上创建和呈现可重用组件的库——您仍然需要收集一堆其他库来将它们组合在一起(路由、HTTP请求等)。

web应用程序中的可伸缩性问题主要归结为代码组织得有多好、技术债务的数量以及web应用程序如何作为一个整体进行架构设计。

根据我个人与数千个客户打交道的经验，我发现像Angular这样的框架绝对是可扩展的，因为开发人员从一开始就倾向于遵循这种设计模式。

不要误解我的意思，我喜欢React，但是如果一个React应用程序从一开始就没有经过很好的考虑，它可能会很快失控(比如很多意大利面条式的代码)。我曾经有一个客户为React编写了一个自定义类模块的特性，浏览他们的代码非常愉快。

也就是说，React仍然可以用于构建可伸缩的web应用程序，但只有在从一开始就考虑可伸缩性时才会考虑。

Vue用于构建可伸缩的web应用程序

作为轻量级的JavaScript库，Vue只适合于较小的应用程序。它不适用于构建可伸缩的应用程序。

React vs Vue:应用程序大小

框架适合轻量级还是重量级应用程序?

在为大型应用程序选择框架时，最重要的是一致性和架构决策制定。在大型应用程序中，明智地选择框架是至关重要的。否则，转换将是一个巨大的痛苦。

因此，让我们探讨一下React和Vue的框架大小以及它们的大小对您业务的软件开发项目的影响。

React

框架/库的大小会对软件开发项目产生重大影响。React大小约为100kb，非常适合轻量级应用程序。此外，React还需要其他库对特定任务的支持，其中一个任务就是路由。它的小尺寸非常适合轻量级应用程序。

Vue

Vue是其他框架和库中最小的。它的大小大约为80kb。它甚至比反应还要小。Vue非常适合开发轻量级应用程序。如果您需要一个小于Vue的库，那么您应该选择Preact。

React vs Vue -在哪里使用什么?

这些框架的顶级实用程序是什么?什么时候使用它们是正确的选择?

现在我们已经评估了几乎所有必要的因素，让我们探索您的项目的React和Vue的最重要用例。它将帮助你选择正确的一个，从而避免不必要的成本。

React

我认为React是构建静态网站的最佳选择。您所需要做的就是使用renderToStaticMarkup呈现组件，并将呈现的有效负载发送给客户机。

此外，选择React开发小而简单的应用程序可能并不过分，因为它是为大型web项目创建的。。尽管React需要大量样板代码来设置一个工作项目，但从长远来看，它的架构是值得的。

JSX提供了JavaScript的全部功能(如流控制)和高级IDE特性(如组件视图模板中的自动完成)。

React vs Vue:对照表

Reactjs vs Vue:选择正确框架的专家意见

我快速接触了一些Javascript专家和CTO，询问他们对于在React和Vue中选择一个框架的看法。我感谢@KentCDodds和@TomGoldenberg对这篇博客所做的宝贵贡献。

我们问了他们一些问题，以下是他们对这场辩论的看法:

Thomas Goldenberg，突击队首席技术官

你对著名的“React vs Angular vs Vue”辩论有什么看法?

我用的是React和Angular，不是Vue。但我不会在这方面投入大量资金，因为我觉得它的应用不如另外两种那样广泛。由于有了React和Angular，我肯定觉得React对代码更直观。也就是说，Angular一直在进步，TypeScript也得到了很多支持。

如果有机会构建一个社交网络应用程序，你会选择哪种框架(或语言)?

Social意味着许多连接，这将使React - GraphQL成为一个很好的组合。这将有助于准备所有连接数据。

如果有机会构建基于企业的电子商务web应用程序(有未来迭代的可能性)，您会选择哪种框架(或语言)?有什么特殊的原因吗?

对于电子商务网站应用程序，我会使用Next.js，因为服务器端呈现对许多电子商务网站来说很重要，在这些网站中，每个列表都必须是可索引和可搜索的。接下来真是太棒了，时代周刊的团队也让人印象深刻。

如果有机会构建一个基于内容的平台，站点结构不会发生变化，您会选择哪种框架(或语言)?

我也会用Next.js，因为基于内容的平台需要有好的SEO和索引。

Kent C. Dodds, PayPal软件工程师，Javascript/ React专家

当你在React、Angular或Vue(或其他几个)中选择一个合适的框架(或语言)时，你会考虑哪些方面?

所有这些框架在功能和性能方面都非常相似。与其他框架相比，我更喜欢React是有一个原因的，这个原因是我相信它在概念上比其他框架更简单，而其他框架会使应用程序更具可维护性和更容易测试。与其他原因相比，最重要的考虑是我在一个给定的框架下会有多有效，而React对我来说绝对是最好的一个。

如果有机会构建一个社交网络应用程序，你会选择哪种框架(或语言)?

如果我有足够的时间去学习，我可能会尝试使用ReasonML作为语言，而ReasonReact作为框架。如果我需要快速完成它，那么我肯定会使用JavaScript(加上用于静态类型的Flow)并对框架做出反应。

如果有机会构建基于企业的电子商务web应用程序(有未来迭代的可能性)，您会选择哪种框架(或语言)?有什么特殊的原因吗?

如果我有足够的时间去学习的话，我仍然更喜欢使用合情合理的语言和合情合理的框架。如果试验和学习的时间更少，我宁愿使用Javascript(加上用于静态类型检查的Flow)并作为框架来响应。

如果你的开发团队并不精通Javascript，你会选择哪种框架(或语言)?

我肯定会选React。原因是，我认为一个开发团队虽然不精通JavaScript，但构建web应用程序时肯定应该学习JavaScript，而能教他们最好的JavaScript框架是React。其他框架在隐藏JavaScript方面做得相当好，你最终会编写比JavaScript更多的框架代码，这在一开始看起来似乎是正确的，但从长远来看，团队最好还是好好学习JavaScript。

结论

React或Vue或任何其他基于Javascript的解决方案就它们自己的用例而言都非常酷。我想说，没有最好的解决办法。最好由您来确定您的用例，并将其映射到这些框架的各个方面。

为了让事情更简单，我总结了用例和React和Vue之间推荐的解决方案(不总是):

• 如果你喜欢摆弄大量的libary、工具或生态系统，那么选择React
• 如果你是一个“JS迷”，并且讨厌把你的UI和代码分开——选择React
• 如果你喜欢编写干净和简单的代码——选择Vue
• 如果你想尽快开始你的项目，选择Vue
• 如果您是一个没有团队的单独开发人员，请选择Vue(或React)
• 如果您希望开发可伸缩的应用程序，而不为测试和调试带来任何麻烦，请选择React
• 如果您想在您的项目中更好地分离关注点，请选择Vue
• 如果你喜欢玩Javascript并且接受应用状态变化的概念-选择React(或Vue)
• 如果你要建立任何复杂的应用程序，有更好的上市时间-选择React

那么你对React vs Vue的比较有什么看法，请在评论中告诉我。

 

原文：https://www.simform.com/react-vs-vue/

本文：http://jiagoushi.pro/node/1275

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

 

这是帮助开发人员构建Web应用程序的三种最流行的工具。 请继续阅读，了解哪一个最适合您的需求。

 

在当今的发展世界中，技术正在快速增长并且变化迅速，许多开发工具似乎可以解决不同的开发问题。在本次讨论中，我们将比较三种最流行的前端开发技术--Angular，React和Vue。我们正在基于项目架构或从开发人员的角度讨论这种比较，他们将为新项目选择技术。因此，我们首先需要明确决定是否要开发单页面应用程序（SPA）或标准的多页面应用程序。

库或框架？

所以在进行更深入的比较之前，我们首先需要确定需要哪一个 - 库或框架？实际上，库设计用于执行某些特定任务，它们通常并不复杂。因此，如果我们使用库构建应用程序，那么我们需要为每个任务选择一个库，以及设置任务运行器。库的主要优点是我们可以完全控制应用程序。但问题是设置项目需要花费更多的时间。

另一方面，框架是为执行更复杂的事情而设计的。因此，如果我们使用框架，那么它将自动为我们解决许多问题。每个框架都有一个预定义的设计或结构，包括许多库和设置的运行程序。框架的主要优点是开发过程要快得多，因为它包含执行不同任务所需的所有可能的库。但是框架的设计比库更严格。

React是用于构建用户界面的库，而Angular和Vue是用于相同目的的框架。

生命周期与战略比较

 

• React于2013年3月首次发布，被描述为JavaScript库。 React由Facebook开发和维护。 Facebook在多个页面上使用React用于许多组件，但不用于创建单个页面应用程序。 React也被Uber，Netflix，Twitter，Reddit，Udemy，Paypal，Walmart和其他人使用。
• Angular是一个基于TypeScript的JavaScript框架。它由Google开发和维护。它于2010年10月首次发布，但此后经历了多次更新，目前正在使用Angular 6. Angular被描述为“超级英雄JavaScript MVW框架。”Angular被Google，Wix，weather.com，Forbes和其他人使用。
• Vue是当今世界上发展最快的JavaScript框架之一。 Vue被描述为“用于构建交互式界面的直观，快速且可组合的MVVM。”它于2014年2月首次发布。它是前Google员工Evan You的心血结晶。 2016年，Vue第2版发布。它被阿里巴巴，百度，GitLab和其他公司使用。

Angular，React和Vue都在MIT许可下提供。

核心发展

根据上面的讨论，Angular和React受到Facebook，Google，Whatsapp等大公司的支持和使用。目前，Google在他们的许多项目中使用Angular，例如AdWords UI（使用Angular和Dart实现）。而Vue主要用于小型项目的个人。我们来看看在GitHub上找到的一些统计数据：

• Angular拥有超过25,000颗星和463个贡献者。
• React拥有超过70,000颗星和超过1,000名贡献者。
• Vue拥有近6万颗星，仅有120位贡献者。

灵活性

我们可以通过简单地将JavaScript库添加到源应用程序来开始使用React或Vue进行开发工作。但是对于Angular来说这是不可能的，因为它使用TypeScript。因为在当今的Web开发世界中，我们正在更多地接近微服务和微应用程序，React和Vue通过仅选择那些真正需要的东西来让我们更好地控制应用程序的大小。 Angular最适合作为基于SPA的应用程序的框架。

性能

在库或框架的大小的情况下，Angular相对于其他选项而言相当大。 gzip文件大小为143k，而Vue为23k，React为43k。 React和Vue都使用Virtual DOM，它可以提高浏览器DOM的性能。在整体分析中，Vue具有出色的性能和三者最深的内存分配。但是所有这三个选项在性能方面都非常接近。

如果要检查源，则可以访问下面的GitHub存储库：

 

结论

React，Angular和Vue对于开发都非常有用，并且它们都没有明显优于其他开发。所以下面我给出了一个表格，它将展示何时选择哪一个：

Angular	React	Vue
想要使用TypeScript	想要使用基于JavaScript的方法。	最简单的JavaScript学习曲线。
想要使用OOPS（面向对象编程）	想要使用大型生态系统。	从事小型项目。
想要使用基于结构的框架	想要灵活性。	开发团队包含少数开发人员。
想要构建混合应用程序	想要构建本机应用程序。
开发团队拥有大量开发人员。	开发团队包含大量开发人员。
如果要将HTML分开以用于设计目的。	如果要为JavaScript代码和HTML代码保留单个文件。	如果要将HTML分开以用于设计目的。

如果你仍然无法决定你需要选择哪一个，我建议你先学习React，然后是Vue，然后是Angular。 因为前两个主要基于JavaScript，第三个完全基于TypeScript。

原文：https://dzone.com/articles/angular-framework-advantages-compare-to-react-amp

本文：https://pub.intelligentx.net/react-angular-and-vue-which-one-best-and-why

讨论：请加入知识星球或者小红圈【首席架构师圈】

大型应用程序的前端管理是最难解决的问题之一。虽然有几种方法可以解决状态管理问题，但Redux和MobX是两个最流行的外部库，用于解决前端应用程序中的状态管理问题。在这篇文章中，我们将研究每个库以及它们是如何匹配的。

本文假设您对web应用程序中的状态管理工作有一个基本的了解。普通JavaScript和Redux框架都适用于普通或不可知的框架。

Redux

Redux是一个流行的状态管理解决方案，它结合了Flux和函数式编程概念。Redux的一些核心原则是：

• Redux只有一个存储——单一来源的真相
• 存储区中的状态是不可变的
• 操作会调用对存储的更改
• Reducers（减速器）更新状态

MobX

MobX是一个状态管理解决方案，可以帮助管理应用程序中的本地状态。

MobX的一些核心原则是：

• MobX可以有多个存储来存储应用程序的状态
• 任何可以从状态派生而不需要任何进一步交互的东西都是派生
• Action是任何可以改变状态的代码
• 当状态发生变化时，所有的派生都会自动和自动地更新

现在让我们比较Redux和MobX的一些关键特性，看看哪些特性更适合您的需求。

人气

在开始学习Redux或MobX之前，让我们看看哪个更受欢迎。

看看下面的谷歌趋势图。截至2019年4月，相比MobX，Redux在谷歌上似乎是一个更受欢迎和搜索的概念。

为了深入了解他们的受欢迎因素，让我们看看2018年JavaScript现状调查。它发布了过去三年里Redux和MobX在开发者中的受欢迎程度的数据。

Redux

Mobx

在过去的几年里，Redux已经获得了大量的人气，并且已经成为状态管理的最佳解决方案。虽然MobX不像Redux那么受欢迎，但它也有自己的优势。

获奖者：Redux

学习曲线

Redux

开发人员对Redux的普遍看法是它不容易学习。2018年JavaScript现状调查分析了Redux最不受欢迎的方面。在这里，开发人员投票认为他们不喜欢Redux的复杂性和它带来的艰苦的学习曲线。

它需要一些时间来理解它的模式和范例。它是通量体系结构和函数式编程概念的结合。如果您是一个函数式程序员，您可能会发现掌握Redux更容易，而如果您来自面向对象编程背景，Redux代码最初看起来很复杂而且很难理解。

学习Redux还意味着您需要了解像Thunk和Saga这样的Redux中间件，这会增加更多的学习内容。

Mobx

众所周知，与Redux相比，MobX更容易掌握。大多数JavaScript开发人员都精通面向对象编程，这使得学习MobX变得简单。另外，MobX中有很多事情是在幕后完成的，为开发人员创造了更好的学习体验。您不必担心状态的规范化或实现类似Thunks的概念。由于已经内置了抽象，因此编写的代码更少。

获奖者：MobX

存储数据-单个存储与多个存储

存储区是我们存储本地数据的地方。它保存整个应用程序的状态。JSON应用程序的状态存储中通常包含一个巨大的对象。

Redux

在Redux，只有一家商店，它是唯一的真理来源。存储中的状态是不可变的，这使得我们更容易知道在哪里可以找到数据/状态。在Redux中，虽然有一个巨大的JSON对象来表示存储，但是您可以始终将代码拆分为多个reducer。这样，就可以用多个reducer在逻辑上分离关注点。对于许多开发人员来说，这是一种更直观的方法，因为他们可以始终引用应用程序状态的单个存储区，并且不存在与当前数据状态相关的重复或混淆的可能性。

Mobx

另一方面，MobX允许多个商店。您可以在逻辑上分离存储区，因此应用程序的所有状态都不在一个存储区中。大多数应用程序设计为至少有两个存储区：一个用于UI状态，一个或多个用于域状态。以这种方式分离存储区的好处是，您也可以在其他应用程序中重用该域。UI存储将特定于当前应用程序。

获奖者：Redux

这个类别的赢家是主观的；这取决于开发者的偏好。我个人喜欢将应用程序的整个状态存储在单个存储中的想法。这有助于我把同一个地方称为真理的唯一来源。有些人可能会说多家商店对他们更有效，更喜欢MobX。

数据结构

Redux

Redux使用普通JavaScript对象作为数据结构来存储状态。使用Redux时，必须手动跟踪更新。在需要维护大量状态的应用程序中，这可能更困难。

Mobx

MobX使用可观测数据。这有助于通过隐式订阅自动跟踪更改。在MobX中，更新是自动跟踪的，因此对开发人员来说更容易。

获奖者：MobX

纯与不纯

Redux

在Redux中，存储中的状态是不可变的，这意味着所有状态都是只读的。Redux中的操作可以调用对状态的更改，reducer可以用新的状态替换以前的状态。这是Redux的核心原则之一。

下面是纯函数的一个简单示例：

function sumOfNumbers(a, b) {
 return a + b;
}

函数将始终返回相同的输出，给定相同的输入。它没有任何副作用或来自外界的影响。

Redux函数使用以下模式编写。reducer是接受一个状态和动作并返回一个新状态的纯函数。

function(state, action) => newState

这让Redux变得纯洁。如果您有兴趣了解更多关于纯函数以及它们在Redux中如何操作的信息，您可以阅读本文以获得更好的理解。这是Redux最好的特性之一。

Mobx

在MobX中，状态是可变的，这意味着您可以简单地用新值更新状态。这让黑帮变得不纯洁。不纯函数很难测试和维护，因为它们并不总是返回可预测的输出。

获奖者：Redux

由于Redux存储是纯的，因此更容易预测，并且很容易恢复状态更新。在MobX的情况下，如果操作不当，状态更新可能会使调试更加困难。

样板代码

Redux

关于Redux最大的抱怨之一是它附带的大量样板代码。当您将React与Redux集成时，会产生更多的样板代码。这是因为Redux本质上是显式的，很多功能都必须显式地编码。

Mobx

MobX更隐式，不需要很多特殊工具。与Redux相比，它的样板代码要少得多。这使得MobX更容易学习和设置。

获奖者：MobX

开发者社区

对于开发人员社区，Redux轻而易举地赢得了胜利。Redux附带了reduxdev工具，供成千上万的开发人员使用。它为调试Redux代码提供了惊人的支持。

MobX还提供开发人员工具，但它们没有Redux提供的相同质量的调试支持。

GitHub统计数据很好地表明了两个库的社区参与度。Redux拥有约48k星，超过672位投稿人。另一方面，MobX拥有大约1.9万星和155名投稿人。

如果我们看看npm的下载量，Redux是遥遥领先的。Redux平均每周下载300万次，MobX平均每周下载25.4万次。这表明Redux被广泛采用。

获奖者：Redux

可扩展性

由于Redux更加固执己见，并且期望reducer函数是纯的，因此它比MobX更容易扩展。Redux的固执己见和纯粹的特性使得应用程序具有可伸缩性。

纯函数更容易测试，因为它们是可预测的和简单的。这就产生了可伸缩的可维护代码。这是选择Redux而不是MobX的核心优势之一。

获奖者：Redux

结论

好吧，判决结果如何？基于开发人员社区、流行度和可伸缩性，Redux的性能优于MobX。但是，如果你想快速跟上速度，用更少的样板代码构建简单的应用程序，MobX可能是你的朋友。

 

 

原文：https://blog.logrocket.com/redux-vs-mobx/

本文：http://jiagoushi.pro/node/1281

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【1110777】

 

什么是Web组件？

Web组件是一组Web平台API，允许您创建新的自定义，可重用，封装的HTML标记，以便在网页和Web应用程序中使用。自定义组件和小部件构建在Web组件标准之上，可以在现代浏览器中使用，并且可以与任何使用HTML的JavaScript库或框架一起使用。

Web组件基于现有Web标准。支持Web组件的功能目前正在添加到HTML和DOM规范中，让Web开发人员可以使用封装样式和自定义行为的新元素轻松扩展HTML。

产品规格

Web组件基于四个主要规范：

自定义元素

Custom Elements规范为设计和使用新类型的DOM元素奠定了基础。

影子DOM

shadow DOM规范定义了如何在Web组件中使用封装样式和标记。

ES模块

ES模块规范以基于标准，模块化，高性能的方式定义JS文档的包含和重用。

HTML模板

HTML模板元素规范定义了如何声明在页面加载时未使用的标记片段，但可以在运行时稍后实例化。

我如何使用Web组件？

此站点上的组件提供了可在Web页面和Web应用程序中使用的新HTML元素。

使用自定义元素就像导入它一样简单，并使用HTML文档中的新标记。例如，要使用paper-button元素：

<script type="module" src="node_modules/@polymer/paper-button/paper-button.js"></script>
...
<paper-button raised class="indigo">raised</paper-button>

有许多方法可以安装自定义元素。当您找到要使用的元素时，请查看其README以获取安装它的命令。今天的大多数元素都可以与NPM一起安装。 NPM还处理安装组件的依赖项。有关NPM的更多信息，请参阅npmjs.com。

例如，纸张按钮概述描述了使用npm的安装过程：

mkdir my-new-app && cd my-new-app
npm install --save @polymer/paper-button

如何定义新的HTML元素？

本节介绍Web组件规范的跨浏览器版本的语法。

使用JavaScript通过customElements全局定义新的HTML元素及其标记。使用您要创建的标记名称调用customElements.define（）以及扩展基本HTMLElement的JavaScript类。

例如，要定义移动抽屉面板，<app-drawer>：

class AppDrawer extends HTMLElement {...}
window.customElements.define('app-drawer', AppDrawer);

要使用新标签：

<app-drawer></app-drawer>

使用自定义元素与使用<div>或任何其他元素没有什么不同。可以在页面上声明实例，在JavaScript中动态创建，可以附加事件侦听器等。

<script>
// Create with javascript
var newDrawer = document.createElement('app-drawer');
// Add it to the page
document.body.appendChild(newDrawer);
// Attach event listeners
document.querySelector('app-drawer').addEventListener('open', function() {...});
</script>

创建和使用阴影根 （ shadow root）

本节介绍使用shadow DOM规范的新跨浏览器版本（v1）创建shadow DOM的语法。 Shadow DOM是一种新的DOM功能，可帮助您构建组件。您可以将shadow DOM视为元素中的作用域子树。

影子根是一个附加到“host”元素的文档片段。附加阴影根的行为是元素如何获得其阴影DOM。要为元素创建shadow DOM，请调用element.attachShadow（）：

const header = document.createElement('header');
const shadowRoot = header.attachShadow({mode: 'open'});
shadowRoot.innerHTML = '<h1>Hello Shadow DOM</h1>'; // Could also use appendChild().
// header.shadowRoot === shadowRoot
// shadowRoot.host === header

用于构建Web组件的库

已经存在许多库，可以更轻松地构建Web组件。该网站的图书馆部分有其他详细信息，但您可以尝试以下内容：

1. Hybrids 是一个用于使用简单和功能API创建Web组件的UI库。
2. LitElement 使用lit-html渲染到元素的Shadow DOM中，并添加API以帮助管理元素属性和属性。
3. Polymer 提供了一组用于创建自定义元素的功能。
4. Slim.js是一个opensource轻量级Web组件库，它使用es6本机类继承为组件提供数据绑定和扩展功能。
5. Stencil i是一个开源编译器，可生成符合标准的Web组件。

 

原文:https://www.webcomponents.org/introduction

 

这篇文章是与 Razorpay 的前端核心团队合作的，该团队由 Varun、Kamlesh、Dhruvdutt、Chaitanya、Saurav、Zameer 组成。

去年，我们组建了前端核心团队，为构建与我们一样快的前端应用程序奠定了基础，这样开发人员就可以专注于更快地交付产品，而不会影响质量。

我们将走过这段旅程，了解为什么我们认为 Razorpay 应该存在这样一个团队，我们如何构建它，我们的使命、目标、原则、我们可以做得更好的事情以及我们下一步的发展方向。

为什么要组建前端核心团队？

多年来，随着新工具、框架、模式的出现和成熟，现代前端生态系统呈指数级增长。掌握现代前端堆栈对个人来说是一项巨大的努力。

Razorpay 的工程团队每年都在迅速扩大规模。在过去的两年里，仅我们的前端团队就增加了两倍多📈。

如果我们分解前端工程师的职责，就会做出各种各样的决定。

前端工程师的职责

 

• Front of Frontend：涉及构建产品、功能、用户界面、UI组件、可访问性、微交互等。
• 前端数据：涉及构建和管理客户端数据存储、状态管理、数据转换、与数据源交互、API 等。
• 前端骨干：涉及设置用于构建和部署应用程序的工具。包括为各种环境配置构建设置：本地、暂存、生产、设置测试框架、代码检查和格式化设置、添加 TypeScript 支持、设置 CI/CD 管道、设置工作流和 PR 检查。

Brad Frost 在他的博客中很好地介绍了这些内容。

我们提升了整个组织的前端工程师正在处理的问题，并创建了团队来建立基础。当时的想法是，只需要 4 名工程师来考虑前端构建工具，而不是 100 人。只有 2 名工程师需要考虑工具提示组件，而不是 50 人。我们建立了一个由专业工程师组成的团队，他们将在这些领域工作并构建一个我们前端堆栈的基础。

缺乏基础设施标准化

设置构建和部署的冗余工作。个别项目所有者必须深入研究这些方面。

缺乏设计一致性

我们在设计/开发过程中遇到了冗余，例如具有相同意图但具有不同变化的组件（按钮、输入字段、颜色等）

复杂的发布管理

复杂的构建和部署过程依赖于构建 ID、提交哈希、shell 脚本和脆弱的 CI 配置。在没有 SLI/SLA 的情况下，缺乏用于可预测错误和性能监控的可观察性工具。

缺乏测试框架

缺乏基础测试，在设置测试方面付出了多余的努力，单元/集成测试的摩擦很大。

复杂的本地环境设置

建立项目的学习曲线很高，本地环境需要很长时间才能构建，这会减慢开发速度，缺少项目指南。

旧版工作流程

让我们看看我们在组建前端核心团队之前遵循的日常工作流程，以及让我们放慢速度的漏洞是什么。

我们有很多移动的部分，它们很脆弱，也有巨大的学习曲线。 随着更多产品和团队的扩展，我们将重做相同的事情，失去在工具基础设施的帮助下自动化此工作流程中的许多部分的巨大潜力。

Lifecycle of frontend app in legacy workflow

涅槃工作流程

这是我们希望为 Razorpay 的所有产品实现的未来工作流程。 我们相信这将显着提高我们产品的开发效率、开发人员体验、可扩展性和性能。

Lifecycle of frontend app in the nirnava workflow

我们的旅程到目前为止 - 奠定基础

在回顾了我们在跨产品的前端工程方面的低效率之后，我们展示了我们的愿景以及我们如何通过以下方式使产品更具弹性和效率：

• 创建有关可以在开发工作流程中填补的空白的详细文档。
• 展示当前的挑战和我们对领导层的愿景
• 为在当前工作流程中投入的时间和金钱以及我们可以优化的地方创建成本估算。

一些单独尝试解决类似挑战的内部工程师聚集在一起建立了前端核心团队。我们实现了我们的愿景，为团队制定了年度目标和 OKR，并开始了这一旅程。

我们主要在两个轨道上工作：

• 工具和核心基础设施
• 设计系统

工具和核心基础设施

由明确标准管理的工具、实用程序和配置的瑞士刀。它们可以组合在一起以构建或扩展到任意数量的产品。

在内部，我们将此项目命名为 Frontend Universe。

我们创建了一个包含多个包的 monorepo，每个包都有自己的边界和范围。

我们的工具链由各种包组成，所有这些包都可以作为单独的包单独使用，也可以通过通用 CLI 使用。

Packages and modules in frontend CLI toolchain

• Universe-cli：所有包的脚手架和作曲家
• Universe-pack：构建由 webpack、babel、metro 组成的工具链。
• Universe-doctor：我们的内部医生诊断所有可能使我们的代码库不卫生的事情（linting、格式化、提交挂钩、PR 检查等）。
• Universe-test：测试环境的工具链（单元、集成和端到端）。
• Universe-utils：通用服务和实用程序，如分析、a/b 服务、错误监控服务等。

这类似于乐高模型（积木），我们提供一组具有合理默认值和接口的模块来扩展或增强它们。 这使产品团队能够专注于构建实际产品，而不必担心使用的底层部件。

Scaffolding a new project using Universe CLI

消费者可以搭建和创建新项目或集成特定模块以向现有项目添加功能。

我们构建了一堆工具、实用程序和配置：

CLI 脚手架

 

• 使用 React、React Native 为 Web 和移动设备搭建新项目。

CI/CD 设置

 

• 使用 GitHub Actions 和 Spinnaker 管道预配置的 CI/CD 工作流。
• Docker 构建、Kubernetes 配置、部署管道的自动设置。
• PR 检查以验证构建，使用 DangerJS 自动执行 PR 杂务。
• 使用变更集生成变更日志和发布的自动版本控制。

SSR（服务器端渲染）支持

 

• 具有代码拆分、路由和 Redis 缓存的 SSR 设置可提供出色的用户体验

监控/可观察性

 

• 使用 SpeedCurve、Sentry（带有源映射、堆栈跟踪和错误严重性）捕获性能和错误指标。

服务和配置

 

• 使用 ESLint、Prettier 和 Stylelint 进行 Linting
• 打字稿设置
• A/B 测试 SDK
• 用户事件分析 SDK
• 使用 DangerJS 自动化公关工作
• Monorepo 支持
• 移动应用程序的推送通知
• 像secretlint这样的安全机制
• 常用的实用程序，如 lodash、日期函数等。

所有这些功能都可以在新项目搭建时预配置开箱即用，也可以作为现有项目的可插拔模块使用。这种模型减少了现有项目在加入和迁移到这些新工具时的摩擦，而无需进行大的重构。

设计系统

设计系统是一套工具，由明确的标准管理，使我们的产品（跨平台——网络和移动）保持一致，减少消费者的学习曲线，提高设计师和开发人员的生产力。

我们设计系统的目标不仅限于为开发人员提供可重用的模式，而且还弥合了设计师+开发人员工作流程之间的差距，这促使我们跨越了从设计工具到源代码的界限。

Building apps using cross-platform design system

我们的重点是建立一个成熟的系统，在实施设计的同时简化设计人员的设计工具以及开发人员的生活，这反过来将增强这两个功能的体验，即更好的 DX（设计/开发体验） ) ➡️ 更好的用户体验。

• 我们从 MVP 开始，通过构建实际产品来展示设计系统的价值。
• 基于我们从 MVP 中学到的知识，我们退后一步，开始完善我们的核心原则，如颜色、排版、间距、边框等，然后从那里开始构建组件。

这让我们一瞥我们的前进方向：

Phases of Design System

如前所述，我们正在努力使我们的开发人员和设计体验变得更好。 这是我们构建的一个 Figma 插件的一瞥，它是为了让我们的设计令牌与我们的代码保持同步。 （这个插件也可以很容易地由设计系统设计师运行）。

Plugin to auto-sync tokens between Figma (Design) and GitHub (Code)

我们遵循的原则和实践

随着我们随着时间的推移建立和扩展前端核心团队，有一些原则可以帮助我们与我们的愿景保持一致：

• 一个拥有所有权心态的小型自治团队。
• 构建一个具有合理默认值的固执己见的工具链，但又足够灵活，可以根据产品需求对其进行塑造，从而帮助团队更快地交付和扩展。
• 通过提供集成可插拔模块或选定功能的接口来降低进入门槛。
• 将平台视为产品，将开发人员视为客户。经常收集反馈并进行迭代，增强它。
• 长期胜于短期。除了为今天构建弹性解决方案外，还要以将来可以扩展或增强的方式设计它们。
• 在构建大型功能之前，进行彻底的研究并从团队中的工程师那里获得早期反馈。为此，我们遵循 RFC 流程。请检查我们的设计系统的一些 RFC。
• 尽可能传福音。传播意识并宣布我们发布的主要功能，同时强调它所增加的价值。举办演示功能的会议。
• 教育和授权团队，分享学习以获取意见，通过提供协作帮助鼓励贡献，编写包含示例的文档、迁移指南、常见问题解答、故障排除指南等。
• 通过集中讨论、收集反馈、进行内部会议、进行公开讨论和在办公时间进行咨询，与其他团队互动以了解他们的问题。
• 识别早期采用者（即零客户），从他们那里获取反馈并迭代产品。这也有助于在整个组织的其他工程师之间建立牵引力。
• 除了构建工具外，还要制定指导方针以传播意识并鼓励组织内的正确使用和文化。

我们本可以做得更好吗？

 

• 足够早地传福音。在我们最初的阶段，我们更多地关注核心能力的建设，而对内部传播的重视不够。这对我们在季度/年度计划期间围绕采用率签署 OKR 产生了影响。
• 假设产品市场从第 0 天起就适合所有人。建立能力，他们就会来找你——这不是真的。每个工具都必须根据消费者和采用需求而发展。
• 测量标准化是困难的。很难找到影响指标并量化开发效率以及代码的标准化和质量。
• 通过做更多的 FGD 来捕捉团队的工程脉搏，捕捉 NPS。这将帮助我们确定我们的优先事项，并始终与消费者的需求保持同步。
• 尽可能地认可和奖励。庆祝采用的胜利，奖励核心以外团队的贡献者，宣传成就。这将大大提高内部牵引力，带来认可并鼓励更多的采用者和外部贡献者。

 

原文：https://engineering.razorpay.com/laying-the-frontend-foundations-with-a…

本文：https://jiagoushi.pro/node/2076

这是前端面试中必然会问到的问题

前端开发多年来一直在不断改进。从简单的静态页面到现在复杂的单页面应用程序，我们的工具变得越来越强大。现在，三大前端框架统治着前端开发，那么你知道这三个框架的区别吗？为什么一直保持着三足鼎立的局面，而不是某种框架来统一其他人？让我们在本文中讨论这些问题。

前端开发的演变

PHP && JSP

早些年，网页的动态内容是在服务器端渲染的，主要使用PHP、JSP等技术。

此时，服务器通过模板引擎填充数据，然后生成HTML，并将HTML返回给浏览器进行渲染。

<!DOCTYPE html>
<html>
<body><h1>My first PHP page</h1><?php
echo "Hello World!";
?></body>
</html>

AJAX

后来有了 AJAX 技术，JavaScript 可以直接在浏览器中发送异步 HTTP 请求，动态地从服务器获取数据，而不是把所有的数据都放在 HTML 中。

<body>
  <h2>Hello world</h2>
  <div id="demo"></div>
  <script>
    var xhttp = new XMLHttpRequest();
    xhttp.onreadystatechange = function () {
      if (this.readyState == 4 && this.status == 200) {
        // Typical action to be performed when the document is ready:
        document.getElementById("demo").innerHTML = xhttp.responseText;
      }
    };
    xhttp.open("GET", "/api/data", true);
    xhttp.send();
  </script>
</body>

最早的 AJAX 是基于 XML 的，所以现在我们用 JavaScript 发送 HTTP 请求时，使用的函数叫做 XMLHttpRequest。但是XML中有很多不必要的标签，浪费了服务器带宽，所以JSON格式的数据占据了主流位置。

DOM API && jQuery

过去开发网页时，主要是通过浏览器提供的DOM API来操作DOM。

但是 DOM API 比较繁琐，在不同的浏览器中存在兼容性问题。为了简化dom操作和兼容不同的浏览器，jQuery开始流行起来。在那个时候，jQuery可以说是前端开发者必学的技术。

$( "button.continue" ).html( "Next Step..." )

前端框架

然后在开发网页的时候，我们发现一个网页需要做的就是先从服务器获取数据，然后根据数据更新DOM。

而且这个过程是固定的。为了简化 DOM 操作，人们发明了 MVVM 框架来自动将数据更改映射到 DOM 更新，而无需手动操作 DOM。这就是前端框架 Angular、React、Vue 所做的。

import { useState } from 'react'function Counter() {
  
  const [count, setCount] = useState(0)  return (
    <div>
      <p>you clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>increase</button>
      <button onClick={() => setCount(count - 1)}>decrease</button>
  </div>)
}
export default Counter

同时前端框架也支持DOM的逻辑划分。我们可以将 DOM 的一部分封装成组件，将组件相互组合，形成整个应用程序。

这种思路让我们可以将一个复杂的页面拆分成不同的组件，方便我们开发项目。

 

React、Vue、Angular 之间的区别

这些前端框架主要使用以下思想：

UI = f(state)

我们只需要声明一个组件的状态、视图和组件之间的依赖关系，就会自动生成组件的UI。

尽管它们的核心思想相同，但这些框架的实现细节却有所不同。下面我们来分析一下。

React JSX 与 Vue 模板

React 和 Vue 在描述视图层时给出了不同的解决方案。 React 选择扩展 JavaScript 并引入 JSX。而 Vue 创建了一个独立的模板语法。

React JSX:

export default function TodoList() {
  let list = ['JavaScript', 'React', 'Vue']
  return <div>
    {
      list.map(item => <li>{ item }</li>)
    }
  </div>
}

Vue模板：

<ul id="array-rendering">
  <li v-for="item in items">
    {{ item.message }}
  </li>
</ul>

JSX 的优点：

• 在编写 JSX 时，开发人员可以使用他们现有的 JavaScript 知识，而无需太多额外的学习成本。
• JSX 可以利用 JavaScript 本身的特性，因此更加强大。
• JSX 代码和普通的 JavaScript 代码将在同一个执行上下文中执行，因此 JSX 可以很容易地与 TypeScript 结合。 Vue Template 和 JavaScript 执行上下文是分开的，所以在 Vuejs 中引入 TypeScript 比较困难。您需要分别声明 prop、method 和 data 的类型。

当然，Vue Template 也有自己的优势。由于 Vue Template 只能使用有限的语法，因此 Vue 可以更轻松地对其进行静态分析和性能优化，这在 JSX 中是很难做到的。

检查数据更新的不同方法

这三个前端框架都需要观察数据变化来决定是否需要更新 UI，但是他们选择了完全不同的方式来做这件事。

Angular 采用的方式是脏检查。每条可能修改数据的语句执行完毕后，Angular 都会对比前后的数据，判断是否有数据变化。

Vue 直接使用 JavaScript 的原生特性来监控数据变化。 Vue2 使用了 Object.defineProperty ，而 Vue3 使用了 Proxy。

另一方面，React 采取了不同的策略。 React 并不直接监控数据变化，而是在数据和 UI 之间添加了一个虚拟 DOM。每次组件应该更新后都会重新生成一个虚拟 DOM，React 会获取新虚拟 DOM 和旧虚拟 DOM 之间的差异。然后 React 决定是否以及如何更新真实的 DOM。

Vue 和 React 的优化

Vue 的数据监视是在组件级别。当组件内部有很多地方可以看数据变化时，一次更新可能需要大量的计算，这可能会导致丢帧，也就是渲染卡顿。所以Vue的优化方法是将大组件拆分成小组件，这样每个数据不会有太多的watcher。

React 不会观察数据变化，而是渲染整个虚拟 dom，然后进行 diff。所以 React 的优化方法是对于不需要重新渲染的组件，通过 shouldComponentUpdate 跳过渲染。

但是，当应用程序的组件树非常大的时候，仅仅使用 shouldComponentUpdate 来跳过一些组件的渲染，可能仍然是非常耗费计算量的。大量的计算也可能导致渲染冻结。那么我们应该怎么做呢？

树遍历有两种方法：深度优先和广度优先。组件树的渲染是深度优先的，一般通过递归来实现。递归调用不能暂停，可能会导致页面冻结。

但是如果我们用链表来记录访问路径，就可以把树的递归遍历变成数组的循环遍历。循环遍历数组时，可以根据时间片进行分段，这样虚拟dom的生成就不会再阻塞页面渲染了。这与操作系统对多个进程的分时调度非常相似。

将组件树变为链表，将virtual dom的生成由递归变为循环的机制有一个著名的名字：React Fiber。

与之前的组件节点相比，Fiber节点没有parent和children属性，但是有child、sibling和return属性。 React 通过 Fiber 链表树优化渲染性能。

在这里我们可以发现，Vue 的性能优化与 React 有很大的不同：

• Vue 使用组件级的数据监视解决方案。当一个属性有太多的watcher时，可能会出现性能瓶颈，所以优化思路是把大组件拆分成小组件，保证每个属性不会有太多的watcher。
• 但是，React 不会监视或检查数据更改。它每次渲染生成virtual dom，然后对比新旧virtual dom。优化思路是使用 shouldComponentUpdate 跳过部分组件的渲染。

重用代码的不同方法

组件之间会有一些共同的逻辑需要重用。 React 和 Vue 有不同的解决方案。

Vue的组件都是option对象的形式，所以很自然的想到通过对象属性来进行mixins进行逻辑复用。 Vue2组件的内部逻辑复用方案确实是mixin，但是mixin很难区分自己的属性和混合属性，也无法判断方法的来源。所以 mixin 的代码很乱，维护也很差。但是没有更好的解决方案。

React 在开始时也支持 mixins，但后来被弃用了。

React 组件有两种形式：类组件和函数式组件。对于类组件，像高阶函数这样的高阶组件（HOC）是重用代码的一种自然方式。具体来说，我们可以使用父组件包装子组件，在父组件中执行一些逻辑，然后渲染子组件。

除了使用 HOC，我们还可以直接将一些 JSX 作为 props 传递给另一个组件进行复用，也就是 render props。

HOC 和 render props 是 React 的类组件支持的两种逻辑复用方案。

原始功能组件是无状态的，仅作为类组件渲染的辅助而存在。

然而，HOC 的逻辑复用方式最终导致了组件的深度嵌套。而且，类的内部生命周期很多，把不同的逻辑放在一起会使组件更加复杂。

如何解决类组件的深度嵌套？并且解决方案不能进行重大更新。

所以 React 团队看了一下功能组件。他们希望在功能组件中扩展一些 API 以支持状态。

如果一个功能组件要支持状态，那么状态应该存储在哪里？

类组件本身是有状态的，成为纤节点后还是有状态的。功能组件一开始没有状态，成为光纤节点后也没有。

这样想，给功能组件的光纤节点添加状态还不够吗？

所以 React 将 memorizedState 属性添加到功能组件的一个 Fiber 节点中来存储数据，然后开发者可以通过 API 使用功能组件中的数据。这些 API 被称为 React Hooks。因为数据是在光纤节点上使用的，所以 API 被命名为 useXxx。

结论

三个前端框架各有优缺点。简单地比较谁更好是没有意义的。我们需要做的是为一个应用场景选择一个合适的解决方案。

技术在不断变化，但最终目的是提高工作效率，降低开发成本，保证质量。

原文：https://betterprogramming.pub/from-jquery-to-react-vue-angular-the-evol…

本文：https://jiagoushi.pro/node/2022

React是管理应用程序状态所需的全部内容

 

管理状态可以说是任何应用程序中最难的部分。这就是为什么有这么多的状态管理库可用，而且每天都有更多的库出现（甚至有些库是建立在其他库之上的。。。npm上有数百个“更简单的Redux”的摘要）。尽管状态管理是一个很难解决的问题，但我认为，使之如此困难的一个原因是我们经常过度设计解决问题的方法。

有一个状态管理解决方案，我个人一直在使用React，随着React钩子的发布（以及对React上下文的大量改进），这种状态管理方法已经大大简化。

我们经常把React组件当作乐高积木来构建我们的应用程序，我想当人们听到这些时，他们会认为这不包括状态方面。我个人解决状态管理问题的方法背后的“秘密”是考虑应用程序的状态如何映射到应用程序的树结构。

redux如此成功的原因之一是react redux解决了支柱钻井问题。事实上，通过简单地将组件传递到某种神奇的connect函数中，就可以在树的不同部分共享数据，这一点非常棒。它对reducer/action creators/etc.的使用也很棒，但我相信redux的普遍存在是因为它解决了开发者的道具钻削痛点。

这就是我只在一个项目中使用redux的原因：我经常看到开发人员把他们所有的状态都放到redux中。不仅是全局应用程序状态，还包括本地状态。这会导致很多问题，尤其是当您维护任何状态交互时，它涉及到与reducer、action creator/type和dispatch调用的交互，这最终导致必须打开许多文件并在头脑中跟踪代码，以确定发生了什么以及它对代码库其余部分的影响。

很明显，对于真正全局的状态来说，这是很好的，但是对于简单状态（比如模态是开放的还是表单输入值状态），这是一个大问题。更糟糕的是，它的规模并不是很好。应用程序越大，这个问题就越难解决。当然，您可以连接不同的reducer来管理应用程序的不同部分，但是间接遍历所有这些action creator和reducer并不是最佳的。

将所有应用程序状态都放在一个对象中也会导致其他问题，即使您没有使用Redux。当一个反应<提供程序上下文>获取一个新值，使用该值的所有组件都将更新并必须呈现，即使它是只关心部分数据的函数组件。这可能会导致潜在的性能问题。（React reduxv6也尝试使用这种方法，直到他们意识到它不能正确地与hooks一起工作，这迫使他们在v7中使用不同的方法来解决这些问题。）但我的观点是，如果您的状态在逻辑上更为分离，并且位于React树中更靠近它的位置，那么就不会出现这个问题。

这是真正的关键，如果您使用React构建应用程序，那么您的应用程序中已经安装了状态管理库。你甚至不需要npm安装（或纱添加）它。它不需要为用户额外增加字节，它与npm上的所有React包集成，而且React团队已经对它进行了很好的记录。它自己反应。

React是一个状态管理库

当您构建React应用程序时，您将组装一组组件，以组成一个组件树，从<App/>开始，到<input/>、<div/>和<button/>结束。您不需要在一个中心位置管理应用程序呈现的所有低级复合组件。相反，你让每个单独的组件来管理它，它最终成为构建UI的一种非常有效的方法。你也可以用你的状态来做这件事，而且很可能你今天也会这样做：

function Counter() {

  const [count, setCount] = React.useState(0)

  const increment = () => setCount(c => c + 1)

  return <button onClick={increment}>{count}</button>

}

function App() {

  return <Counter />

}

请注意，我在这里所说的一切也适用于类组件。钩子只是让事情变得简单一点（特别是我们马上要讨论的上下文）。

class Counter extends React.Component {

  state = {count: 0}

  increment = () => this.setState(({count}) => ({count: count + 1}))

  render() {

    return <button onClick={this.increment}>{this.state.count}</button>

  }

“好吧，Kent，在一个组件中管理一个状态元素是很容易的，但是当我需要跨组件共享状态时，您会怎么做？例如，如果我想这样做呢：“

function CountDisplay() {

  // where does `count` come from?

  return <div>The current counter count is {count}</div>

}

function App() {

  return (

    <div>

      <CountDisplay />

      <Counter />

    </div>

  )

 

“计数是在<Counter/>中管理的，现在我需要一个状态管理库从<CountDisplay/>访问该计数值并在<Counter/>中更新它！”

这个问题的答案和反应本身一样古老（旧？）在我记事的时候，我就在文档里写了很久：提升状态

“提升国家”合法地回答了React中的国家管理问题，这是一个坚如磐石的答案。以下是如何将其应用于这种情况：

function Counter({count, onIncrementClick}) {

  return <button onClick={onIncrementClick}>{count}</button>

}

function CountDisplay({count}) {

  return <div>The current counter count is {count}</div>

}

function App() {

  const [count, setCount] = React.useState(0)

  const increment = () => setCount(c => c + 1)

  return (

    <div>

      <CountDisplay count={count} />

      <Counter count={count} onIncrementClick={increment} />

    </div>

  )

}

我们刚刚改变了谁对我们的国家负责，这真的很简单。我们可以一直提升状态，直到我们的应用程序的顶端。

“当然肯特，好吧，但是道具钻的问题呢？”

好问题。您的第一道防线就是改变构建组件的方式。利用组件组成。也许不是：

function App() {

  const [someState, setSomeState] = React.useState('some state')

  return (

    <>

      <Header someState={someState} onStateChange={setSomeState} />

      <LeftNav someState={someState} onStateChange={setSomeState} />

      <MainContent someState={someState} onStateChange={setSomeState} />

    </>

  )

}

你可以这样做：

function App() {

  const [someState, setSomeState] = React.useState('some state')

  return (

    <>

      <Header

        logo={<Logo someState={someState} />}

        settings={<Settings onStateChange={setSomeState} />}

      />

      <LeftNav>

        <SomeLink someState={someState} />

        <SomeOtherLink someState={someState} />

        <Etc someState={someState} />

      </LeftNav>

      <MainContent>

        <SomeSensibleComponent someState={someState} />

        <AndSoOn someState={someState} />

      </MainContent>

    </>

  )

}

如果这不是很清楚（因为它是超级做作），迈克尔杰克逊有一个伟大的视频，你可以看，以帮助澄清我的意思。

不过，最终，即使是组合也不能为您做到这一点，所以您的下一步是跳转到React的Context API中。这实际上是一个“解决方案”，但很长一段时间以来，这个解决方案是“非官方的”。正如我所说，很多人求助于react redux，因为它使用我所指的机制解决了这个问题，而不必担心react文档中的警告。但是，既然context是React API的一个官方支持的部分，那么我们可以直接使用它而没有任何问题：

// src/count/count-context.js

import * as React from 'react'

const CountContext = React.createContext()

function useCount() {

  const context = React.useContext(CountContext)

  if (!context) {

    throw new Error(`useCount must be used within a CountProvider`)

  }

  return context

}

function CountProvider(props) {

  const [count, setCount] = React.useState(0)

  const value = React.useMemo(() => [count, setCount], [count])

  return <CountContext.Provider value={value} {...props} />

}

export {CountProvider, useCount}

// src/count/page.js

import * as React from 'react'

import {CountProvider, useCount} from './count-context'

function Counter() {

  const [count, setCount] = useCount()

  const increment = () => setCount(c => c + 1)

  return <button onClick={increment}>{count}</button>

}

function CountDisplay() {

  const [count] = useCount()

  return <div>The current counter count is {count}</div>

}

function CountPage() {

  return (

    <div>

      <CountProvider>

        <CountDisplay />

        <Counter />

      </CountProvider>

    </div>

  )

}

注意：这个特定的代码示例非常做作，我不建议您使用上下文来解决这个特定的场景。请阅读支柱钻井，以获得更好的理解为什么支柱钻井不一定是一个问题，往往是可取的。不要太快接触上下文！

这种方法的酷之处在于，我们可以将更新状态的常用方法的所有逻辑放在useCount钩子中：

function useCount() {

  const context = React.useContext(CountContext)

  if (!context) {

    throw new Error(`useCount must be used within a CountProvider`)

  }

  const [count, setCount] = context

  const increment = () => setCount(c => c + 1)

  return {

    count,

    setCount,

    increment,

  }

}

你也可以很容易地用这个来说明：

function countReducer(state, action) {

  switch (action.type) {

    case 'INCREMENT': {

      return {count: state.count + 1}

    }

    default: {

      throw new Error(`Unsupported action type: ${action.type}`)

    }

  }

}

function CountProvider(props) {

  const [state, dispatch] = React.useReducer(countReducer, {count: 0})

  const value = React.useMemo(() => [state, dispatch], [state])

  return <CountContext.Provider value={value} {...props} />

}

function useCount() {

  const context = React.useContext(CountContext)

  if (!context) {

    throw new Error(`useCount must be used within a CountProvider`)

  }

  const [state, dispatch] = context

  const increment = () => dispatch({type: 'INCREMENT'})

  return {

    state,

    dispatch,

    increment,

  }

}

这为您提供了极大的灵活性，并将复杂性降低了一个数量级。在这样做的时候，要记住以下几点：

• 并非应用程序中的所有内容都需要处于单个状态对象中。保持逻辑上的分离（用户设置不必与通知处于同一上下文中）。使用此方法将有多个提供程序。
• 不是所有的上下文都需要全局访问！让状态政府尽可能靠近需要的地方。

关于第二点的更多信息。你的应用程序树可能如下所示：

function App() {

  return (

    <ThemeProvider>

      <AuthenticationProvider>

        <Router>

          <Home path="/" />

          <About path="/about" />

          <UserPage path="/:userId" />

          <UserSettings path="/settings" />

          <Notifications path="/notifications" />

        </Router>

      </AuthenticationProvider>

    </ThemeProvider>

  )

}

function Notifications() {

  return (

    <NotificationsProvider>

      <NotificationsTab />

      <NotificationsTypeList />

      <NotificationsList />

    </NotificationsProvider>

  )

}

function UserPage({username}) {

  return (

    <UserProvider username={username}>

      <UserInfo />

      <UserNav />

      <UserActivity />

    </UserProvider>

  )

}

function UserSettings() {

  // this would be the associated hook for the AuthenticationProvider

  const {user} = useAuthenticatedUser()

}

 

请注意，每个页面都可以有自己的提供程序，其中包含其下组件所需的数据。代码拆分对这种东西也“管用”。如何将数据导入每个提供程序取决于这些提供程序使用的钩子以及如何在应用程序中检索数据，但您知道从何处开始查找（在提供程序中）如何工作。

关于为什么这个托管是有益的，请查看我的“State colosition will make your React app faster”和“colocation”博客文章。有关上下文的更多信息，请阅读如何有效地使用React context

服务器缓存与UI状态

最后我想补充一点。状态有多种类型，但每种类型的状态都可以分为两种类型：

• 服务器缓存—实际存储在服务器上的状态，我们将其存储在客户机中以便快速访问（如用户数据）。
• UI状态—仅在UI中用于控制应用程序交互部分的状态（如模态isOpen状态）。

当我们把两者结合在一起时，我们犯了一个错误。服务器缓存与UI状态有着本质上不同的问题，因此需要进行不同的管理。如果你接受这样一个事实：你所拥有的根本不是状态，而是一个状态缓存，那么你就可以开始正确地思考它，从而正确地管理它。

当然，您可以使用自己的useState或useReducer在这里和那里使用正确的useContext来管理它。但请允许我帮你直截了当地说，缓存是一个非常困难的问题（有人说它是计算机科学中最难的问题之一），在这个问题上站在巨人的肩膀上是明智的。

这就是为什么我对这种状态使用并推荐react query。我知道我知道，我告诉过你不需要状态管理库，但我并不认为react query是状态管理库。我认为这是个藏匿处。这真是个好主意。看看！坦纳·林斯利是个聪明的小甜饼。

性能怎么样？

当你遵循上面的建议时，性能就很少是个问题了。尤其是当你遵循有关托管的建议时。但是，在某些用例中，性能可能会有问题。当您遇到与状态相关的性能问题时，首先要检查的是有多少组件由于状态更改而被重新呈现，并确定这些组件是否真的需要由于状态更改而重新呈现。如果是这样，那么perf问题不在管理状态的机制中，而是在渲染速度上，在这种情况下，需要加快渲染速度。

但是，如果您注意到有许多组件在没有DOM更新或需要的副作用的情况下进行渲染，那么这些组件将不必要地进行渲染。在React中，这种情况一直都会发生，而且它本身通常不是问题（您应该首先集中精力快速进行不必要的重新渲染），但是如果这真的是瓶颈，那么以下是一些在React上下文中使用state解决性能问题的方法：

• 将你的状态划分为不同的逻辑部分，而不是在一个大的存储区中，这样对状态的任何部分进行一次更新都不会触发对应用程序中每个组件的更新。
• 优化上下文提供程序
• 把 jotai带进来

这又是一个库的建议。的确，有些用例React的内置状态管理抽象不太适合。在所有可用的抽象中，jotai对于这些用例是最有前途的。如果您想知道这些用例是什么，那么jotai很好地解决的问题类型实际上在 Recoil: State Management for Today's React - Dave McCabe aka @mcc_abe at @ReactEurope 2020一书中得到了很好的描述。Recoil和jotai非常相似（并且解决了相同类型的问题）。但根据我和他们的（有限）经验，我更喜欢jotai。

无论如何，大多数应用程序都不需要像recoil或jotai这样的原子状态管理工具。

结论

同样，这是你可以用类组件来做的事情（你不必使用钩子）。钩子使这变得容易得多，但是您可以用React 15来实现这一理念。尽可能保持状态的本地性，并且只有在支柱钻井成为问题时才使用上下文。这样做会使您更容易维护状态交互。

 

原文：https://kentcdodds.com/blog/application-state-management-with-react/

本文：http://jiagoushi.pro/node/1282

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

 

Monolith Lake — snarbaz

 

敏捷的思维方式促进了对流程，产品和业务的迭代。如今，随着时间的推移，渐进式架构正在实现架构的渐进式变革。

迁移大型整体的最常用方法是：

1. Big Bang：包括从头开始迁移遗留系统。风险很高，因为没有记录的功能可能会丢失，并且价值交付会下降，因为当时需要在两个系统上实现即将推出的功能，或者根本不需要。
2. Strangler：包括稳定地迁移遗留系统将责任转移到新系统或服务，我喜欢将遗留代码称为服务。这种方法需要更多时间来扼杀巨石，但能够持续提供价值。

 

扼杀Monolith应用程序的旅程

现在可以很容易地选择Nuxt.js和Next.js这样的框架来使用React和Vue.js进行通用渲染页面，也称为同构应用程序，但是对于使用自己的模板引擎的框架来说很困难，而对于非javascript则更难Ruby on Rails，Laravel或Flask等框架。

Airbnb + Hypernova作为案例研究

Airbnb一直在稳步迁移基于Ruby on Rails构建的系统，将前端代码转换为使用Hypernova作为服务器端渲染服务的一致架构。

 

1. 用户在Ruby on Rails服务器上请求页面。
2. 服务器收集必要的数据以呈现页面。
3. ERB模板使用自定义渲染器向Hypernova服务器请求组件。
4. Hypernova服务器使用React呈现所有请求的组件，并将它们发送回Ruby on Rails服务器。
5. ERB在生成的页面中注入组件。
6. Ruby on Rails将HTML标记和javascript文件发送回浏览器。
7. 在浏览器上，JavaScript用于逐步增强应用程序并使其动态化。

使用这种架构，Airbnb可以将其React组件重用于服务器端和客户端呈现，并将基于Ruby on Rails构建的Monolith的展示层解耦。

这是Airbnb工程团队撰写的详细文章。

在Laravel上使用Hypernova

Laravel是一个PHP Web框架，用于构建类似于其他框架（如ASP.net MVC，Ruby on Rails和AdonisJS）的现代Web应用程序。

Laravel使用Blade作为服务器端渲染的模板引擎，Laravel Mix使用Javascript，CSS和Vue.js组件等资源进行客户端渲染。

支持Hypernova上的Vue.js.

Airbnb Hypernova不支持开箱即用的Vue.js，但它使我们能够开发自己的Hypernova绑定，所以我创建了hypernova-vue。

我写了这篇关于如何将Vue.js与Hypernova一起使用的文章，你也可以使用这个生成器。

第一种方法 -  Hypernova客户端

将Hypernova服务器配置为使用Vue.js后，我在Blade中创建了一个自定义指令，以便将超新星组件放入Blade视图中。

Hypernova指令使用一个Facade，它将请求的组件推送到hypernova-php客户端，并在模板视图中添加一个占位符，以便稍后放置渲染的组件。

hypernova客户端是一个单例，因此我们可以持久保存所请求的组件，以便稍后从hypernova服务器获取它们。

最后，Blade基于模板视图呈现页面，Laravel中间件使用Facade修改原始响应。 场景背后的Facade使用Hypernova客户端向Hypernova服务器请求组件，并仅在一步上用所呈现的组件替换占位符。

我采用了laravel-hypernova包的一些想法，但我没有使用它，因为该库与Laravel 5.8不兼容，我遇到了处理来自hypernova服务器的传入错误的问题。

使用Hypernova指令

Laravel控制器只需要使用视图功能将视图名称和数据传递给Blade。

默认布局包含HTML文档，并使用hypernova指令定义NavBar组件。

 

欢迎视图使用默认布局，并使用hypernova指令定义Home组件。

呈现HTML后，结果如下：

该页面是服务器端呈现和客户端动态使用相同的Vue.js组件，这对于SEO非常酷。

我使用Hypernova服务器启用了Laravel通用渲染Vue.js组件，但它仍然与一些实现细节相关联。 Laravel需要使用Hypernova客户端直接与Hypernova服务器交互，因此该架构需要为每种语言或Web框架开发Hypernova客户端。

Hypernova代理方法

在深入分析了架构之后，我发现了一个与微前端原则密切相关的通用通信接口。

 

Blade生成的HTML包含占位符，其中包含生成批量请求到Hypernova服务器所需的所有信息，即使超新星服务器无法呈现视图，客户端脚本也会在浏览器上呈现组件，使前端具有弹性。

基于Laravel中间件方法，我决定在客户端和Laravel应用程序之间放置一个反向代理，以便服务器端包含（SSI）来自Hypernova服务器的视图。

我尝试使用OpenResty对Nginx进行扩展，但是我发现了使用HTML解析器和Lua的HTTP客户端的一些实现约束。

最后，在研究了很多之后，我决定选择Go来开发它。 Go有一个开箱即用的HTTP客户端和反向代理服务器模块，以及一个非常酷的库，可以使用查询选择器解析和改变DOM。

Hypernova代理如何工作

使用Hypernova代理Laravel只需要使用Hypernova指令，以便将Hypernova代理用于服务器端的占位符包含在页面中的Hypernova视图中，就像我们之前使用Laravel中间件一样，但现在我们可以重用Hypernova代理命令使用其他Web框架来通用渲染视图。

Hypernova代理

用户请求Hypernova代理上的页面

Hypernova代理将请求传递给Laravel服务器。

Laravel服务器收集渲染页面所需的数据。

Blade使用模板vue和hypernova指令呈现页面（div标签包含组件的唯一ID和名称，脚本标签包含组件的数据）

Laravel服务器将HTML页面发送回Hypernova代理。

当响应content-type是text / html时，Hypernova代理解析HTML以便为Hypernova服务器创建JSON请求，否则，它会在不修改响应的情况下发回响应。

Hypernova代理请求Hypernova服务器的视图。

Hypernova服务器使用Vue.js组件呈现所有请求的视图，并将它们发送回Hypernova代理。

Hypernova代理使用成功结果的HTML替换占位符，并保留错误结果的占位符，以使客户端脚本在浏览器中呈现它们。

Hypernova代理将修改后的响应发送回用户。

在浏览器上，JavaScript用于逐步增强应用程序并使其动态化。

结论

这种架构可以轻松地将域从monolith分发到新服务，我们还可以开发新服务，例如使用Express.js和Mustache.js partials来生成Hypernova Proxy向Hypernova Server请求视图所需的预期标记。

 

Resources

• Building Evolutionary Architectures
• Operationalizing Node.js for Server Side Rendering
• Strangler Application
• Using Vue.js with Hypernova Server
• Micro-frontends using Vue.js, React.js, and Hypernova

 

原文：https://itnext.io/strangling-a-monolith-to-micro-frontends-decoupling-presentation-layer-18a33ddf591b

本文：http://pub.intelligentx.net/node/516

讨论：请加入知识星球或者小红圈【首席架构师圈】

这些天你一定听说过很多关于单页应用程序的愤怒，如果你没有听说过，你可能生活在岩石下。

SPAs提供了许多好处，比如无缝流畅的用户体验、易于开发、简化调试和重用相同的代码来构建移动应用程序。您经常使用的许多应用程序都是单页应用程序。举几个例子:Facebook、Twitter、Gmail、谷歌文档等等。

(Google Docs)

毫无疑问，SPA是这些天的图表杀手，每个人都想要它的业务。但是，在您雇佣web开发公司来构建一个SPA之前，您必须了解SPA是适合您的业务需求，还是传统的多页面web应用程序工作得更好。

要回答这个问题，首先让我们了解web应用程序的类型。

Web应用程序的类型

web的诞生引入了超文本文档，但这些文档被复杂且功能丰富的web应用程序所取代。当前的web应用程序开发场景可以分为两种方法。它们是:

1. 多页面应用程序
2. 单页面应用程序

什么是多页应用程序?

多页面应用程序是传统的web应用程序，它在用户与web应用程序交互时重新加载整个页面并显示新的页面。

每次来回交换数据时，都会从服务器请求一个新页面，以便在web浏览器中显示。这个过程需要时间在服务器上生成页面，将其发送到客户机并在浏览器中显示，这可能会影响用户体验。

然而，AJAX使呈现应用程序的特定组件成为可能，但这使得开发过程更加困难和复杂。

多页面应用程序的优点

1. 在搜索引擎上表现良好。
2. 为用户提供web应用程序的可视化地图。

多页面应用程序的缺点

1. 相对复杂的开发
2. 耦合后端和前端

什么是单页应用程序?

顾名思义，单页面应用程序只包含一个页面。SPAs以一种简单、优雅和有效的方式呈现内容，因为它只在一个页面上加载所有内容，而不是将用户导航到不同的页面。

SPAs比传统web应用程序更快，因为它们在web浏览器本身而不是在服务器上执行逻辑。在初始页面加载之后，只来回发送数据，而不是整个HTML，这会减少带宽。

单页应用程序的优点

1. 1. 单页应用程序流畅而快速。
2. 2. 它们易于开发和部署。
3. 3.spa更容易调试。
4. 4. 可以通过重用相同的后端代码转移到移动应用程序。

单页应用程序的缺点

1.  spa在搜索引擎上表现不佳。但是现在，使用同构呈现/服务器端呈现，甚至SPAs也可以为搜索引擎进行优化。
2.  单页面应用程序提供单共享链接。
3. 由于其跨站点脚本，与传统的多页面应用程序相比，它们的安全性更低。

那么，你应该选择SPA吗?

虽然单页应用程序方法可以用于构建任何类型的web应用程序，但是在开始之前必须考虑以下几点。

首先，你需要列出你在你的web应用程序中需要的功能和功能。例如，您的站点是内容密集还是图形密集?还是两个?所有的图形和内容都可以适当地放在一个页面上吗?

您的业务是否涉及特定的产品或服务，或者您提供各种产品和服务。如果您的业务只处理一个产品，那么没有什么比一个页面应用程序更完美的了。然而，如果您的企业提供各种服务或产品，那么您肯定需要通过使用多页面应用程序将它们划分为不同的页面，从而对每一个服务或产品给予重视。这甚至可以为您提供每个页面的深度链接。

(Trello -单页申请)

您想为用户提供不刷新页面的实时体验吗?例如，一个实时汽车配置器。查看我们为Rezvani制作的单页实时汽车配置器。

(Techuz的Rezvani实时汽车配置器)

如今的Web应用程序，无论是spa还是MPAs，都非常复杂、功能丰富，并且提供了令人惊叹的用户体验。因此，为了最大限度地利用这两种方法，您必须考虑您的业务和客户的需求。上面，我们试图介绍一些主要因素，这些因素可以帮助您在单页应用程序和传统的多页应用程序之间进行选择，从而为您的业务带来最大的好处。如果您仍然有任何问题，请毫不犹豫地联系经验丰富的web开发公司，如Techuz InfoWeb。

 

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

 

Angular、Vue、React、Ember、Preact和Svelte都有各自的优势，但哪一个适合您的下一个Web开发项目？

Angular vs.Vue vs.React vs.Ember vs.Preact vs.Svelte（pheew，在本次更新中添加了最后2项之后，即使是将jQuery委托给了历史，这也算是满嘴口水了！）是一个开发团队和产品所有者在每个新的web开发项目开始时必须问自己的一个问题。每一个流行的JavaScript框架和库都有各自的优缺点。不同的开发者、产品所有者和管理层在不同的选择上都有自己的舒适区和意见。

在我们将要介绍的JS框架和库中，Ember无疑已经达到了顶峰，现在正处于其活跃使用和普及周期的下降曲线上。2019年底发布的Ember Octane有望重回正轨，并吸引一批利基追随者。这似乎是在胡说八道，但现在就完全停止谈论Ember 还为时过早。

 

jQuery在这篇文章的前一个版本中已经讨论过了，但是我们已经把它放在这里了。这个库仍然用于一些需要支持旧浏览器的遗留应用程序，但是对于处理浏览器间互操作性问题的抽象层的需求现在基本上是多余的，jQuery也是如此。

其他的，Svelte 的和Preact的，是新鲜的感觉而且刚刚开始有了一个势头。他们可能会也可能不会继续严重挑战React、angle和Vue.js版当它们成熟的时候。

但如果只谈论React、Vue和Angular的话，那就太无聊了。Ember有一个重要的遗产，并仍将看到市场的需求一段时间，即使它看起来似乎它也在它的方式，随着技术的车轮转动。另一方面，Preact和Svelte才刚刚开始他们的旅程。它们正在制造一些噪音，但它们是否会成为公认的React、angle和Vue.js在企业层面。实际情况是，如果没有科技巨头的支持，比如谷歌对Angular和Facebook对React的积极支持，组织将新的框架和库视为一种战略风险，即使他们很欣赏自己的技术素质。

组织如何决定使用哪种JavaScript框架或库？

对于一个特定的前端开发项目，做出一个明智的决定，这是任何规划过程开始时的首要任务之一。有许多不同的考虑因素可以并且确实会影响对JS框架/库的选择的最终决定，这些JS框架/库将用于任何给定的前端项目。

当然，在所需功能组合的背景下，技术质量、利弊是在Angular、Vue、Ember和其他产品之间进行选择的一个重要因素。但是，假设每个前端项目选择JS框架归根结底都是对技术质量和特性的分析，这是过于简单的。

可以说，特定框架的优势使其在特定前端开发项目的上下文中具有优势。但是最流行的JavaScript框架和库都非常灵活，而且本身就令人印象深刻。最终的选择通常归结为更广泛的商业案例决策和实践性。

在框架之间的决策过程中，往往可以证明具有决定性的其他因素包括：

• 组织政策，即“我们在前端开发中使用React，除非有特别令人信服的原因说明应用程序无法实现所需的功能”。
• 开发资源的可用性，即“我们目前内部有Angular专家”或“我们的IT外包合作伙伴有Vue.js版团队可在接到通知后立即开始工作。
• 能否经得住时间的考验。将React构建的应用程序更新到框架的最新迭代比使用Angular、Vue.js或Ember要容易得多。从中期到长期来看，框架的积极支持和开源社区参与有多稳定?
• 开发商人气。招募和留住开发人员使用最流行的JS框架更容易。更多具有特定框架经验的开发人员也有助于将成本控制在合理的框架内。

本博客的目的不是试图客观地确定当前使用最多的JavaScript框架/库中哪一个是最好的。原因很简单，当代前端JS生态系统的美丽之处在于它的成熟性——在考虑大多数应用程序的技术需求时，有一些优秀的框架可供选择。

如前所述，在新项目中使用哪个JS框架或迁移遗留应用程序的决定通常与技术利弊一样取决于战略商业案例因素。

但我们要做的是，在React、Angular和，Vue.js还有Ember以及影响这些趋势的因素。这将有助于深入了解可能影响您决策的战略考虑因素。

我们还将全面概述这些框架的技术优势和弱点。这些质量将有助于确定特定框架选择对特定应用程序的适用性，在战略商业案例考虑中所有因素都是平等的。

我们能帮你吗

JavaScript用于什么？

在快速了解主流JavaScript框架生态系统的竞争优势之前，有必要先简单介绍一下JavaScript本身，然后问一下JavaScript作为编码语言的用途是什么？这将为我们深入研究JS库和框架本身提供上下文。

JavaScript最早发布于25年前，自那以后的几年里，JavaScript被认为是web开发的改头换面。尽管有着令人困惑的相似名称，JS完全不同于Java，后者是sunmicrosystems在同一时间发布的通用编程语言。它们唯一真正的共同点是它们都是为跨平台开发而设计的。

简而言之，JavaScript创建者Brendan Eich的目标是使网站更具交互性，改善用户体验。JavaScript在其诞生的头10年里获得了广泛的关注，但可以说微软2005年发布的AJAX才是真正的突破。

AJAX导致微软在其internetexplorer脚本中添加了XMLHttpRequest，这意味着可以通过从服务器下载新数据来实时更新实时web页面的HTML。再也不需要完全重新加载一个web页面来获取新的数据进行更新。其他浏览器很快就采用了suite，网站和服务器之间的异步通信成为了一种常态。

结果是出现了一种新的高度互动的应用程序，如谷歌地图和Gmail，紧随其后的是Facebook等。Google通过创建V8浏览器和解释器，进一步推动了JavaScript作为首选前端语言的采用率。它通过将JS编译成机器代码来弥补JavaScript的弱点，而不是在移动中实时解释它。

随着JS在过去的几年中逐渐成熟，并产生了开源插件，包括节点.js服务器环境和React原生移动应用框架，它已经不仅仅是一种编程语言。今天JavaScript是连接前端和后端、web和移动、基于浏览器和本地应用程序开发的桥梁。

 

JavaScript库和框架到底是什么？

编程语言、库和框架之间的区别最初可能会令人困惑。非技术管理人员通常认为React、Angular，Vue.js,Ember和jQuery是编程语言。

当然，他们不是。JavaScript是编程语言，以上都是基于JS的框架和库。但是，库和框架已经成为当代web和应用程序开发的标准，因为使用它们可以使软件开发更容易、更快，而且直接的结果是成本更低。

但是到底什么是库和框架？

什么是JavaScript库？

库是预先编写的执行常用JS函数的“代码片段”的集合。这些代码片段像乐高积木一样被用来构建更复杂的函数配置。例如，如果希望应用程序的搜索函数提供自动完成功能，则会插入一段库代码。

最终，库提供的代码片段可以加快构建整个项目的过程。但它们并不是一颗银弹，可以用来从头到尾格式化一个复杂的应用程序。

React、Preact和jQuery都是JavaScript库的示例。

什么是JavaScript框架？

另一方面，JS框架是一个完整的工具箱，可以用来创建网站或应用程序。一个很好的类比是把图书馆想象成房子的固定装置、装置和家具。而框架更像是用来建造预制建筑的模板和构件。

JS框架提供了构建整个web开发项目的框架。框架提供了页面模板，这些模板为以自定义代码的形式插入的详细信息留出了空间。这与使用库不同，在库中开发人员决定在哪里添加代码段。

框架的优势在于它提供了大量的效率和组织。代码结构良好，框架为经常遇到的编码挑战提供了开箱即用的解决方案。框架的缺点是它允许的灵活性较低。用户体验和功能的附加定制编码仅限于框架设计允许插入的地方。

框架和自由度必须根据具体的规则和规则进行调整，但必须根据具体的规则和规则进行调整。可以说，实际上，没有JavaScript框架真正符合“框架”的严格定义。正如StackOverflow上很好地解释的：

“软件框架的一个重要特征是其代码不受修改。在JavaScript中，显然不是这样。任何可以被调用到客户端代码中的库或框架都是可以修改的，尽管修改它们是不符合最佳实践的”。

框架：

• 侦听web请求
• 处理会话
• 调用代码来处理请求

框架调用应用程序的代码。但如果您使用的是库，则应用程序会从库中调用代码片段。

Java Brains的这段解释视频对JavaScript库和JavaScript框架之间的区别进行了更全面的解释：

 

 

Angular、Vue和Ember是JS“框架”的例子。Svelte，这个街区的新成员，被描述为一个“组件框架”。当我们更详细地看斯维特的时候，我们将更详细地了解这实际上意味着什么。

• Angular
• Ember JS
• Vue.js

你什么时候会选择JavaScript库，什么时候选择开发项目的框架？

对于什么时候选择JavaScript库，什么时候为特定项目选择一个框架，没有黑白对错的答案。但是根据经验，如果一个应用程序的业务和技术案例意味着您愿意在框架的限制下工作，并失去一些控制权以换取资源效率，那么使用JS框架是有意义的。

如果你想要更大的控制力和灵活性，并且愿意花更多的时间以你想要的方式组装你的应用程序，那么库在这种情况下可能更有意义。

Angular，Vue.js，React，Preact，Ember，Svelte:2020年哪个JavaScript框架最受欢迎？为什么？

在接下来的几个月里，任何一个接近web开发项目的人都会在React、Angular和，Vue.js,Ember，纤细或预燃。我们已经解决了一个非常近似的问题：何时选择JavaScript库，如React或Preact，何时选择Angular、Vue、Ember或Svelte。

现在我们将更仔细地看一下各个选项的相对优势和劣势。但作为一个介绍，让我们看看市场的更广泛的趋势。

开发人员对六大JavaScript框架和库的认识

当然，开源JavaScript框架和库比我们这里关注的6个还要多。例如，主干和米特里尔都有活跃的社区和信徒。但是，将我们的注意力集中在JavaScript状态报告所涵盖的那些方面是有意义的。缺乏在较小的框架和库方面拥有专业知识的开发人员意味着组织使用它们是不寻常的。

下图显示了全球数千名国际JS开发人员对主要框架和库的认识水平，这些开发者为sojs2019报告做出了贡献。它清楚地表明了Ember是如何在过去几年失去人气，与Vue.js版篡夺了它在第一桌的位置。它也展示了Preact和Svelte如何像几年前的Vue一样迅速出现在现场，并对JS景观产生了真正的影响。

下一张图很好地代表了开发者对这六种产品的看法，这可能是一个重要的线索，说明几年后每种产品的使用范围有多广。

我们可以看到React不仅应用非常广泛，几乎80%的JS开发人员都用它编写过代码，而且满意度很高。下一个方面是使用Angular，超过60%的JS开发人员已经使用了这个框架。

但是，尽管它作为付费和管理开发项目的一种选择很受欢迎，开发人员自己在对待Angular的态度上表现出相对较高的焦虑。大约58%的开发人员使用了Angular，接近三分之二的人说他们不想再这样做了。

他们的抱怨显然阻碍了其他人获得Angular方面的经验。那些还没有使用过它的人和那些没有打算或希望在将来使用它的人数是那些没有使用它但想学习Angular的人的三倍多。

这与Vue.js版. 大约有45%的JS开发者使用过Vue，但仍然相对较高，但大多数人对该框架持积极态度，并希望继续使用它。那些没用过的人Vue.js版然而，与那些不愿意的开发者相比，未来愿意加入的开发者要多出近两倍。

几乎10%的JavaScript开发人员从未听说过Ember，这表明它的流行度和相关性正在下降。在实际使用过Ember的JS开发人员中，有12%的人愿意再次使用Ember。超过80%的使用过Ember的大多数人不想再使用它。大多数熟悉Ember但没有使用过Ember的开发人员对此不感兴趣。

在这两个年轻的假装者中，斯维特周围的情绪最为积极。在使用过Svelte的7%左右的JavaScripts开发人员中，只有一小部分表示他们不想再使用了。其他人对新框架持积极态度。在那些还没有使用过但听说过它的人中，愿意在将来使用它的人比那些不感兴趣的人多出两倍。这可以被认为是基于听到了积极的事情。

Preact的情况大致相同，除了那些还没有使用过这个库的开发人员，与对Svelte的热情相比，对将来使用这个库的兴趣更少。

开发者2020年对Angular，Vue.js，React、Preact、Ember和Svelte的需求

主动的JavaScript开发人员经常在空闲时间探索和熟悉新的框架和库，并在个人项目中使用它们。但是，从利基到主流意味着公司和组织在开发新应用程序时选择使用框架或库。

这才是真正的考验。雇主们是想雇佣苗条的开发人员呢？就业市场上还需要灰烬技能吗？让我们看看。

StackOverFlow上公布2020年8月Angular，Vue.js，React、Preact、Ember和Svelte 公开的职位数量。

LinkedIn上招聘Angular, Vue.js、React、Preact、Ember和Svelte——2020年8月的职位空缺

这里的数字说明得非常清楚。从商业角度来看，JavaScript开发人员正在积极招聘国际上的空缺职位，到2020年，只有3个JS框架和库在使用——React、Angular和Vue.js版.

仍然有一些非常有限的需求，开发人员在烬经验。但是，尽管JavaScript开发社区对此很感兴趣，而且态度积极，但雇主实际上并没有雇佣苗条的或是前卫的开发人员。至少在统计上不相关。

当JavaScript 2020年的状态报告发布时，我们很有兴趣看看这是否反映在2019年至2020年间，这两家新兴企业失去了行业和社区的吸引力。或许斯维特和普莱克的势头并没有动摇。也许他们还有一段路要走，才能让项目发起人充分认识到未来的可行性，从而做出与他们一起构建应用程序的承诺。

比较Angular,Vue.js,React,Ember,Preact和Svelte的优缺点

我们刚刚看到的统计数据的市场证据表明，几乎所有使用JavaScript作为面向用户界面的新web和应用程序开发项目都会在React、Angular和Vue.js版2020年。它们都是很棒的库和框架。其他三种方法也有各自的优点，但在大多数情况下，它们显然不是商业上可行的选择。

这可能是因为人们对Ember、Svelte和Preact的积极支持和持续的OS社区开发的长期性的担忧。事实上，没有足够的开发人员具备这两方面的技能和经验，这意味着可持续招聘将是切实可行的。

但是抛开战略和业务考虑，只关注它们的技术优势，我们六大领先的JavaScript框架和库有哪些优势和弱点，或者说局限性呢？

Angular

AngularJS是一个基于TypeScript的JavaScript框架，也是该框架的第二次主要迭代，自2016年发布以来，AngularJS已逐步淘汰。2010年Google首次发布AngularJS时，作为第一批基于JS的前端框架之一，AngularJS引起了轰动。

Facebook 2013年发布的React库是一个更灵活的框架，它引起了人们对AngularJS局限性的关注，开发人员开始认为AngularJS已经过时，不再使用它。

一个很好的例子说明了为什么一个健康的JavaScript生态系统是由竞争和竞争的工具和标准驱动的，React的到来让Google升级了它的游戏，并创建了一个全新的单页应用程序（SPA）框架，这个框架仅仅是“Angular”发布的。

1.x版本之前的所有AngularJS版本都是AngularJS，2.x以后的所有版本都是AngularJS。与React等JS库不同，Angular是一个端到端的框架，它提供了构建企业级web应用程序所需的所有主要组件。

Angular更严格的结构（也是它的优势）固有的局限性，近年来React的普及率超过了它。有很多开发商会说Vue.js版它是由前谷歌（google）创始人埃文•尤（Evan You）设计的，旨在改善Angular认为的弱点，即卓越的框架。

如果您回顾一下JavaScript图形显示JS开发人员情绪的状态，这是显而易见的。但Angular仍然受到组织的欢迎，因为在谷歌的支持下，Angular被认为是经得起未来考验的。最终，框架仍然是一个强有力的选择，远远不是一个薄弱的工具。

K&C开发人员alexchugaev解释了为什么在企业级应用程序环境中，他更喜欢Angular而不是React和Vue。最终，Angular被证明是可靠的，并且在未来几年内将是一个重要的JavaScript资源。

 

这段由Fireship制作的视频比较了Angular、React和Vue.js版，辩称安格尔的情况。它还对JavaScript 2019年状态报告中使用的数据集进行了非常有价值的批判性分析。

Angular 优势

• 模块化；
• 如何使用组件和模块；
• 如何使用依赖注入；
• 有许多现成的“优点”，如路由器、表单验证、HttpClient等；
• 高水平的控制；
• 与React不同，Angular支持HTML和CSS的正常使用以及它们的所有特性和优点。
• Angular CLI是JavaScript环境中最好的命令行工具之一。
• TypeScript和将模板与样式和业务逻辑分离，使得Angular开发特别适合企业级应用程序的大型代码库。
• DOM sanitisation等内置功能使Angular成为最安全的前端框架。
• 谷歌对Angular的支持可能与Facebook所支持的资源并不完全相同，但足以确保该框架既能经得起未来考验，又能不断创新和改进。最近增加的功能包括延迟加载、用于改进模块加载时间的差分加载和Angular9的新渲染引擎Ivy，用于改进启动时间、响应时间和减小包大小。

Angular 弱点

• 对于没有经验的开发人员来说，使用Angular可能有点棘手，特别是如果他们没有很强的Typescript背景。然而，对于经验不足的人来说，这仍然比React要容易得多；
• 到目前为止，每一个新版本都与前一个版本有很大的不同，这会导致对框架的不信任，并使应用程序向AngularComplex最新版本的前瞻性迁移变得复杂。尤其是AngularJS和AngularJS之间的情况，不能直接在AngularJS和AngularJS之间切换。
• 依赖注入可能很耗时，并且为组件创建依赖项非常困难。
• 如果开发人员想要创建单页应用程序，那么他/她将受到限制。你不能把它放到你的完整堆栈或多页应用程序中。
• 棱角分明。对于较小的应用程序，它通常不是最佳选择。

React

React是一个用于UI开发的JavaScript库，尽管为了简单起见，它通常被称为framework。Facebook最初创建并维护React，这给了它很大的可信度。Uber、Netflix、PayPal、Airbnb、Twitter、沃尔玛和其他许多“巨头”都使用React，这是大中型项目的一个令人高兴的媒介。

React是一个基于组件的、具有单向数据流的web框架，它对前端web开发产生了重大影响，并在2020年成为JS应用程序的主流框架/库。React引入了函数式、声明式编程、不可变状态等概念，这在以前的前端开发中并不常见。React的另一大名气是引入了虚拟DOM，它有助于改善用户体验和应用程序性能。

React优势

• 优化不需要工作的世界。
• 灵活性。React与React Core是一个面向视图层的基于组件的库，提供几乎完全的灵活性和应用程序的定制。
• React灵活性的进一步表现是，它与不同的库和项目之间的交互几乎没有障碍。
• 图书馆真正践行其“一次学习，随时随地写作”的口号，可用于开发Web、移动（React Native）和桌面（电子）应用程序，也可用于后端开发节点.js.
• React使用javascriptes6，与使用TypeScript进行Angular分析相比，它有一个更温和的学习曲线；
• React设计用于基于JSX呈现内容。它可以在SPA和SSR架构中使用，使其成为此类开发工作的一个非常强大的解决方案。它的服务器端渲染优于竞争对手，并提供非常好的搜索引擎优化支持。
• 声明的。当数据更改时，有效地响应更新并呈现正确的组件。声明性视图还使代码可读，易于调试。
• 得到Facebook的支持，并被Facebook使用，意味着这家科技巨头将大量资源用于持续发展React。这也意味着，在历史上规模最大、流量最高的应用程序之一浏览器和移动原生应用程序上，这些功能都得到了验证。
• React不断创新和改进，最近的例子包括React Fiber用于改进并发性、React hook、减少样板代码和提高渲染效果的悬念。

React弱点

• React非常简单，但是基于React编译一个完整的框架是一项具有挑战性的任务；
• 灵活性可能是一把双刃剑，React提供的自由可能导致浪费时间来决定应对不同挑战的最佳方法。
• React使用JSX语法扩展来混合HTML和JavaScript也有另一面。它的复杂性可以看作是有效使用库的一个障碍，特别是对于初级开发人员。
• React开发涉及到使用广泛的组装工具，以使其功能良好并与其他web开发工具兼容。
• 糟糕的文档常常是React库的一个批评。一个非常活跃的社区和来自Facebook的资源支持可以看到定期发布的更新和工具，但是附带的文档常常缺乏。这会使开发人员很难跟上新特性的速度，而且库集成也很差。

Preact

Preact作为JavaScript库的目标是在更小、更轻的包中提供优势或做出React。作为SPA工具，Preact的重量为3kb，而React为30kb。这个库是由google的jasonmiller在一组贡献者的支持下创建的，被Uber、Lyft、腾讯、Groupon和Domino's使用。

最近发布的Preact X进一步清理了库的代码，并添加了新的特性和兼容性增强，以支持更多的第三方库。

Preact的大小和速度意味着它通常最适合于轻量级的移动web应用程序或web widgets/embedded，这些应用程序的React可能很重。它的极简主义本质意味着Preact通常会被考虑用于那些性能优先的小型项目。

Preact优势

• JavaScript生态系统中最快的虚拟DOM和最小的库之一。
• Preact的简单和可预测的diff实现是其速度的另一个原因。
• 有效的内存存储使Preact非常高效。
• 简单的应用程序可以在浏览器中运行，而不需要使用构建工具
• Preact提供了一个专用的CLI
• 使用React的API
• 可与React项目集成

Preact弱点

• Preact的主要弱点是其主要优点的直接结果，它是一种更轻、更快的React应替代品。它羽毛般的体型意味着它缺乏相同的特征范围。
• React的一个显著区别是“这个道具”和这个州'直接传递给render（）方法。以后可以销毁它。
• 基于浏览器的“addEventListener”，Preact不支持合成事件。
• Preact的基本核心不支持PropType验证，这意味着如果您想使用它，则需要从“Preact/compat”模块导入它。
• 单元测试，React使用Airbnb为开发的酶测试工具，是可能的，但是需要一些Webpack配置，并且有一些限制。

Vue.js

Vue.js版2014年首次推出，2016年重新推出。Vue将自己描述为“用于创建交互界面的直观、快速和可集成的MVVM”。在K&C，我们倾向于同意这些形容词。

我喜欢在Packt上的一篇博客文章中对Vue的描述：

“Vue在三大阵营的前端JavaScript框架中占据着一个有趣的位置。它没有像React那样大肆宣传，也没有像Angular那样老牌，在过去的几年里，它一直在默默地关注着自己的业务，并建立了一个积极、热情的开发者社区。”

这个框架项目的主要目标是使webui开发中的思想（组件、声明性UI、热重新加载、时间旅行调试等）更易于理解。与其他框架相比，对于年轻的开发人员来说，学习它要简单得多。

如前所述，Vue.js版这是由前谷歌工程师Evan You创建的，他打算将Angular和React的优势结合起来，并在某种程度上消除各自的弱点。

尽管到达现场后，Angular和React，Vue.js版很快就获得了广泛的关注，并被阿里巴巴、任天堂、Expedia和其他多个企业级项目选中，这一点有时会让人觉得它是一个单页应用程序的框架。事实上Vue.js版不享受“大科技”公司的支持，使其日益增长的成功更加引人注目，并回避了一个问题，即它是否可能没有更受欢迎的程度的财务支持Angular和React受益。

但是Vue.js版的独立性也被视为（双关语意图😊) 被许多在web开发社区被认为是积极的。这也导致了一个特别勤奋的志愿者支持社区在Vue周围涌现。与Angular和React等大型企业支持的框架相比，问题和问题的响应速度通常要快得多。

另一个积极的副作用是没有被“过度设计”的清晰代码/API。这是一个很棒的视频Vue.js版对于任何想要简洁易懂的框架摘要的人来说：

 

Vue.js优势

• JavaScript代码、模板和CSS代码在React中没有混合；
• 可以使用ES5、ES6和TypeScript（有了警告，设置起来可能更困难）；
• 与React一样，Vue可以很好地与其他库甚至项目交互。
• 这也允许渐进式的应用程序开发。大型遗留JavaScript代码库可以通过Vue.js版，这对复杂的迁移项目是一个很大的激励。
• Vue的文档易于理解且结构良好，开源社区在回答问题或问题方面尤其活跃。这使得起步相对轻松。
• Vue.js版同时也是一个固执己见的端到端框架和提供状态管理的视图层。
• 我们提到的目的Vue.js版将React和Angular的优势结合起来，也许最值得注意的例子是反应式双向数据绑定（比如Angular）和虚拟DOM、事件源（比如React）。
• 继续这样做，Vue.js版同时支持JavaScript和TypeScript。
• Vue是一个真正的轻量级框架，下载的.zip只有18KB。下载和安装这个库是超快速和轻巧也有一个积极的影响网站速度，通过扩展用户体验和搜索引擎优化。
• Vue.js版正在经历另一次重大的革新，比如从2014年的原始版本升级到2016年的2.0版本。Vue.js版3.0即将面世。它已经可以在beta版中试用了。正如你总结的创始人所言，VUE3有望成为“更快、更小、更易维护、更容易瞄准本机产品”。

Vue.js弱点

• Vue.js版它还是相对较新的，没有像Angular（谷歌支持）和React（Facebook支持）这样的大型科技公司的支持和资金支持。在大型企业级项目中更经常采用React或React型，Vue.js版仍然缺乏公司倾向于寻找的那种支持，以及为什么它在较小的项目中最常用。
• Vue在中国尤其流行，这意味着该框架的大部分内容、插件描述和说明以及社区讨论都是中文的。
• 反应性复杂性。在Vue中实现的用于管理DOM更新的双向数据绑定是保持组件同步的便利工具。反应性系统只重新呈现由用户激活组件所触发的数据块。在读取数据的过程中经常会出错，需要将数据展平。这是一个已知的问题，有大量的文件解释如何正确设置反应性。
• 与React或Angular相比，插件和工具的生态系统更小。
• 缺乏经验Vue.js开发者。这是一个鸡和蛋的情况，但更少的Vue开发人员可以让公司远离框架，而较低的客户需求阻止更多的开发人员学习它。
• 有趣的是，我们注意到Vue.js几乎所有这些都与框架在社区规模（尽管它也以其质量闻名）和企业级支持方面的成熟程度有关。在技术层面上，对缺陷的抱怨是很难得到的，这表明Vue.js版很可能会继续走红。

Ember

Ember开源框架是开发人员的老朋友，源于苹果音乐。受rubyonrails原则“约定优先于配置”的启发，Ember最出名的是作为应用程序开发字典的大型存储库。它考虑到约定而不是改变配置，并支持双向数据绑定。

自从2012年首次发布以来，Ember几乎没有看到重大变化，这意味着它是一个严格向后兼容的框架。另一方面，该框架每六周更新一次，并声称它坚持对稳定的坚定承诺。Netflix、苹果和微软只是使用Ember的一些公司。

Ember优势

• 在系统上简单配置；
• Ember是一个端到端的固执己见的内聚框架，专注于“约定优于配置”
• Ember得到了包括雅虎和LinkedIn在内的大型科技公司和品牌财团的支持。这意味着它并没有按照一家公司的需要进行调整。
• Embers数据库允许跨多个源同时访问数据，建立异步关系。
• Ember CLI被广泛认为是所有JavaScript框架中最好的CLI。它有助于生成正确的代码，并用正确的结构构建它们，同时考虑到依赖关系。
• Ember Inspector是一个方便的浏览器扩展，允许开发人员实时监控和编辑应用程序。
• Ember的MVVM（Model–View–ViewModel pattern）架构深受用户欢迎，该框架还提供双向数据绑定。
• 最近发布的dember辛烷迭代引入了一种HTML和组件优先的方法，改进了对状态管理和反应性的支持。
• Ember受益于一个活跃的社区，该社区定期向Ember Observer（一个聚合常见任务解决方案的网站）投稿。
• 你可能也会对我们的博客文章感兴趣，直接比较Angular和Ember。

Ember弱点

• 作为一个高度固执己见的框架，定制非常困难。
• 在最重的框架中；
• 难以掌握；
• 有时对小项目来说过于复杂；
• 新版本发布缓慢，几乎没有新选项。
• Ember与jQuery密切相关，对于喜欢使用标准fetch或Axios处理AJAX请求的开发人员来说，jQuery可能被认为是一个缺点。但是，在Ember Octane中，jQuery不再默认包含。
• 下降的人气可能使寻找好的灰烬开发人员棘手。

Svelte

Svelte诞生于2016年软件工程师Rich Harris的“尤里卡时刻”，他想出了构建一个JavaScript框架而不考虑任何特定于框架的运行时的想法。这是通过精巧地将特定于框架的代码编译成干净的JavaScript、HTML和CSS来实现的，并将编译后的代码呈现给浏览器。这种方法在软件开发中并不是新的，而是在前端开发环境中革命性的。

Svelte的第二个独特品质是增加了一流的反应性支持。这使得在不需要虚拟Dom的情况下提高了性能，这使得Svelte的渲染速度在任何JS框架中都是最快的。

基于组件（HTML、CSS和JS）和轻量级、轻量级的Svelte是用TypeScript编写的。但最重要的是，框架不需要掌握TypeScript知识就可以充分使用它。

JavaScript开发人员对此印象深刻，虽然对于sivelte来说还处于非常早期的阶段，但它已经吸引了很多人的兴趣，并迅速在前端开发领域获得了广泛的关注。一些勇敢的人甚至认为，Svelte最终可能取代React成为占主导地位的JS资源。然而，与Vue一样，缺乏强大的技术支持可能会在某个时刻导致牵引力瓶颈，尽管它的技术质量很高。

Svelte的优点

• 对于没有很多JS经验的开发人员来说，使用Svelte很容易。
• 编译时框架不需要任何特定于框架的运行时，并且Svelte的包大小是任何JS框架中最小的。
• 任何框架的最快渲染都要归功于通过反应式编程进行的Dom渲染。
• Svelte基于组件的框架允许通过创建可组合和可重用的组件来构建UI。结果是减少了样板代码和减少了开发时间。
• 和React Core一样，Svelte是一个视图层，没有任何细节。
• 同时支持客户端和服务器端呈现。良好的SEO支持。
• Svelte是跨平台的，可用于开发web、非本地移动和桌面应用程序。

Svelte的弱点

• 缺乏成熟度。仍然年轻，Svelte还没有很多重要的用例或第三方工具。缺少工装和工装支持是目前斯维特的主要批评。
• Svelte提供的特性数量仍然有限，这意味着必须编写大量代码或使用第三方工具来进行更复杂的开发项目。
• 与成熟的、占主导地位的JS框架和库相比，Svelte的社区仍然很小，文档不发达，并且通常缺乏大多数企业级项目所需的支持。
• 子组件不能用作用域样式调整。
• 不支持TypeScript。
• 很少有专门针对苗条开发人员的职位空缺。

有Angular，Vue，React，Preact，Ember还是Svelte？下一个JavaScript项目应该选择哪一个？

最后，你应该为你的应用程序选择Angular、Vue、React、Preact、Ember或Svelte中的哪一个？如上所述，每个框架或库都有其优点和缺点。正确的选择取决于应用程序的特定需求，而且通常至少也受到开发人员资源和业务考虑因素的影响。

但如果我们在对这六个问题进行如此广泛的审查之后，把它放在一边，那我们就是在作弊。因此，以下是一些经验法则可以帮助您决定：

• 如果您喜欢TypeScript，并且喜欢在一个风格和流程中清晰定义的框架中工作，那么您的解决方案是有Angular的。尤其是在大型企业级应用程序中，稳定性、支持和大量经验丰富的开发人员是首要任务。
• 你的解决方案是React.  如果你需要灵活性，喜欢大的生态系统，不想在不同的包之间选择，喜欢JS，喜欢你自己的方法和尖端技术。就像Angular的情况一样，React开发人员的深度池以及成熟的支持和稳定性也对库有利。
• 如果您也在考虑React，但是感觉到前者的轻巧带来的性能优势超过了它更有限的功能，那么您的解决方案就是Preact。
• 你的解决方案是Vue.js版如果您正在寻找一个更温和的学习曲线来帮助初级开发人员，需要一个轻量级的框架或需要干净的HTML文件。考虑到虽然Vue现在已经很成熟，但经验丰富的开发人员库并不像Angular或React那样多。
• 你的解决方案是Ember，如果你个人喜欢与框架合作，不过分担心几年后能够相对容易地雇佣Ember开发人员，并且不把未来验证视为战略必须。
• 如果你准备好优先考虑其技术优势而不是缺乏成熟度，或者不必担心或者愿意在经验丰富的开发人员队伍中冒险，那么你的解决方案就显得Svelte了。
• 如果你还是拿不定主意，那就在不同的环境中尝试一下。你会得出你自己的结论的。

 

 

原文：https://kruschecompany.com/ember-jquery-angular-react-vue-what-to-choose/

本文：http://jiagoushi.pro/node/1280

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

以适合项目规模和意图的方式构建项目文件夹是可扩展性和可维护性的关键。 不幸的是，没有多少示例记录了适用于企业级应用程序的结构。 对于完美的文件夹结构是什么样的，也没有单一的正确答案。 以下结构是我多年来一直在发展并已在许多企业级项目中使用的结构。

本文的目的是解释这种结构背后的推理，以便您可以使用这些想法为您的项目构建最佳解决方案。

TL;DR

在解释每个目录的意图之前，让我解释一下这种方法背后的方法论。

可组合性

允许您在组件之间重用代码。这是 React 中一个非常强大的概念，并且对为什么拆分和分组可重用代码很常见的影响很大。

本地优先

在构建组件时，最好将仅与该组件相关的代码保留在本地。在我们上面的示例中，身份验证功能组件包含一个 auth-form 组件和一些实用程序。我们没有将它们分解到各自的组件或 utils 目录中，而是将它们保留在本地，因为它们包含的代码永远不会在另一个组件中使用。这将有助于防止这些目录随着项目规模的扩大而变得不合理。

平一点更好

每次嵌套时，您都会添加到理解组件本地代码所需的心智模型中。嵌套还伴随着其他痛点，因此最好避免过多的嵌套。

随着你的成长筑巢

扁平化可能更好，但也有嵌套的理由。例如，如果您的功能目录变得太大，您可能希望按逻辑对您的功能进行分组。

components/

 

• 包含最常用于组成功能或页面组件的可重用组件。
• 这些组件几乎总是纯粹的和展示性的，没有副作用。

constants/

 

• 包含可重用和不可变的字符串，如 URL 或正则表达式模式。
• 对于大多数项目，单个索引文件就足够了。

contexts/

 

• 包含用于通过组件树提供数据的可重用上下文。
• 如果直接使用 Redux，则可能不需要。

features/

 

• 包含可重用的功能组件。功能组件是一个受 Redux 启发的概念，其中功能所需的所有逻辑都位于一个目录中。功能组件通常由许多其他组件组成，无论是本地的还是共享的。对于所有资源也是如此：utils、types、hooks 等等。
• 功能组件通常包含副作用。
• 如果使用 Redux 并与 Store 交互，则功能组件将包含一个切片文件，该文件定义了该功能所代表的 Redux Store 的“切片”。

layouts/

 

• 包含可重用的布局组件。布局组件是组成页面布局的组件。它通常会导入 app-bar、app-footer、app-side-nav 等组件。
• 如果您的项目可能只有一个布局，则此目录可能不是必需的，并且布局组件可以位于 components 目录中。

hooks/

 

• 包含可重用的 React Hooks。

pages/

 

• 包含页面组件。每个页面组件都与一个路由相关联。
• 页面组件通过导入组件和功能组件来组成页面的内容。
• 页面组件应该很少包含副作用，而应该将副作用委托给功能组件。

services/

 

• 包含用于与 API 交互的可重用代码，通常采用钩子的形式，并且最好使用服务器缓存工具，如 React Query 或 RTK Query。
• 不要将其与 Angular-esque 服务混淆，该服务旨在处理将功能注入到组件中。 React 使用上下文和钩子处理这种情况。此目录应仅包含用于与 API 交互的代码。
• 受 RTK Query 建议的启发，将您的 API 定义放在一个中心位置。这是我们故意打破本地优先规则的唯一例子。我喜欢将 API 定义视为它们自己的模块化功能。事实上，用 features/api 目录代替 services 目录的情况并不少见。

“我们的观点是，与在整个应用程序的不同文件中拥有 X 个自定义钩子相比，当请求、缓存失效和一般应用程序配置都在一个中心位置时，跟踪它们的行为要容易得多。” — RTK

styles/

 

• 可重用或全局样式。
• 可能包括配置、重置或变量。

types/

 

• 使用 TypeScript 或 Flow 的项目的可重用类型。
• 我经常将我的可重用 Zod Schema 也放在这个目录中，并导出推断类型。

utils/

 

• 可重用的实用函数。
• 这些函数应该始终是纯函数并且不会产生副作用。

store.ts

 

• 如果使用 Redux，此文件是您导入所有切片和配置 Redux Store 的位置。

专业提示

 

• 每次开始新项目时都要阅读官方文档。 您永远不知道自您上次实现某个库以来可能添加了哪些新工具。
• 停止使用 PascalCase 作为文件名。 而是对所有文件使用 kebab-case。
• 使用服务器状态工具，如 React Query 或 Redux Toolkit Query。
• 使用像 MUI 这样的组件库。
• 使用像 usehooks-ts 这样的钩子库来处理常见的钩子。

原文：https://engineering.udacity.com/react-folder-structure-for-enterprise-l…

本文：https://jiagoushi.pro/node/1642

 

我们必须承认，我们在这些框架方面有着极不平等的经验。然而，我们将尽量保持公正，并弄清楚React何时可能不是最佳选择，但首先，简短介绍：

• React是Facebook维护的最流行的框架。所有的酷孩子，以及经验丰富的工程师都喜欢它。
• 我们有Angular感谢谷歌。它是企业中最古老、最著名的。
• Evan You从他以前在Google的工作经验中提取出他喜欢AngularJS的部分，从而创建了轻量级Vue。这是亚洲最流行的框架。

框架设计

Vue和Angular共享类似的设计，尽管Angular是一个复杂的平台，而不仅仅是一个小库。另一方面，React具有独特的设计，具有单向数据绑定和虚拟DOM。

React设计原则

React是基于可组合组件的思想构建的。它们是隔离的，在大多数情况下，只公开props 接口。它使团队协作更加容易，因为不同的人可以创建各种协同工作的组件。对组件进行更改也是一件轻而易举的事，而且这很少会导致整个代码库的更改链。

在React中，组件不会直接呈现给Dom。render方法返回需要呈现的内容的描述，React有一种快速而聪明的方法将其应用于DOM。

这个框架是关于组件层次结构的单向数据流。子组件不知道它们的父组件，只接收来自它们的props 。将函数作为属性传递是修改父组件状态的常见做法。它使得所有的东西都是松散耦合的、模块化的、快速的。

Angular 是为了企业

Angular更像是一个使用HTML和TypeScript构建应用程序的平台。它由不同的TypeScript库组成，可以导入到项目中，比如路由或ajax调用。

Angular应用程序总是有一个支持引导的根模块，通常有一堆特性模块。NgModules是将相关代码收集到功能组件中的基本构建块。

组件为屏幕元素定义视图，并使用与视图不直接相关的特定功能的服务。它利用依赖注入使所有东西松散耦合和模块化。

应用程序代码广泛地使用decorator为Angular提供额外的元数据。

对于视图，它有自己的模板语言，带有指令和绑定标记，可以根据数据动态呈现HTML。还有一个事件绑定可以让你的应用程序响应用户输入。与react不同，数据流是双向的。

Vue,两者兼而有之

Vue试图用最简单的API提供可组合视图组件和反应式(reactive )数据绑定的好处。Vue有一篇文章从其他框架的角度将其与其他框架进行了比较，值得一读，尤其是如果您已经熟悉其他两种框架之一的话。

Vue不是Angular那样的平台，而是像React一样的接口框架。与Angular一样，它支持双向数据绑定，但组件之间的单向父子数据流是默认设置。它还有一个独特的模板语言，并且不像React那样使用虚拟DOM。

Vue中的组件与Web组件规范中的自定义元素非常相似。他们故意按照规范对语法进行建模。但是，Vue组件在每个浏览器中都受支持，具有跨组件数据流、自定义事件通信和其他基本功能。

框架的优势

每个框架都有它最好的部分。React使开发变得轻而易举，Angular主要专注于企业，而Vue则是最轻量级的。

React优点

如果你问我们React最喜欢什么，那应该是JSX（TypeScript是TSX）。它是JavaScript的语法扩展，可以为组件编写类似HTML的呈现代码：

function Hello({ name }) {
  return <div>Hello {name}</div>;
}

如果没有JSX，编写React代码会非常痛苦：

function Hello({ name }) {
  return React.createElement("div", null, `Hello ${name}`);
}

上面的JSX在幕后被翻译成了非常相似的JavaScript。想象一下用它编写复杂的组件层次结构。你可以玩一下the online Babel compiler 来获得这个想法。

React团队非常关注API的稳定性。对于像Facebook、Twitter和Airbnb这样在生产中使用React的大公司来说，这一点至关重要。这些api与最初的版本相比没有太大变化。当他们决定删除某些内容时，他们首先将其标记为已弃用，这将触发linter和debug生成警告。

作为一个视图库，react通过互操作性得到了了巨大的好处。您可以快速将其放入现有项目中，并仅将其用于组件的一个子集。

对于性能，它使用“拉动”方法。与其他在新数据可用时执行计算的框架不同，React可以安排生命周期方法来延迟应用更改。

开发经验是React团队的首要任务。它们维护有用的React DevTools，并尝试使框架抛出的警告真正有用。

在React 16.8中引入React钩子使得几乎整个应用程序都可以使用短功能组件。函数式风格使代码更易于编写、阅读和理解。

除了HTML，React还支持Web组件和呈现SVG。它与渲染器无关，可以在浏览器内部工作，也可以在Node.js处理和输出HTML流，甚至在移动设备上使用React Native。

你可以在他们的“设计原则”(“Design Principles”）一文中了解更多关于它们的好处。

Angular 长处

作为一个平台，Angular的所有基础知识都是现成的。因此，应用程序通常具有更好的一致性、更高的代码质量和更高的安全性。您不必为常见任务处理不熟悉的第三方软件包。

默认情况下，Angular附带TypeScript。强类型语言有许多优点，比如出现错误的机会更少、工具更好、重构功能更强大以及总体上可维护性更好。我们也推荐它用于React项目。

与其他鼓励自由的框架不同，Angular通常有一种建议的做事方式。对于新开发人员来说，加入不熟悉的项目更为自然，因为每个应用程序的结构几乎都是一样的。它还使得维护大型代码库更便宜、更高效。

与其他框架中的组件类似，模块允许代码重用和由不同的人甚至团队进行并行开发。Angular社区还提供了带有可重用组件的预制模块。

Vue灵活性

轻量级和简单是Vue设计的核心原则之一。在所有三个框架中，它的包大小最小。Vue代码非常简单易懂。这可能是它受欢迎的主要原因。

与React一样，您可以轻松地将Vue添加到现有项目中，并开始将其用于某些部分。与React不同的是，Vue模板语法类似于HTML，因此转换现有代码更加方便。顺便说一下，它还支持JSX语法。

Vue的核心和最受欢迎的库都有公共CDN。您不必设置复杂的构建过程来使用它，添加头脚本（如jQuery）应该可以让您快速入门。

Vue覆盖了MVVM架构模式的ViewModel层。除了呈现HTML视图外，它还具有双向数据绑定，以使UI中的更改与数据同步，反之亦然。它比React的单向绑定直观得多，使它更容易在静态网站中添加动态功能。

它受到了另外两个框架的启发，并试图从这两个框架中获取最好的部分。组件来自React。指令以及双向数据绑定都是从Angular中借用的。它不仅仅是像React这样的UI库，也不是Angular这样的成熟平台。Vue拥有一个很好的平衡特性，这些特性都是现成的，而且没有固执己见，提供了广泛的选择自由。

每个框架的缺点

本文中涉及的所有框架都是健壮的，经过许多公司的生产测试，没有明显的缺点。但是，在为下一个项目选择框架时，需要记住一些事情。

React 缺点

React不喜欢第三方代码弄乱DOM。在React中提供具有根DOM元素的外部库很容易，并且只处理其生命周期。这就是流行的react-leaflet库如何用react接口包装纯JavaScript单张库。

单向的数据流是一个巨大的好处，在没有经验的人身上会造成很多伤害。清楚的理解是正确使用它的关键。我们认为React与其他框架有很大的不同，因此它需要自己的思考方式。

Angular 缺陷

Angular是一个复杂的平台，具有陡峭的学习曲线。应用程序代码冗长而复杂，这使得它不适合许多开发速度至关重要的敏捷项目。它是为企业级应用程序而创建的，因此可维护性是他们的首要任务。

包的大小通常比另外两个包大得多，尽管它取决于包含的库。再加上缺乏对服务器端渲染的支持，这使得Angular应用程序远不是SEO友好的。有点奇怪，考虑到它的创建者，谷歌是最大的搜索公司。

Angular的受欢迎程度正在慢慢下降，社区开始转向其他框架。许多开发人员认为这个已经有十年历史的框架是一种遗留技术，并且不愿意在基于它的项目上工作。

Vue缺点

Vue依赖于相当复杂的机制来实现其双向反应性(reactivity)。每个开发人员都应该意识到Vue无法检测到的这些情况：

• 对象的属性添加和删除
• 使用相应属性修改数组长度
• 按索引直接分配数组元素

JavaScript本身的局限性导致了这些问题，Vue团队对此无能为力。它们在反应性指南中有完整的记录。

作为最年轻的框架，Vue缺乏经验丰富的开发人员，学习资源有限。不过，生态系统本身相当广泛。

尽管它的受欢迎程度有一个强劲的上升趋势，但在撰写本文时，很少有大型项目是基于Vue构建的。对于应用程序的其余部分，没有多少最佳实践和经过验证的库。它引入了一些风险因素，在选择Vue进行更实质性的项目时需要考虑。

性能

所有的基准都来自Stefan Krause的综合JS框架基准测试。您可以检查每个框架测试的源代码，甚至可以在本地计算机上运行这些基准测试。所有的说明以及每个测试的详细解释都在存储库中。

Dom操作

DOM操作测试在应用程序完全加载和预热后测量UI性能。

我们这里没有明确的赢家。Vue可能会使用独特的性能优化来加快交换行的速度。另一方面，Angular和React在highlighting rows测试中的性能都要优于React。

启动时间

这些测试代表了Google在访问应用程序时推荐的高质量用户体验的“Web关键点”指标。

Vue凭借其轻量级的设计和最小的捆绑包大小击败了这里的所有人。React排在第二，只输了几分。角度，感谢它的束大小和复杂的引导是最后一个明显的区别。

内存分配

结果与启动时间试验有很强的相关性。Vue排在第一位，反应不远，Angular由于其大小和抽象性而占据了大部分内存。

人气

根据googletrends，React仍然是最流行的框架。它有一个活跃的社区和最广泛的第三方npm包集合。

然而，在他们的存储库获得的星数量上，Vue已经克服了这一点。

如果我们看看中国，情况就不同了。中国是Vue的发源地，在附近的亚洲国家也很受欢迎。由于防火墙的存在，中国开发者无法访问谷歌和其他框架上的大部分资源。语言障碍也起着重要作用。

学习曲线

Vue是最容易学的，不用担心。它的模板语法与plain html非常相似。您可以用HTML、Javascript或JSX编写模板。双向响应非常简单。i

整个框架很小，设计中融入了简洁性。

反应其次。JSX也类似于HTML，但有一些区别，比如类名和camelCase命名约定。单向数据流和不变状态是最难理解的部分。但一旦你得到它，其他一切都很容易。

Angular的学习曲线要陡得多，因为它是这三个框架中最复杂的。TypeScript和RxJS对于Angular开发是必需的，因此开发人员也必须了解它们。虽然TypeScript构建在JavaScript之上，而且非常容易学习，但RxJS确实需要一些努力才能掌握。

摘要

React	Angular	Vue
Realease	2013	2010	2014
Website	reactjs.org	angular.io	vuejs.org
Current Version	16.13.x	10	2.6.x
Used by	Facebook, Instagram, Netflix, New York Times	Microsoft, Google, Apple, Paypal	Adobe, Buzzfeed, GitLab, Grammarly
Bundle Size	35 Kb	500 Kb	20 Kb
Popularity	High	Moderate	High
Watchers	6.7k	3.2k	6.2k
Stars	152k	63.1k	168k
Forks	29.7k	17.1k	25.5k
Contributors	1,468	1,165	371

荣誉提及Preact

PPreact是一个快速的api兼容React的替代品，具有令人惊叹的3Kb包大小。

它与React基本上是生态系统兼容的，这意味着为React设计的第三方npm包中的组件也应该在Preact中工作。在关于从React切换的指南中，它们涵盖了许多常见的迁移问题。

作为最小的UI框架之一，它非常适合于可嵌入的小部件和其他代码，其中bundle的大小至关重要。拥有React经验的开发人员甚至不必牺牲生产力，因为它离它的老大哥太近了。

结论

对于一个新项目来说，这三个框架中的任何一个都不会完全出错。明智的做法是将你的决定主要建立在你的团队现有的专业知识之上。

• 当涉及到小部件和其他可嵌入的UI组件时，Preact是最好的。
• React是一个很好的全能者。由于单向数据流，应用程序的逻辑始终保持清晰。组件提供了高级别的代码重用和较低的更改成本。它对小项目没有问题，而且，当与TypeScript一起使用时，对于大中型项目也非常适用。
• 对于Web设计者来说，Vue是jQuery的最佳替代品。它的功能远不止于此，我们还建议将其用于除企业项目之外的任何项目。由于简单和高效，它对于MVP开发来说一定是很棒的，尽管我们还没有尝试过。
• 随着越来越多的公司迁移到Vue和React，Angular甚至在企业利基市场也失去了主导地位。现在我们不提倡从头开始学习，但是如果你有合理的理由，开始一个新的角度项目并不是一个大错误。然而，它的大量冗长对开发生产力有很大的伤害。

在LeanyLabs，我们重视React设计决策的好处及其广泛的生态系统。我们对Vue没有太多的经验，但是如果它对项目更有意义的话，我们会考虑使用它。今天，我们不能向我们的客户推荐好的老Angular，因为它继续失去人气，我们担心很难很快找到好的Angular开发人员。

 

原文：https://leanylabs.com/blog/react-angular-vue/

本文：http://jiagoushi.pro/node/1276

讨论:请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

在我回答之前，如果你读这篇文章是为了选择一个“要学习”的框架，不要这样做。还是读读这篇文章吧。

如果你想选择一个框架来使用(在一个实际的项目中)，你可以继续:)

“更好”是非常主观的。更好的为了什么?

• 可扩展性。如果我们讨论性能的话，为所有3个框架编写的代码可以根据需要进行扩展。有些框架偶尔会有更智能的优化，但最终所有框架都会遵循经过实战测试的任何优秀智能优化。
• 语法和可读性呢。你(个人或团队)来做裁判!试一试，看看你更喜欢哪种语法。许多框架都有不同的“使用方法”，所以请确保探索所有的选项。
• 开发速度。这取决于你对你所拥有的工具有多精通。有些框架确实为您提供了更多的设计决策，但如果您有足够的经验，您几乎不会注意到任何差异。事实上，您拥有的经验越多，您就越不希望预先为您做出设计决策。
• 可测试性.全靠你了!当您遵循某些编码实践时，一切都是可测试的。
• 互操作性/ Debuggability。框架越小，API越小，效果就越好。
• 可维护性。框架允许您编写的函数/组件越小，就越好。
• 寻找支持或人员加入你的团队。框架越流行越好。React赢得了NPM下载的流行(这可能是最重要的)。Vue在GitHub上的星舰人气相当。Angular的受欢迎程度是有争议的，因为你必须将两种不同的框架结合在一起，但现在它可能和React差不多了。
• 移动集成呢。React是这里发光的那个。您也可以选择其他框架，但它们(在我看来)不如React Native那么好。

如果您不关心最后一点，那么这三个选项或多或少都提供了相同的价值。这绝对是个偏好问题。可以通过构建完全相同的应用程序来尝试所有这些方法，然后选择最让您高兴的一个!对于在线课程来说，这是个不错的主意，哈!我可能有偏见，但我可能会考虑试一试。

 

原文：https://medium.com/edge-coders/which-framework-is-better-angular-js-react-js-or-vue-js-77c67d00d410

本文：http://jiagoushi.pro/node/1272

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

对于现代UI开发人员，您的“选择框架”是您内心深处的东西，它以某种方式定义了您的身份，并且可能限制了您解决问题的能力。就像我之前说的，如果每个人都和睦相处不是更好吗?

 

如果您是React或Angular、Ember或Vue，让我们创建一个地方，让它们都可以使用web组件和谐地生活在一起。

使用web组件作为Angular和React组件的包装器，我将展示它们在单个应用程序中协同工作的情况。我还将把数据从父容器传递到两个组件，然后再返回。我们的成品会是这样的:

 

先决条件

为了让我们能够专注于重要的部分，我把所有的东西都编码并上传到我的github:

https://github.com/chriskitson/micro-frontends-with-web-components?sour…---------------------------

无论如何，这都不是一个深入的研究，但是我将浏览Angular中web组件支持的重要部分并作出反应。

*如果您想完成其他一些框架(Vue, Ember等)，请随意在我的repo上创建一个pull request !

我已经使用Angular CLI为我们的Angular项目生成了一个起点。你至少应该熟悉这个工具，这样你就可以浏览代码:

https://cli.angular.io/?source=post_page---------------------------

由于我们的最终目标是web组件，所以我们将把静态JavaScript文件组合成微型服务。为此，我将在我的本地环境中使用serve，这是一个使用node服务静态文件的优秀工具:

https://www.npmjs.com/package/serve?source=post_page---------------------------

 

Angular 组件作为自定义元素

由于Angular似乎正在采用web组件(带有Angular元素)，您可以将Angular组件作为web组件来使用，只需对Angular CLI生成的默认项目做一些小调整。

在/micro-fe-ng目录下，一切都应该正常工作，你需要做的就是安装依赖项并运行启动脚本:

cd micro-fe-ng/

npm i

npm start

现在我们的Angular微前端将自定义元素定义为，应该在http://localhost:5001/main.js上运行。

注意:我们在不同的端口上通过localhost提供文件，但是它们很容易位于共享相同DNS的多个微服务中。

如果你对这是如何实现的感兴趣，这里是一个必要的变化纲要:

我们需要一些新的依赖:

Angular对自定义元素的支持(@angular/elements)和ngx-build-plus，后者是Angular的另一种构建工具(这对Angular元素有很好的支持):

npm i @angular/elements ngx-build-plus -D

我们还需要对包做一些修改。json来构建我们的Angular项目，并作为自定义元素服务于我们的项目:

micro-fe-ng / package.json:

"start": "npm run build && serve -l 5001 dist/micro-fe-ng",

"build": "ng build --prod --output-hashing none --single-bundle true",

我们需要在app.module中定义自定义元素。ts:

micro-fe-ng / src / app / app.module.ts:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule, Injector } from '@angular/core';
import { createCustomElement } from '@angular/elements';import { AppComponent } from './app.component';
import { CustomelementComponent } from './customelement/customelement.component';@NgModule({
  declarations: [
    AppComponent,
    CustomelementComponent
  ],
  imports: [
    BrowserModule
  ],
  providers: [],
  bootstrap: [],
  entryComponents: [
    AppComponent,
    CustomelementComponent
  ]
})export class AppModule {  
   constructor(private injector: Injector) {} 
    ngDoBootstrap(): void {
    const { injector } = this;    // create custom elements from angular components
    const ngCustomElement = createCustomElement(CustomelementComponent, { injector });    // define in browser registry
    customElements.define('ng-el', ngCustomElement);  
}}

最后，我们需要告诉Angular使用ngx-build-plus构建工具，方法是在Angular内部的三个位置指定它。json如下图所示:

Ngx-build-plus将构建的项目作为一个JS文件返回，这是web组件作为一个服务工作的要求。

micro-fe-ng / angular.json:

..."architect": {
  "build": {
    "builder": "ngx-build-plus:build",
    ....  "serve": {
    "builder": "ngx-build-plus:dev-server",
    ...  "test": {
    "builder": "ngx-build-plus:karma",

 

将react组件作为自定义元素

由于React对web组件没有开箱即用的支持，我们将不得不编写比以前多一点的代码来包装一个标准的React组件，并将其呈现为一个本地web组件(自定义元素)。

与React组件非常相似，定制元素(web组件)也有生命周期钩子，您可以通过回调方法访问这些钩子。

通过使用定制元素API的connectedCallback()和disconnectedCallback()生命周期方法，我们可以将它们分别映射为render()和unmount()我们的React组件，如下所示:

class MyCustomElement extends HTMLElement {
  constructor() {
    super();
  }  connectedCallback() {
    ReactDOM.render(<MyReactComponent />, this);
  }  disconnectedCallback(){
    ReactDOM.unmountComponentAtNode(this);
  }
}

通过映射React道具和事件，我将这一阶段做得更深。如果您想查看它，请查看/micro-fe-react/src/index.js。

在示例存储库中，所有东西都应该很好地工作，这样您就可以执行以下操作来启动和运行React微服务:

cd micro-fe-react/

npm i

npm start

现在我们的React微前端将定制元素定义为< React -el />，应该在http://localhost:5002/main.js上运行

 

Micro-frontend包装

我们有两个微前端服务;一个用于Angular组件，一个用于React组件。

现在让我们来创造一个他们可以一起生活的世界…

在/micro-fe-wrapper目录下，一切都应该正常工作，你所需要做的就是安装依赖项并运行开始脚本:

cd micro-fe-wrapper/

npm i

npm start

现在，我们的微前端包装器应该运行在http://localhost:5000。

要了解它是如何工作的，请继续阅读……

由于web组件是原生HTML规范的一部分，所以我们不需要做太多花哨的工作来将它们组合在一起。

在现实世界中，您可能想要使用一个框架来实现更好的代码结构和数据绑定等，但是为了简单起见，我们只使用普通的HTML/JS。

micro-fe-wrapper / index . html:

我们需要包括一些来自CDN的外部依赖:

• zone.js 是Angular所需要的。在包装器应用程序中包含一次是很好的实践，因为不能在同一个页面上有多个版本。
• custom-elements-es5-adapter.js 在浏览器中提供自定义元素支持。

此外，我们应该包括来自组件服务的JS文件，我们在前面的步骤中建立和部署:

<script src="https://cdnjs.cloudflare.com/ajax/libs/zone.js/0.9.1/zone.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/webcomponentsjs/2.2.10/custom-elements-es5-adapter.js"></script>
<script src="http://localhost:5001/main.js"></script>
<script src="http://localhost:5002/main.js"></script>

我已经定义了一个方法tellComponents()，它应该将自定义元素标记注入到我们的页面中: <ng-el /> 代表Angular， < React -el />代表React。

我还使用setAttribute()传递一个属性名，以模拟包装器应用程序与组件的对话。

我还使用addEventListener()侦听一个名为helloEvt的事件，该事件将侦听来自组件的事件，使它们能够与父应用程序和其他组件通信。很酷!

React和Angular之间helloEvt()的属性名略有不同。这是由于框架之间的约定不同造成的。我待会再解释……

function tellComponents() {
  const name = document.getElementById('yourName').value;
const reactEl = document.createElement('react-el');
  reactEl.setAttribute('name', name);
  reactEl.setAttribute('onHelloEvt', 'onHelloEvt');
  reactEl.addEventListener('onHelloEvt', (e) => helloEvent('react'));
  const reactElContainer =  document.getElementById('react-container')
  if (reactElContainer.children.length > 0) {
    reactElContainer.removeChild(reactElContainer.children[0]);
  }
  reactElContainer.appendChild(reactEl);
const ngEl = document.createElement('ng-el');
  ngEl.setAttribute('name', name);
  ngEl.addEventListener('helloEvt', (e) => helloEvent('angular'));
  const ngElContainer =  document.getElementById('ng-container');
  if (ngElContainer.children.length > 0) {
    ngElContainer.removeChild(ngElContainer.children[0]);
  }
  ngElContainer.appendChild(ngEl);
}

向组件传递值和从组件传递值

还记得我们传递给自定义元素的name属性吗?实际上，在组件中读取这个值非常简单。

在Angular中，我们只是简单地引用一个输入:

export class CustomelementComponent implements OnInit {

@Input() name: string;

...

}

这使得我们的模板中的值可用:

<p>Hello <strong>{{name}}</strong> from your friendly Angular component.</p>

在React中，它将作为一个道具传递给组件:

export class ExampleComponent extends React.Component {
  
  static propTypes = {
    name: PropTypes.string
  }  static defaultProps = {
    name: "Chris"
  }  render() {
    const { name } = this.props;
    return (
      <div className="exampleComponent">
        <p>Hello <strong>{name}</strong> from your friendly React component.</p>
      </div>
    )
  }
}

从组件发送事件几乎与监听helloEvt一样简单。

在Angular中，我们只需要指定一个输出:

export class CustomelementComponent implements OnInit {

@Input() name: string;

@Output() helloEvt: EventEmitter<string> = new EventEmitter();

...

}

然后我们可以从模板中调用这个事件:

<button type="submit" (click)="helloEvt.next()">Say hello</button>

注意，EventEmitter在Angular中创建了一个可观察对象，因此我们需要调用next()。

在React中，我们的组件包装器(micro-fe-react/src/index.js)将查找前缀为“on”的道具，并将它们视为事件，例如onClick()、onFocus()等原生事件。这就是为什么我们将定制事件onHelloEvt()称为React。

事件在React中被视为道具，所以我们需要做的就是定义道具并将其调用为onClick()处理程序。就是这样!

export class ExampleComponent extends React.Component {  static propTypes = {
    name: PropTypes.string,
    onHelloEvt: PropTypes.func
  }  static defaultProps = {
    name: "Chris"
  }  render() {    const { name, onHelloEvt } = this.props;
    
    return (
      <div className="exampleComponent">
        <button type="submit" onClick={onHelloEvt}>Say hello</button>
      </div>
    )
  }
}

结论

使用这些概念，您应该能够创建一些真正强大的应用程序，通过使用Web组件自定义元素规范混合Angular和React组件。

为什么混合框架是有益的还是有问题的(取决于您的用例)，有很多利弊;考虑适应性、可伸缩性、性能、安全性、资源分配、浏览器支持等因素。

如果你还没有查看我的github，这里有一个提醒。享受! !

原文：https://medium.com/javascript-in-plain-english/create-micro-frontends-using-web-components-with-support-for-angular-and-react-2d6db18f557a

本文：http://pub.intelligentx.net/creating-micro-frontends-using-web-components-support-angular-and-react

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

规模发展

微服务现在已经众所周知好几年了，并被广泛采用。但前端通常仍然是整体式的。这种应用程序结构通常反映在团队结构上：有几个独立的后端团队和一个单一的前端团队。这也阻止了后端开发团队提供完整的可用功能——他们总是缺少前端。要实施前端，所有更改必须由一个前端团队完成。这使得规模化开发变得困难。通过实现微型前端，我们可以组建一个完整的团队，他们可以自己发布完整的功能。这也是ThoughtWorks连续第三次将微型前端放在其著名技术雷达的“采用”部分的原因之一！

微前端组成

对于我们的用例，微型前端由标记（HTML）、样式（CSS）、脚本（JavaScript）和图像组成。我们希望在我们的页面中组成不同的微前端，或通常称之为“片段”。一些片段是交互的。一些片段可能依赖于某些片段。一些片段可能希望与其他片段交互。

有两种方法可以集成来自微前端的片段：客户端和服务器端。两者各有利弊。我们正在比较服务器端组合的不同方式，因为我们专注于搜索引擎优化。谷歌现在支持很多JavaScript，但索引需要更长的时间，这对一个频繁变化的网站是不利的，而其他一些爬虫根本不支持JavaScript。

此外，通过服务器端组合，对慢速移动客户端（如智能手机）的支持更好。移动客户端通常具有较慢的互联网连接，因此它们可以从较小的下载负载中获益。它们的计算能力也较低，因此它们可以从预先呈现的HTML中获益。

服务器端包括（SSI）

SSI是一种简单的服务器端脚本语言，允许使用条件语句并包含来自文件和URL的其他片段。

要在页面中包含另一个片段，请添加和SSI标记，如<--#include virtual=“/url/to/include”->。web服务器获取片段并用片段的内容替换SSI标记。组合输出返回给客户端。

要想更深入地了解SSI的作品，请看我的同事Artun Subasi去年在duesentrieb夏令营所做的介绍。

赞成的意见

• 久经考验
• 在Nginx、Apache和其他web服务器中得到很好的支持
• 支持超时和回退内容

弊端

• 片段以并行方式获取，但仅在获取最后一个片段后交付（Nginx）
• 没有对资产处理的内置支持。ApachePageSpeed（谷歌以前称为modpagespeed）可以进行一些CSS处理并结合片段中的CSS，但自2018年初以来没有收到任何更新，似乎已经死了

边缘侧包括（ESI）

ESI是一种简单的标记语言，允许包含来自其他URL的片段。

ESI的工作原理与SSI非常相似。ESI更侧重于反向代理或CDN层，而SSI则针对web服务器本身。当然，这些边界有些模糊，因为Nginx也经常用作反向代理。ESI本身没有条件逻辑。但Varnish允许在其自己的DSL（称为“VCL”）中使用条件逻辑。

赞成的意见

• 久经考验
• 清漆支持良好（并行抓取需要商业版）。Squid（项目网站已经过时，但有新版本）和Mongrel（自2010年以来没有新版本）也支持它

弊端

• 没有内置的超时支持。专有扩展确实存在。
• 互斥，使用基于CDN的ESI进行缓存
• 没有对资产处理的内置支持

Zalando Tailor

Tailor是一个节点。基于js的片段服务由Zalando开源，作为独立服务运行。它是Mosaic项目的一部分——Zalando的伞式项目——前端模块化。

Zalando Tailor使用自定义标记组成页面。它们定义<fragment src=”http://www.example.com“>-用于指定要加载的片段的标记。可以通过链接头由片段本身填充资源，如样式和脚本。

赞成的意见

• 对资产处理的内置支持
• 作为第一方概念的碎片
• 立即异步获取多个片段和流

弊端

• 专有解决方案，需要带有样式和AMD JS绑定的自定义链接头

Podium

Podium也用JavaScript实现并在节点上运行。js。它是由挪威芬恩公司开发的。没有他们的分类广告网站。Podium是一个将片段（他们称之为“podlet”）集成到页面（他们称页面为“布局”）中的库。

要运行podium，您至少需要两个实例：一个布局服务器和至少一个podlet服务器。podlet服务器公开片段，布局服务器将其集成到页面中。每个片段都需要公开一个“Podlet清单”，其中包含JSON数据资产，并且可能包含回退URL。布局服务器最初获取回退内容，并在Podlet服务器不可用时将其缓存。

赞成的意见

• 内置资产处理支持（片段需要公开元数据端点）
• 作为第一方概念的碎片
• 内置代理支持隐藏片段服务器
• Fragement服务器可以定义回退内容

弊端

• 专有解决方案，与库紧密耦合

最后的想法和建议

ESI和SSI是经过良好测试的稳定技术，易于学习。像Varnish的VCL这样的定制添加增加了复杂性，但引入了许多新的可能性。一般来说，这些解决方案对于资产处理并没有很好的解决方案，并且难以满足现代web应用程序的需求。

像Tailor和Zalando这样的更现代的解决方案解决了老式工具存在的许多问题。但是，他们引入了公平份额的复杂性，并有自己的学习曲线。这两个工具或多或少都是一个人的表演（如果你看贡献日志的话）。所以你应该准备好介入并继续发展，如果是Zalando或Finn。如果您将这些产品中的任何一种作为应用程序的基石，就不要放弃他们的解决方案。

为了更广泛地了解合成技术（包括客户端合成），我可以推荐bluesoft的这篇关于微前端的文章。如果你对微前端感兴趣，你应该看看MichaelGeers的《微前端行动》。

参考：

• 原文：https://www.esentri.com/composing-micro-frontends-server-side/
• 本文：http://jiagoushi.pro/node/1540

在任何合法的前端开发团队中，提高可扩展性和敏捷性很少会成为头等大事。在处理大型、复杂的产品时，如何确保快速、频繁地交付同时包含后端和前端的功能？像后端那样将前端单体分解成许多更小的部分似乎是答案。如果执行得当，微前端可以提高团队的有效性和效率。就是这样。

微前端背后的想法是将网站或 Web 应用程序视为由独立团队拥有的功能的组合。每个团队都有自己关心和擅长的不同业务领域或任务。团队是跨职能的，从数据库到用户界面，端到端地开发其功能。

将较大的问题分解为较小的问题以提高敏捷性、可重用性和可扩展性一直是 IT 的圣杯之一，过去二十年来该领域取得的进展令人震惊。但是，使用越来越大的代码库的新限制仍在不断出现。业内最有头脑的人一直在努力应对这一挑战，试图从技术和组织的角度来解决这个问题。迄今为止，微服务架构肯定仍然最接近解决它。

在本文中，您将学习：

• 微服务架构和微前端如何运作；
• 他们最大的优势是什么；
• 实施微前端时必须满足哪些要求；
• 您可以使用哪些技术或方法；
• 以及这些解决方案中的每一个如何相互比较。

微服务架构和微前端——它们解决了什么以及它们如何运作

微服务架构承诺：

• 更容易构建和维护应用程序
• 提高团队生产力
• 使用技术的灵活性
• 可扩展性

解决方案是将大型系统拆分为围绕明确定义的业务能力组织的细粒度、松散耦合的服务。然后，每个服务都足够小，可以由一个开发团队开发，并且可以快速调整以适应新的业务需求并进行部署，而不会破坏系统的其他部分。

这种方法的危险在于系统将被分解成许多不相关的应用程序。尽管这对开发人员来说很好处理，但这并不是用户对系统的期望；大多数人不喜欢使用大量的小型应用程序来完成他们的工作。因此，必须将为此过程分解的内容重新组合到用户界面中。

将碎片重新组合在一起

常见的方法是在用户和微服务之间构建一个单一的前端层。 对于每一个重要的系统，庞大的前端代码库都会威胁到微服务架构的好处。 这就是微前端的用武之地。

微前端的基本思想非常简单——将用户界面由多个围绕明确定义的业务能力组织起来的细粒度部分组成。 然后每个部分都足够小，可以由一个垂直结构的团队开发和拥有。 拥有前端和后端的团队建立了一个真正自给自足的功能团队。

然而不幸的是，微前端带来了同样的挑战，使得微服务难以实现。此外，任何捷径都可能以负面的方式影响用户体验。必须确保一致性、安全性、互操作性、性能、可扩展性和所有权，以确保无缝的用户界面。

尽管不同的微前端方法解决了各种问题，但还没有一个能够涵盖所有这些问题。但在我们深入研究这些不同方法的细节之前，让我们先仔细看看选择微前端的主要动机，以及与单体方法相比的优缺点。

 解释微前端的 3 大优势

微前端的优势#1：可扩展的团队设置

3 种不同的前端方法及其对团队组织的影响

选择微前端方法有很多很好的理由，但最重要的（如果不是最重要的）之一来自可扩展的团队设置。

至少可以确定影响开发团队组织的三种可能的前端架构：单片前端和后端、带有后端微服务的单片前端和微前端。下面，我们将描述每个团队组织的后果。

单片前端和后端

构建需要前端和后端的解决方案的常用方法是水平拆分项目并通过 REST API 在这些层之间进行通信。

如果系统足够小，可以供一个团队开发，最好的选择是保持架构简单。您可以通过创建单页应用程序 (SPA) 前端并通过 REST API 将其连接到后端来实现此目的。然后根据每一层所需的工作量调整您的团队设置。

良好的做法是确保从一开始您的代码就结构良好，并且当您的解决方案增长时，您可以引入另一个或两个团队，而无需重新构建它。

但是这种架构的局限性是显而易见的：团队修改代码库的次数越多，就需要更多的协调和集成，这会导致产品开发瘫痪。

带有后端微服务的单片前端

尤其是在大型企业中，对额外开发团队的需求通常从后端开始。 大多数系统需要大量的业务逻辑。 例如，它们需要在浏览器端无法完成的处理，或者与遗留系统的复杂集成。 在这些情况下，一个跨职能团队已经不够了。

大多数公司扩展其架构的第一步是垂直拆分后端代码库以解决复杂性。 前端被分配给一个专门的前端团队，而其余的工作则分配给各个后端团队。 因此，积压的项目被分解成块，并由不同的团队交付。 然后，这些团队要么通过合同谈判解决依赖关系，要么——以更敏捷的方法——通过大量积压计划来解决依赖关系。

这种方法带来的最大挑战是管理这些依赖关系和同步发布。 测试也变得很麻烦，因为您需要等待所有单独的部分到达测试环境才能验证它。

当解决方案必须嵌入来自不同产品 backlog 的功能时，它变得更加复杂（这种情况经常发生）。

在更大的范围内，这种方法需要大量的管理。 日常部署几乎是不可能的。 这就是为什么在具有复杂前端的大型企业中工作的开发人员和架构师寻求最终垂直扩展的解决方案，将前端添加到他们已经改变游戏规则的微服务架构 - 微前端。

微前端

为了快速开发、测试和发布其功能，团队需要能够在不依赖其他团队的情况下工作。 微前端可以在用户界面领域实现后端微服务的相同承诺，并且可以应用支持独立团队合作的相同原则。

在此设置中，前端和后端这两个领域紧密耦合，因为需求来自一个产品待办列表。 再一次，一个团队可以在一个简单的架构中交付整个功能。 如果执行得当，这不会影响用户体验。

为了很好地执行它，微前端带来了许多后端微服务已知的类似问题，必须解决。 否则，用户可能仍将系统感知或体验为不同特征的拼凑。

微前端的优势#2：技术选择自由

除了创建可扩展且独立的团队设置外，微前端方法还有助于处理应用于前端的大量技术。 每个季度都有关于如何开发面向用户的系统部分的新想法。 很多时候，新版本的框架甚至不向后兼容，这意味着每个版本实际上都是一个单独的框架。

微服务架构的优势之一是可以自由选择所使用的技术。当用户界面被拆分成独立的模块时，前端开发人员可以享有同样的自由——至少在一定程度上。

微前端的优势#3：弹性

任何系统的实际成本都不能很好地体现在代码库的初始开发成本上，而是体现在维护上。代码重构和系统重构的无休止螺旋的目的是保持与开始时相同的速度引入功能更改。

微前端架构通过引入以下约束使代码库更具弹性：

• 隔离变更的影响；
• 防止代码耦合；
• 并随着时间的推移保留架构。

这些约束防止不受控制的依赖关系、限制代码重用和强制服务边界。

不再有不受控制的依赖

多年来开发的大型应用程序不可避免地充满了难以跟踪和维护的代码依赖关系。开发人员在上市时间的压力下工作，或者只是试图优化他们的工作方式，会在代码的不同部分之间产生许多不受控制的依赖关系。当引入新的依赖项时，重用一些业务逻辑、缓存数据或资源池似乎总是一个好主意。后来发生的事情是这种共享功能变化的不可预见的后果。

通过将代码库分成几个不相连的部分，很容易避免这种依赖关系。由于两者之间的自然边界，一个微前端不可能重用其他微前端的现有功能。因此，更改的任何意外副作用仅限于一个微前端。

有限的代码重用

普遍遵循的原则不要重复自己（DRY）的目的是限制代码库的大小，从而降低出错的可能性。另一方面，开发成代码的每个抽象都引入了依赖性。随着时间的推移，抽象也经常出现必须根据特定的使用上下文进行调整。当您的微前端代码库仅限于几个功能时，开发人员不太可能试图创建这样的抽象。相反，当他们找到重用代码的机会时，他们只是复制并粘贴相关的片段，这通常比引入依赖项要好得多。

服务边界执行

系统的架构通常受某些分析和设计决策的影响。然而，决定某事和遵守这些决定往往是不一样的。在服务被拆分并就职责达成一致并记录在案之后，漂移就开始了。缺乏明确的边界或跨越边界的能力可能导致并允许开发人员破坏先前商定的设计。有一些工具，例如在 CI/CD 管道中实现的代码审查或依赖检查，但使用单独的微前端，不可能偏离约定的架构。

微前端的 6 个常见要求

为了不失去微前端的任何潜在好处，这种架构的实际实现必须满足一些共同的要求。以下六点很重要，不容忽视：

独立部署

——使用微前端的最大风险是，当它们没有正确实施时，它们将需要部署协调。除了将有意义的功能封装在单个组件中并始终确保向后兼容性的良好设计之外，组件本身必须可以一个一个地部署，而无需任何协调。

热部署

——开发某些应用程序片段的团队必须能够部署新版本而不会造成任何停机。必须考虑使用滚动更新或金丝雀部署等策略。使用带有经过深思熟虑的路径系统的高级 HTTP 路由机制可以提供很大帮助。

统一的样式/组件

——将应用程序构建为不兼容的拼贴块可能会对用户体验产生破坏性影响。如何确保视觉和行为一致性的问题必须从引入微前端的一开始就解决。该解决方案通常涵盖技术（共享 UX 库）和组织方面（共享 UX 团队）。

身份验证和授权

——显然，用户必须只进行一次身份验证。授权上下文和规则必须由前端和后端的所有组件共享。

跨组件通信

——即使组件之间的通信引入了耦合并因此应该避免，但很难想象一个应用程序由完全分离的部分组成。特定的微前端必须能够共享应用程序上下文（即用户或其他资源标识）并相互通知内部状态的变化。选择的通信方法应该更喜欢基于事件或地址栏的间接通信，而不是直接使用其他组件 API。

搜索引擎优化

——这种需求的严重程度取决于具体的用例，但对于某些应用程序来说，它是要解决的第一类公民。

微前端技术——解耦前端的 3 种方法

微前端技术可以分为三类，每一种技术都有一些优点和缺点。我们可以区分：

• 构建时集成——应用程序作为一个捆绑包生成，然后一次性交付给用户
• 服务器端集成——在提供页面的同时集成应用程序，用户浏览器获得完整的应用程序
• 客户端集成 – 应用程序分批交付给用户 Web 浏览器，然后集成到浏览器中

 下面我们通过使用像 Strava 或 Endomondo 这样的健身追踪应用程序的示例来仔细研究这三种方法中的每一种。这些应用程序中的每一个都具有相似的特性和功能，例如显示运动员个人资料摘要、他们的最新活动、一些正在进行的挑战等的仪表板。

构建时集成

解耦前端的第一种方法是将代码库组织在独立的存储库中。通过构建时集成，每个微前端都作为独立包构建和发布。完整的应用程序导入这些包并从包含的组件组成用户界面。

这样，在组织团队和适当划分团队之间的功能上稍加努力，就可以实现合理的团队独立性。虽然它不会提供微前端的所有可能好处，例如技术多样性或部署自主性，但它的优点是它不需要任何其他工具，除了开发人员已经使用的工具。

与其他方法相比，构建时集成简化了一致性保证。这也是减少传输到用户浏览器的数据量的最简单和最有效的方法，因为整个应用程序包在构建阶段进行了优化。

在我们的示例中设计健身跟踪应用程序时需要考虑的是使用组件之间的间接通信，这将减少耦合。

服务器端集成

第二种方法的总体思路如下图所示。

浏览器对页面 (1) 的请求来自“布局服务”，该服务首先为页面布局 (2) 请求“页面模板服务”。布局包含 HTML 兼容标签，其中包含要包含的页面片段的 URL (3)。 “布局服务”请求实现特定功能的所有包含部分调用服务的内容。布局服务的更高级实现并行执行查询 (4)，支持故障转移和快速响应流。

在检索到所有部分 (5) 之后，准备好请求页面的全部内容并将其返回到浏览器 (6)。

布局服务在从用户角度建立应用程序的一致行为方面发挥着核心作用，但它由独立开发和部署的部分组成。

当应用程序包含由许多独立尾部组成的页面时，服务器端集成非常有用，有些是用户特定的，有些是用户之间共享的，如电子商务网站通常具有的。

有很多技术可以应用这种模式，例如服务器端包含、边缘端包含和 Zalando 的带有“片段”标签的项目 Mosaic。

服务器端包括

服务器端包含 (SSI) 是一种由 Web 服务器解释的脚本语言，用于将一个或多个文件的内容包含到网页中。语言语法基于放置在 HTML 注释中的指令，这些指令由启用 SSI 的 Web 服务器处理。

<!--#directive parameter=value parameter=value -->

最常用的指令是“包含”，允许将一个文档包含到另一个文档中。包含的文档可以通过相对于当前文件目录的路径来引用。例如：

<!--#include file="footer.html" -->

更强大和推荐的选项是使用虚拟参数，它可以指定任何资源，包括 CGI 脚本或远程页面：

<!--# include virtual="/athlete/768769879/details" -->

该语言还提供变量和条件子句，以在页面上创建更多上下文感知内容。

SSI 受到流行的 Web 服务器（如 Apache 或 NGINX）的支持。

边侧包括

Edge Side Includes (ESI) 是一种用于边缘级动态 Web 内容组装的标记语言。 ESI 的目标是解决 Web 基础设施扩展和内容发布的问题。与 SSI 类似，它通过 esi:include 标签提供嵌入：

<esi:include src="http://befit.com/footer.html" />

条件执行命令与大量预定义变量相结合，可以在提供给用户的页面上实现真正的动态内容。

<esi:choose>
    <esi:when test="$(HTTP_COOKIE{group})=='Advanced'">
        <esi:include src="http://befit.com/advanced.html"/>
    </esi:when>
    <esi:when test="$(HTTP_COOKIE{group})=='Basic User'">
        <esi:include src="http://befit.com/basic.html"/>
    </esi:when>
    <esi:otherwise>
        <esi:include src="http://befit.com/new_user.html"/>
    </esi:otherwise>
</esi:choose>

缓存代理服务器（如 Varnish 或 Squid）支持 ESI。

Zalando的马赛克项目

Mosaic 内置于 Zalando，是首批成熟的、有目的的、用于实现服务器端集成的微前端框架之一。

Mosaic 架构的中心点是“Tailor”，即在这种服务器端微前端架构中实现布局服务。为了在页面中包含微前端，使用了“片段”标签：

<html>
<head>
    <script type="fragment" src="http://assets.befit.com"></script>
</head>
<body>
    <fragment src="http://athlete.befit.com"></fragment>
    <fragment src="http://trainng-log.befit.com" primary></fragment>
    <fragment src="http://challanges.befit.com" async></fragment>
</body>
</html>

与普通的 SSI 或 ESI 标签相比，片段标签提供了额外的有用属性：

• primary – 表示设置页面响应代码的片段
• timeout – 可选的片段超时时间（以毫秒为单位）（默认为 3000）
• async - 将片段推迟到正文标记的末尾
• public – 防止 Tailor 将过滤后的请求标头从上游转发到片段
• fallback-src – 在当前片段超时/错误的情况下回退片段的 URL

如上所述，Mosaic 旨在为微前端提供服务，并提供以下功能优势：

• 在后端编写预渲染标记。这对 SEO 很重要，并且可以加快初始渲染。
• 确保快速到达第一个字节。 Tailor 并行请求片段并尽快将它们流式传输，而不会阻塞页面的其余部分。
• 执行绩效预算。这在其他设置中非常具有挑战性，因为没有单一的点可以控制性能。
• 容错：呈现有意义的输出，即使页面片段失败或超时。

如果需要更复杂的模板管理，可以简单地从文件系统或专用服务提供页面模板。

马赛克的第二部分是船长。在 Innkeeper 的陪伴下，Skipper 建立了一个先进的 HTTP 路由器，可以在需要隐藏复杂的微服务世界时使用。 Skipper 本身提供了基于规则的 HTTP 请求路由，具有过滤和丰富功能。 Innkeeper 用作运行时 Skipper 规则管理的 API。

服务器端集成允许从微前端轻松编写应用程序，但它不能解决需要真正丰富的前端应用程序时出现的挑战。

客户端集成

最后但并非最不重要的一点是客户端集成方法。在这里，微前端的构建是将应用程序集成到用户 Web 浏览器中。应用程序的每个部分都独立交付给浏览器，然后应用程序在呈现时被粘合。

使用这种方法，在运行时构建应用程序不需要额外的基础设施，而且它似乎是最灵活的。应用程序组件可以共享一些用户上下文，因此就像在构建时集成的那样，而不会影响微前端的其他要求。

Iframes

iframes 是一种旧的客户端集成技术，可用于将一个 HTML 文档嵌入到另一个中。在微前端的上下文中，解决方案在于使用 iframe 标记嵌入每个微前端应用程序页面布局，其中 src 属性指向为应用程序提供服务的 URL。

与这种方法中的 SSI/ESI 类似，每个微前端都可以托管在不同的地址上。与 SSI/ESI 相反，客户端浏览器负责独立下载每个片段并显示完整页面。

<html>
   <body>
     <iframe src="http://athlete.befit.com" style="border: none;"/>
     <iframe src="http://trainng-log.befit.com" style="border: none;"/>
     <iframe src="http://challanges.befit.com" style="border: none;"/>
   </body>
</html>

要成为一个成熟的微前端，嵌入在 iframe 中的应用程序应该能够与其父级通信。这可以通过使用 window.postMessage() 方法来实现，但在大多数情况下，将这样一个低级 API 与一个从微前端的角度简化集成的库包装是一种很好的做法。

除了涵盖影响渲染内容状态的微前端之间的数据交换的标准用例之外，还需要启用父级和微前端之间的通信。后者确保 iframe 的大小适合微前端内容的大小。当 iframe 内容溢出时，必须将有关嵌入内容的实际大小的信息传播到父应用程序，并且必须由父应用程序调整 iframe 高度。

当微前端平台本身需要基于 iframe 的集成以确保父应用程序和微前端之间的最高级别隔离时，它的效果最好。在这种情况下，可以使用任何技术或框架创建微前端，包括在客户端集成中独一无二的简单遗留应用程序集成。

微前端的部署也不需要任何特殊的方式来构建或打包源代码。

iframe 方法确保部署新版本的微前端不会影响其他已经部署的微前端。这种技术自由保证了整个系统不会卡在某个框架中，因为不需要微前端的兼容性。这样可以根据每个开发团队的实际业务优先级来支付技术债务。

这种高度隔离简化了集成，但同时它会导致一些 UX 限制，在考虑您的集成解决方案时应该考虑这些限制。

当您的主要关注点在于 UX 设计时，iframe 绝对不是最佳选择。可以提供良好的 UX 设计（在响应式网页设计的情况下也是如此），但它比其他方法稍微复杂一些。主要限制是由于微前端内容不能超出 iframe 边界。例如，显示在多个 iframe 上的弹出窗口无法正确显示。

需要考虑的另一个因素是下载到浏览器的资源开销。特定微前端所需的每个资源（css、js等）都必须单独下载。尽管对于现在客户端使用的大多数工作站来说这可能不是问题，但请注意，仅将前端框架核心库的一个实例加载到内存中是不可能的。

Single SPA

Single SPA 是一个 JavaScript 框架，旨在构建由多个单页应用程序组成的用户界面，它承诺许多框架的共存。甚至同一框架的不同版本也可以混合在一个页面中。

使用 Single SPA 时，每个微前端都可以独立部署。另一个不错的功能是延迟加载代码。仅在需要时才加载特定的微前端包，这提高了应用程序的加载速度。

任何 Single SPA 应用程序的架构都包含两个概念：

• 应用程序——微前端本身。每个应用程序都可以响应 URL 路由事件，并且必须知道如何从 DOM 中引导、挂载和卸载自己。传统 SPA 和 Single SPA 应用程序之间的主要区别在于后者必须能够与其他应用程序共存，并且不能各自拥有自己的 HTML 页面。
• Single SPA config – 向单一 SPA 注册应用程序的 HTML 页面和 JavaScript。

将微前端嵌入到 Single SPA 中不需要对前端进行大量调整。新的微前端声明需要实现单个 SPA 生命周期函数并为主应用程序公开具有这些实现的文件。

单个 SPA 生命周期函数与 React 组件生命周期函数非常相似——对象 props 具有属性 domElementGetter，返回应该放置或删除微前端的 DOM 元素。

• bootstrap – 将在第一次安装微前端之前执行一次。
• mount - 将在满足激活功能条件（即正确的 URL）或手动安装微前端时执行。
• unmount – 将在不满足激活功能条件（即不正确的 URL）或手动卸载微前端时执行。

如何在代码中将前端应用程序标记为单个 SPA 微前端

如果要将前端应用程序标记为 Single SPA，第一步是准备一个主微前端文件并实现生命周期方法。这可以手动完成，但框架提供了一个方便的助手来完成它。

import React from 'react'
import ReactDOM from 'react-dom'
import singleSpaReact from 'single-spa-react'
import root from './root.component.js'

const reactLifecycles = singleSpaReact({
   React,
   ReactDOM,
   rootComponent: root
})

export function bootstrap(props) {
    return reactLifecycles.bootstrap(props);
}

export function mount(props) {
    return reactLifecycles.mount(props);
}

export function unmount(props) {
    return reactLifecycles.unmount(props);
}

在第二步中，您可以使用 Webpack 将您的应用程序捆绑到一个捆绑文件中，例如运动员.bundle.js，并从客户端可访问的任何服务器公开它。

如何在前端应用程序中使用 Single SPA 微前端

应用概念 = 单一 SPA 作为框架（The application concept = Single SPA as a framework）

第一步是在根应用程序中注册一个微前端。为此，您应该使用以下功能：

registerApplication(
    appName: string,
    applicationOrLoadingFn: () => <Function | Promise>,
    activityFn: (location) => boolean,
    customProps?: Object
);

 

• appName – 将在单水疗中用作标识符的名称
• applicationOrLoadingFn – 一个可以返回应用程序或应用程序承诺的函数
• activityFn – 一个函数，当必须安装应用程序时返回 true，当必须卸载应用程序时返回 false。
• customProps – 一个可选对象，无论何时调用它们都会传递给生命周期方法。

最后一步是 start() 单一 SPA 引擎，然后一切就绪。

import {registerApplication, start} from 'single-spa';

const domElementGetter = () => document.getElementById('micro-font-end-container');
const pathPrefix = (prefix) => {
   return (location) => location.pathname.startsWith(`${prefix}`);
}

registerApplication('athletes', () => import ('athletes.bundle.js'), 
pathPrefix('/athletes'), {domElementGetter});
registerApplication('challenges', () => import ('challenges.bundle.js'), 
pathPrefix('/challenges'), {domElementGetter});
start();

<html>
<body>
   <script src="/dist/root.js"></script>
   <a onclick="singleSpaNavigate('/athletes')">Go to athletes</a>
   <a onclick="singleSpaNavigate('/challenges)">Go to challenges</a> 
   <div id="micro-font-end-container">
       //i.e. here micro frontends can be injected
   </div>
</body>
</html>

包裹概念 = 作为库的单一 SPA （The parcel concept = Single SPA as a library）

当使用 Single SPA 作为框架时，容器应用程序是一个简单的应用程序容器，这些应用程序会根据根更改进行切换。 另一种选择是包裹概念。 在这里，您在任何框架中创建一个容器应用程序作为系统的基础，并且必须将包（或实际上是微前端）直接安装在特定位置。 这样一页可以包含多个微前端。 这更接近于将用户界面构建为解耦特征的组合，但同时可见和可访问的概念。

包裹也应该在正确的时间卸载。

在下面的示例中，使用 React 作为主要框架，因此 componentDidMount 和 componentWillUnmount 可用于挂载和卸载包裹。

class AthletesMicrofrontendComponent extends React.Component {

    componentDidMount() {
        SystemJS.import('athletes.bundle.js')
            .then(athletesApp => {
               const domElement = document.getElementById('athelete-micro-frontend-id');
               mountParcel(athletesApp, {domElement})
            });
    }

    render(){
       return <div id="athelete-micro-frontend-id"></div>
    }
    ...
}

微前端方案比较

下表总结并强调了每种方法的主要优势和劣势：

技术	类别	例子实现	优势	弱势	建议
构建时的包	构建时集成	NPN, yarn	易于设置 - 无需额外工具 为开发者所知 代码重复数据删除 轻松实现 UX 一致性	锁步释放过程——必须重新编译和部署整个包 仅限于一个框架	仅在其他选项似乎非常复杂时才用于小型项目（不超过三个团队）
SSI/ESI	服务器端集成	SSI – NGINX, Apache Http   ESI – Varnish, Squid	易于设置——HTTP 服务器和 Cashes 是每个 Web 应用程序架构的一部分 部署完全独立	缺乏跨组件通信——必须以其他方式解决 难以实现一致的用户体验观感 缺乏内置的身份验证和授权	当应用程序和服务架构波动较小的微服务时，用于电子商务等 Web 应用程序
专业的微前端中间件	服务器端集成	Zalando’s Mosaic,    Compoxure, micro-fe	部署完全独立 对页面性能和故障转移的出色控制 具有自动发现功能的内置高级动态路由	难以设置——需要额外的组件 缺乏跨组件通信——必须以其他方式解决 难以实现一致的用户体验观感 缺乏内置的身份验证和授权	当应用程序和服务架构波动较大的微服务时，用于类似 Web 应用程序的电子商务
Iframes	客户端集成		易于设置 - 无需额外工具   部署完全独立 高组件隔离 跨组件通信 真正的框架不可知论者	难以实现深度链接 难以实施 RWD 高资源消耗	当框架不可知和组件隔离是关键问题并且 UX 不是那么重要时使用
微前端框架	客户端集成	Single SPA	微前端和容器应用程序之间的完全集成 支持所有主要的 JS 框架 延迟加载	没有充分记录的引擎	在由许多通信微前端组成的丰富应用程序中使用

 

概括

如果你想充分利用你的微服务架构，微前端模式似乎真的是拼图中缺失的一块。 根据您的需求，确切的解决方案可能会有所不同。 例如，对于电子商务网站，您可以选择任何类型的服务器端集成。 但是，当您的目标是高级覆盖应用程序时，其中一种客户端技术将是您更好的解决方案。

如果您认为微前端仍然会带来太多麻烦，那么至少选择构建时模块化。 从长远来看，它总是会得到回报。

如果您对微前端及其实现有任何经验，请在下面分享。 我们很乐意收到您的想法和疑虑，并进一步讨论该主题。

原文：https://bluesoft.com/micro-frontends-the-missing-piece-of-the-puzzle-in…

本文：https://jiagoushi.pro/node/1812

single-spa 用于前端微服务的javascript框架

在过去的几周里，围绕微前沿(一些负面的，一些正面的)已经有了大量的讨论。

有一个tweet,真正吸引我的目光从乔尔丹宁‏,single-spa:

Funny how the many of the people recently criticizing #microfrontends (1) haven’t tried them, (2) don’t understand what they are, and (3) have attacked microfrontends and the people using them with almost a bully-like sarcasm.



I’m one of the main popularizers of them - AMA

 

当我看到一些新的和有争议的东西，像这样，我总是想自己尝试一下，看看所有的炒作是关于什么的，也让我可以形成自己的观点对这个主题。

这引导我创建了一个微前端应用程序，它呈现了两个单独的React应用程序和一个Vue应用程序。

在本教程中，我将分享我所学到的知识，并向您展示如何构建一个由React和Vue应用程序组成的微前端应用程序。

要查看此应用程序的最终代码，请单击这里。

single-spa

我们将使用的工具来创建我们的项目是单SPA -一个javascript框架的前端微服务。

单SPA允许您在单页面应用程序中使用多个框架，允许您根据功能拆分代码，并具有Angular、React和Vue。js等应用都生活在一起。

您可能已经习惯了Create React应用程序CLI和Vue CLI。使用这些工具，您可以快速启动整个项目，完成webpack配置、依赖项和样板文件。

如果您习惯了这种简单的设置，那么第一部分可能有些不和谐。这是因为我们将从头开始创建所有内容，包括安装所需的所有依赖项，以及从头开始创建webpack和babel配置。

如果您仍然好奇Single SPA是做什么的，或者为什么您可能想要使用微前端架构来构建，请查看这个视频。

开始

你需要做的第一件事是创建一个新的文件夹来保存应用程序，并切换到目录:

mkdir single-spa-app

cd single-spa-app

 

接下来，我们将初始化一个新包。json文件:

npm init -y

现在，这是有趣的部分。我们将安装此项目所需的所有依赖项。我将把它们分成不同的步骤。

安装普通的依赖关系

npm install react react-dom single-spa single-spa-react single-spa-vue vue

 

安装 babel 依赖

npm install @babel/core @babel/plugin-proposal-object-rest-spread @babel/plugin-syntax-dynamic-import @babel/preset-env @babel/preset-react babel-loader --save-dev

 

安装 webpack 依赖

npm install webpack webpack-cli webpack-dev-server clean-webpack-plugin css-loader html-loader style-loader vue-loader vue-template-compiler --save-dev

现在，所有依赖项都已安装，我们可以创建文件夹结构。

应用程序的主代码将位于src目录中。这个src目录将为每个应用程序保存子文件夹。让我们继续在src文件夹中创建react和vue应用程序文件夹:

mkdir src src/vue src/react

现在，我们可以为webpack和babel创建配置。

创建webpack配置

在主应用程序的根目录下，用以下代码创建一个webpack.config.js文件:

const path = require('path');
const webpack = require('webpack');
const { CleanWebpackPlugin } = require('clean-webpack-plugin');
const VueLoaderPlugin = require('vue-loader/lib/plugin')

module.exports = {
  mode: 'development',
  entry: {
    'single-spa.config': './single-spa.config.js',
  },
  output: {
    publicPath: '/dist/',
    filename: '[name].js',
    path: path.resolve(__dirname, 'dist'),
  },
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }, {
        test: /\.js$/,
        exclude: [path.resolve(__dirname, 'node_modules')],
        loader: 'babel-loader',
      },
      {
        test: /\.vue$/,
        loader: 'vue-loader'
      }
    ],
  },
  node: {
    fs: 'empty'
  },
  resolve: {
    alias: {
      vue: 'vue/dist/vue.js'
    },
    modules: [path.resolve(__dirname, 'node_modules')],
  },
  plugins: [
    new CleanWebpackPlugin(),
    new VueLoaderPlugin()
  ],
  devtool: 'source-map',
  externals: [],
  devServer: {
    historyApiFallback: true
  }
};

 

创建babel 配置

在主应用程序的根目录下，用下面的代码创建一个.babelrc文件:

{
  "presets": [
    ["@babel/preset-env", {
      "targets": {
        "browsers": ["last 2 versions"]
      }
    }],
    ["@babel/preset-react"]
  ],
  "plugins": [
    "@babel/plugin-syntax-dynamic-import",
    "@babel/plugin-proposal-object-rest-spread"
  ]
}

初始化Single-spa

注册应用程序是我们告诉single-spa何时以及如何引导、挂载和卸载应用程序的方式。

在webpack.config.js文件中，我们将入口点设置为single-spa.config.js。

让我们继续在项目的根目录中创建该文件并配置它。

single-spa.config.js

import { registerApplication, start } from 'single-spa'

registerApplication(
  'vue', 
  () => import('./src/vue/vue.app.js'),
  () => location.pathname === "/react" ? false : true
);

registerApplication(
  'react',
  () => import('./src/react/main.app.js'),
  () => location.pathname === "/vue"  ? false : true
);

start();

这个文件是您注册所有应用程序的地方，这些应用程序将是主单页应用程序的一部分。每次调用registerApplication都会注册一个新应用程序，并接受三个参数:

1. App name
2. Loading function (what entrypoint to load)
3. Activity function (logic to tell whether to load the app)

接下来，我们需要为每个应用程序创建代码。

React 应用

在src/react中，创建以下两个文件:

touch main.app.js root.component.js

src/react/main.app.js

 

import React from 'react';
import ReactDOM from 'react-dom';
import singleSpaReact from 'single-spa-react';
import Home from './root.component.js';

function domElementGetter() {
  return document.getElementById("react")
}

const reactLifecycles = singleSpaReact({
  React,
  ReactDOM,
  rootComponent: Home,
  domElementGetter,
})

export const bootstrap = [
  reactLifecycles.bootstrap,
];

export const mount = [
  reactLifecycles.mount,
];

export const unmount = [
  reactLifecycles.unmount,
];

src/react/root.component.js

import React from "react"

const App = () => <h1>Hello from React</h1>

export default App

Vue应用

在src/vue中，创建以下两个文件:

touch vue.app.js main.vue

src/vue/vue.app.js

import Vue from 'vue';
import singleSpaVue from 'single-spa-vue';
import Hello from './main.vue'

const vueLifecycles = singleSpaVue({
  Vue,
  appOptions: {
    el: '#vue',
    render: r => r(Hello)
  } 
});

export const bootstrap = [
  vueLifecycles.bootstrap,
];

export const mount = [
  vueLifecycles.mount,
];

export const unmount = [
  vueLifecycles.unmount,
];

src/vue/main.vue

<template>
  <div>
      <h1>Hello from Vue</h1>
  </div>
</template>

接下来，在应用程序的根目录中创建index.html文件:

touch index.html

index . html

<html>
  <body>
    <div id="react"></div>
    <div id="vue"></div>
    <script src="/dist/single-spa.config.js"></script>
  </body>
</html>

更新Package.json使用脚本

要运行这个应用程序，让我们在package.json中添加start脚本和build脚本:

"scripts": {
  "start": "webpack-dev-server --open",
  "build": "webpack --config webpack.config.js -p"
}

运行应用程序

要运行该应用程序，请运行start脚本:

npm start

现在，你可以访问以下网址:

# renders both apps
http://localhost:8080/

# renders only react
http://localhost:8080/react

# renders only vue
http://localhost:8080/vue

要查看此应用程序的最终代码，请单击这里。

结论

总的来说，除了所有的初始样板设置外，设置这个项目相当简单。

我认为，在未来，如果能有某种CLI来处理大部分样板文件和初始项目设置，那就太好了。

如果您需要这种类型的架构，那么Single-spa无疑是目前最成熟的方式，并且非常适合您的工作。

 

原文：https://dev.to/dabit3/building-micro-frontends-with-react-vue-and-single-spa-52op

本文：http://pub.intelligentx.net/building-micro-frontends-react-vue-and-single-spa

讨论：请加入知识星球或者小红圈【首席架构师圈】

微服务架构的特点是独立服务，这些服务专注于特定的业务功能，并由小型、自包含的团队维护。 微服务架构经常用于在 AWS 上开发的 Web 应用程序，这是有充分理由的。 它们提供了许多众所周知的好处，例如开发敏捷性、技术自由、有针对性的部署等等。 尽管微服务很受欢迎，但许多前端应用程序仍然以单体风格构建。 例如，他们有一个与所有后端微服务交互的大型代码库，并由一大群开发人员维护。

图 1. 带有单体前端的微服务后端

什么是微前端？

微前端架构将微服务开发原则引入前端应用程序。 在微前端架构中，开发团队独立构建和部署“子”前端应用程序。 这些应用程序由“父”前端应用程序组合而成，该前端应用程序充当容器来检索、显示和集成各种子应用程序。 在此父/子模型中，用户与看似单个应用程序的交互。 实际上，他们正在与由不同团队发布的多个独立应用程序进行交互。

图 2. 带有微前端的微服务后端

微前端的好处

与单体前端相比，微前端具有以下优势：

• 独立工件：微服务开发的核心原则是工件可以独立部署，这对于微前端仍然适用。在微前端架构中，团队应该能够独立部署他们的前端应用程序，而对其他服务的影响最小。这些更改将反映在父应用程序中。
• 自治团队：每个团队都是各自领域的专家。例如，计费服务团队成员具有专业知识。这包括与计费服务相关的数据模型、业务需求、API 调用和用户交互。与规模更大、专业性较低的团队相比，这些知识使团队能够更快地开发计费前端。
• 灵活的技术选择：自治允许每个团队做出独立于其他团队的技术选择。例如，计费服务团队可以使用 Vue.js 开发他们的微前端，而配置文件服务团队可以使用 Angular 开发他们的前端。
• 可扩展的开发：微前端开发团队更小，能够在不干扰其他团队的情况下进行操作。这使我们能够通过组建新团队以通过子应用程序提供额外的前端功能来快速扩展开发。
• 更容易维护：保持前端存储库小而专业，可以更容易地理解它们，这简化了长期维护和测试。例如，如果您想更改单体前端的交互，则必须在大型代码库的上下文中隔离功能的位置和依赖关系。在处理与微前端相关的较小代码库时，这种类型的操作会大大简化。

微前端挑战

相反，微前端提出了以下挑战：

• 父/子集成：微前端引入了确保父应用程序以与单体应用程序相同的一致性和性能显示子应用程序的任务。这一点将在下一节中进一步讨论。
• 运营开销：微前端应用程序不是管理单个前端应用程序，而是涉及为所有团队创建和管理单独的基础架构。
• 一致的用户体验：为了保持一致的用户体验，子应用程序必须使用相同的 UI 组件、CSS 库、交互、错误处理等。对于处于开发生命周期不同阶段的子应用程序，保持用户体验的一致性可能很困难。

构建微前端

微前端架构模式最困难的挑战是将子应用程序与父应用程序集成。优先考虑用户体验对于任何前端应用程序都至关重要。在微前端的上下文中，这意味着确保用户可以在父应用程序中从一个子应用程序无缝导航到另一个子应用程序。我们希望避免破坏性行为，例如页面刷新或多次登录。在最基本的定义中，父/子集成涉及父应用程序在加载父应用程序时动态检索和呈现子应用程序。渲染子应用程序取决于子应用程序的构建方式，这可以通过多种方式完成。两种最流行的父/子集成方法是：

将每个子应用程序构建为 Web 组件。

将每个子应用程序作为独立模块导入。这些模块要么声明一个函数来呈现自身，要么由父应用程序动态导入（例如使用模块联合）。

将子应用注册为 Web 组件：

<html>
    <head>
        <script src="https://shipping.example.com/shipping-service.js"></script>
        <script src="https://profile.example.com/profile-service.js"></script>
        <script src="https://billing.example.com/billing-service.js"></script>
        <title>Parent Application</title>
    </head>
    <body>
        <shipping-service />
        <profile-service />
        <billing-service />
    </body>
</html>

将子应用注册为模块：

<html>
    <head>
        <script src="https://shipping.example.com/shipping-service.js"></script>
        <script src="https://profile.example.com/profile-service.js"></script>
        <script src="https://billing.example.com/billing-service.js"></script>
     <title>Parent Application</title>
    </head>
    <body>
    </body>
    <script>
        // Load and render the child applications form their JS bundles.
    </script>
</html>

下图显示了一个基于 AWS 构建的示例微前端架构。

Figure 3. Micro-frontend architecture on AWS

在此示例中，每个服务团队都在运行一个单独的、相同的堆栈来构建他们的应用程序。他们使用 AWS 开发人员工具并使用 Amazon CloudFront 将应用程序部署到 Amazon Simple Storage Service (S3)。 CI/CD 管道使用共享组件，例如 CSS 库、API 包装器或存储在 AWS CodeArtifact 中的自定义模块。这有助于提高父应用程序和子应用程序之间的一致性。

当您检索父应用程序时，它应该会提示您登录身份提供程序并检索 JWT。在此示例中，身份提供商是 Amazon Cognito 用户池。成功登录后，父应用程序从 CloudFront 检索子应用程序并将它们呈现在父应用程序中。或者，当您导航到特定路线时，父应用程序可以选择按需呈现子应用程序。子应用程序不应要求您再次登录到 Amazon Cognito 用户池。应将它们配置为使用父应用程序获取的 JWT，或者从 Amazon Cognito 静默检索新的 JWT。

结论

微前端架构为前端应用程序引入了微服务开发的许多熟悉的好处。微前端架构还允许您管理小型独立组件，从而简化构建复杂前端应用程序的过程。

原文：https://aws.amazon.com/blogs/architecture/micro-frontend-architectures-…

本文：

 

 

在这篇文章中，如果您对第2部分的实现细节感兴趣，我将概述微前端背后的概念。

它是什么，为什么我需要它?

让我们从why部分开始，当单页面应用程序启动的时候，大多数应用程序都非常小，并且由一个FE团队管理，一切都很好……

随着时间的推移，应用程序变得越来越大，管理它们的团队也越来越大。没有必要过多地讨论拥有大型代码库和大型团队的问题……

“微前端”这个术语最近被频繁使用，它提供了一个类似于微服务的概念，我们可以将单个前端应用程序拆分为微应用程序，这些微应用程序可以加载到用户浏览器上运行的单个容器应用程序中。每个应用程序都可以有自己的代码库，由一个面向业务的团队管理，他们可以独立地测试和部署他们的微应用程序。

(taken from https://micro-frontends.org/)

 

虽然这个概念本身听起来很有希望，但是缺乏实际的实现。特别是那些可以应用于现有大型应用程序的应用程序。

选择

一种可能的解决方案是使用良好的旧Iframe，它在封装和独立性方面提供了许多优势，但它是一种旧技术，并且存在严重的规模问题。

除了iframe之外，Web组件这个术语也出现了一段时间。

Web组件是一种解决方案，您可以在其中创建可以独立运行的自定义DOM元素，并提供分离和css封装，虽然这听起来是正确的方向，但Web组件离实际的解决方案还很远。它们更多的是一个概念，其背后的特性，如shadow DOM仍然缺乏完整的浏览器支持。

我们的解决方案

在Outbrain，我们一直面临着大多数资深SPA (单应用)所面临的问题，我们有一个庞大的FE应用程序，有一个庞大的团队来管理它，它变得越来越粗糙。看到在野外没有出色的MFE解决方案，我们决定尝试寻找一个我们自己的解决方案，一个可以在我们现有的echo系统上快速实现的解决方案。

我们定义了几个关键点，我们认为任何解决方案都必须应用MFE。

独立模式

每个微应用都应该能够完全独立运行，所以每个负责给定应用的团队都应该能够独立于其他应用运行。

这意味着每个应用程序应该托管在一个单独的代码基上，并且能够在开发人员的计算机上本地运行，以及在开发和测试环境中运行。

部署

可以独立每个服务部署到任何环境包括生产为了让业主团队的自由而不干扰其他团队工作,如果一个bug修复需要部署到生产在周末没有其他团队应该参与。

测试

在每个微应用程序上独立运行测试，这样一个应用程序中的bug很容易识别，不会反映到其他应用程序上。也就是说，有必要进行一些集成测试来检查应用程序之间的接口，并确保它们没有被破坏，这些测试应该由所有团队监控。

一个到多个

我们希望能够多次使用每个微应用程序，一个微应用程序不应该关心它在哪里运行，只知道它的输入和输出。

运行时分离和封装

重要的是，每个应用程序在运行时环境中都要沙箱化，这样应用程序之间就不会相互干扰，这包括CSS封装、JS命名空间和HTML分离。

常见的资源共享

因为我们不想要加载大型模块,如角,lodash和多次CSS样式的应用程序是很重要的微型应用程序能够共享公共资源,也就是说,我们也希望能够允许他们只封装资源相关,或封装在应用程序资源有不同的版本,例如应用程序使用lodash 3和应用程序B想迁移到lodash 4。我们不希望等到所有的应用程序都迁移之后才能升级。

通讯

需要有一种解耦的方式，让应用程序在不真正了解彼此的情况下彼此通信，只需要通过预定义的接口和API。

向后兼容性

由于我们不打算重写庞大的代码库，所以我们需要一些可以插入到当前系统的东西，以及可以由其他团队管理的逐渐独立的部分。

Web组件

最后,任何解决方案我们应该尽可能一致的web组件的概念,尽管它目前只是一个概念,似乎这就是未来是标题,如果将来任何解决方案出现,将自己与未来这将帮助我们采取的解决方案。

第2部分

在接下来的部分中，我将详细介绍我们是如何实现这一目标的，以及我们是如何通过写作来实现这一目标的。

下一部分的内容包括Angular、Webpack和一些美味的加载器。

原文：https://medium.com/outbrain-engineering/micro-front-ends-doing-it-angular-style-part-1-219c842fd02e

本文：http://pub.intelligentx.net/micro-front-ends-doing-it-angular-style-part-1

讨论：请加入知识星球或者小红圈【首席架构师圈】

在前一部分中，我讨论了转向MFE解决方案的动机以及解决方案相关的一些标准。在这一部分中，我将介绍我们如何在Outbrain实现它。

正如我在前一部分中提到的，其中一个标准是能够与我们当前的技术echo系统集成的解决方案，并且不需要对我们当前维护的应用程序进行什么更改。

进入Angular惰性加载特性模块

Angular有一个内建的模块概念，它基本上是一个声明对象，用来指定封装在一个模块中的所有组件、指令、服务和其他模块。

@NgModule({
imports: [CommonModule],
declarations: [ WelcomeComponent],
bootstrap: [],
entryComponents: []
})export class AppB_Module {}

通过将模块文件指定为Webpack入口点，我们可以将整个Angular模块(包括css和html)打包为一个单独的js文件。

entry: {

'appB_module': './app/appB.prod.module.ts'

}

使用Angular的延迟加载机制，我们可以动态加载这个js文件并引导到当前的应用程序中。

const routes: Routes = [

{

path: appB,

loadChildren: '/appB/appB_Module#AppB_Module'

}

]

这是朝着将应用程序分离为一个小型应用程序的目标迈出的一大步。

从功能模块转移到迷你应用程序

角功能模块以及Webpack捆绑销售给我们我们需要的代码分离,但这是不够的,因为Webpack只允许我们创建包作为一个构建过程的一部分,我们希望能够产生一个单独的JS包,这是建立在不同的时间,从一个单独的代码在一个单独的构建系统,可以在运行时加载到应用程序和共享公共资源,如角。

为了解决这个问题，我们必须创建自己的Webpack加载器，称为share-loader。

share -loader允许我们指定希望在应用程序之间共享的模块列表，它将一个给定的模块捆绑到一个应用程序js捆绑包中，并提供一个其他捆绑包访问该模块的名称空间。

应用程序A webpack.config:

rules: [

 {

   test: /\.js?$/,

   use: [{

     loader: 'share-loader',

     options: {

       modules: [/@angular/, /@lodash/],

       namespace: 'container-app'

     }

   }]

 }

应用程序B webpack.json

 

const {Externals} = require('share-loader');…externals: [
 Externals({
   namespace: 'container-app',
   modules: [/@angular/, /@lodash/]
 })
],
output: {
 library: 'appB',
 libraryTarget: 'umd'
},

在这个例子中，我们告诉Webpack将angular和lodash捆绑到应用程序A中，并在“容器-应用程序”命名空间下公开它。

在应用程序B中，我们定义angular和lodash不会绑定在一起，而是由命名空间“container-app”指向它们。

通过这种方式，我们可以跨应用程序共享一些模块，但是维护我们不希望共享的其他模块。

到目前为止,我们已经解决的几个关键的我们以前的文章中指定,我们现在有两个应用程序可以运行独立或在运行时加载远程虽然裹着js名称空间和css和html封装,他们之间也可以分享模块,封装模块不应该共享,现在让我们看看一些其他关键的我们所提到的。

DOM封装

为了解决css封装我们包装每个迷你应用程序与一个通用的角组件,该组件使用角css封装特性,我们有两个选择,我们可以使用模拟模式或本地模式根据我们需要的浏览器支持,不管怎样我们确保css不会泄漏。

@Component({

  selector: 'ob-externals-wrapper',

  template: require('./externals-wrapper.component.pug')(),

  styleUrls: ['./externals-wrapper.component.less'],

  encapsulation: ViewEncapsulation.Native

})

这个包装器组件还充当每个迷你应用程序和其他应用程序之间的通信层。所有的通信都是通过一个由每个包装器实例承载的事件总线实例来完成的，通过使用一个事件系统，我们有一种解耦的方式来通信数据的输入和输出，当一个小型应用程序从主应用程序中清除时，我们可以很容易地清除这种方式。

如果我们看看我们迄今为止的情况,我们可以看到,我们有一个解决方案是非常内联与web组件的概念,每个迷你应用程序是由一个独立的包装组件,封装所有js html和css,所有通信通过一个事件系统。

测试

由于每个应用程序也可以独立运行，所以我们可以在每个应用程序上独立运行测试套件，这意味着每个应用程序所有者都知道他的更改何时破坏了应用程序，并且每个团队主要关心他们自己的应用程序。

部署和服务

为了为每个应用程序提供自己的部署，我们为每个应用程序创建了一个节点服务，每当一个团队创建一个新的应用程序部署时，都会创建一个封装应用程序的js包，每个服务都会公开一个端点，该端点返回到包的路径。在运行时，当一个小型应用程序加载到容器应用程序中时，将调用端点并将js文件加载到应用程序并引导到主应用程序。这样，每个应用程序都可以单独构建部署。

例子:

没有什么比示例更好的了，如果您想尝试一下，可以到share-loader repo查看Readme中的示例和example-cli部分。

演示可以在回购本身，享受..

结束笔记:

感谢你的阅读!我希望本文能够帮助正在考虑这一举措的公司认识到，通过彻底改革代码库是有可能做到这一点的。

移动到微前端方法是朝着正确的方向移动，因为应用程序越大，速度越小。

本文展示了一个使用Angular作为框架的解决方案，类似的解决方案也可以使用其他框架来实现。

 

原文：https://medium.com/outbrain-engineering/micro-front-ends-doing-it-angular-style-part-2-1393ced4ceab?

本文:http://pub.intelligentx.net/micro-front-ends-doing-it-angular-style-part-2

讨论:请加入知识星球或者小红圈【首席架构师圈】

我们最近在实用主义者的微前沿黑客马拉松上发表了什么。

 

什么是微前端?

它是将大型web应用程序设计为由小型子应用程序组成的概念。这个想法与微服务非常相似。区别在于微服务是独立的后端服务，而微前端，顾名思义，是独立的前端组件。如果将这两种体系结构模式组合在一起，就可以设计自包含的应用程序。这意味着我们可以将大型系统垂直地分割成独立的部分，在理想的情况下，每个部分都有自己的前端、后端服务和数据库(如果需要的话)。这听起来像是一个摆脱单一UI的完美方法，支持独立且可伸缩的组件!

简单真实的例子

假设我们要实现一个在线商店。它应该有一个可用产品的列表。客户可以将产品添加到购物车中。从购物车级别来看，应该可以下订单。可选地，推荐系统可以推荐可能引起客户兴趣的产品。

布局

在web页面上有两种定位子应用程序的方法:

• 每个页面一个应用程序——每当URL更改时，都会加载一个新的应用程序

• 每个页面有许多应用程序——一个URL可以访问显示在单个页面上的许多小应用程序。

我们如何实现它?

每个应用程序前端可以从不同的位置提供服务，并具有自己的API。为了实现它，我们需要一个模板，它将应用程序呈现在特定的屏幕位置。我们可以通过两种方式实现:服务器端或客户端。

对于服务器端，我们可以使用:

• 启用ESI模块的清漆。有关详细信息，请参见https://varnish-cache.org/docs/3.0/tutorial/esi.html
• NGINX作为启用SSI和ngx_pagespeed模块的反向代理。有关详细信息，请参见https://www.thoughtworks.com/talks/a-high- performance mansolution to microservice-ui-composition

对于客户端，我们可以使用:

• iFrames — ugly solution with lots of problems. For details, please see http://www.rwblackburn.com/iframe-evil/
• Web Components — sample implementation is here: https://micro-frontends.org/
• hinclude library
• H-include library
• Single SPA library

服务器端和客户端都有各自的优缺点，但我更关注客户端。

微前端的优势

1. 应用程序是自包含的——这意味着更高的内聚性，因为每个应用程序只有一个职责。
2. 应用程序可以独立开发——开发人员可以专注于他们的工作并交付业务价值;不需要与其他团队进行技术同步。
3. 应用程序可以独立部署——部署应用程序时可以自由选择，不会对系统的其他部分造成负面影响。
4. 应用程序可以在不同的技术中实现——在前端技术快速发展的世界中，选择一个理想的JS框架是不可能的，这在未来两年内不会被视为遗留问题。如果我们可以使用一个新的框架来编写代码，而不用重写现有的系统，那不是很棒吗?使用微前端，我们可以组合许多框架。额外的好处是，我们可以选择我们喜欢的技术，或者与我们团队的技能相匹配的技术!

 

潜在的问题

1. 一致的外观和感觉。我们如何执行它?我们可以使用共享的CSS样式表，但这意味着所有应用程序都依赖于一个公共资源。有更好的方法吗?答案是肯定的，也不是。没有完美的解决方案，但是我建议为每个应用程序使用单独的样式表。冗余导致用户获取更多数据，从而影响应用程序的加载时间。此外，组件必须至少实现一次，这将影响开发成本和一致性。这种方法的好处是独立性。这样，我们就可以避免团队在开发和部署期间的同步问题。有一个共同的风格指南，例如在Zeplin中设计的，有助于保持整个系统的外观和感觉一致(但不相同)。或者，我们可以使用每个应用程序包含的公共组件库。这种解决方案的缺点是，每当有人更改库时，他们必须确保不会破坏依赖的应用程序。它会引入一个巨大的惯性。此外，库在大多数情况下只能由一个框架使用。实现一个UI组件库没有简单的方法，Angular和React应用程序可以使用这个库。
2. 缓慢的加载。如果我们要使用至少两个JS框架(例如，两个应用程序使用Angular，一个使用React)，那么我们的web浏览器必须获取大量数据。
3. 整体的复杂性。如何将不同技术和由不同团队创建的应用程序编排并组合成一个产品?

让我们开始一个概念项目的客户端证明

我们的目标是:

1. 创建带有顶部标题和左侧导航栏的类似门户的应用程序，
2. 导航栏有打开子应用程序的链接，
3. 每个子应用程序都可以用不同的技术实现(比如Angular 5、React 15和React 16)，
4. 我们可以在一个页面上呈现一个子应用程序，
5. 我们可以在一个页面上呈现许多子应用程序，
6. 每个子应用程序都可以独立部署并托管在不同的服务器上，
7. CSS样式表是独立的，
8. 子应用程序之间的通信是可能的。

核心框架

单个SPA库对于引导项目非常有用。它的功能如下:

1. 在同一页面上使用多个框架而不刷新页面，
2. 改进初始加载时间的延迟加载代码，
3. 顶级路由。

那听起来很棒!让我们继续!

概念项目结构证明

我们将创建3个模块:

1. 子app- Angular - Angular 5应用，
2. 子应用程序-反应物-反应应用程序，
3. main-app - React 15应用;它是一个模板模块，将sub-app-angular和sub-app-react16聚合为一个“门户”应用程序。

我们可以使用create-反应物-app来创建新的React子app-react16和main-app应用程序，以及Angular CLI来创建子app- Angular。由于这些启动程序，我们能够跳过耗时的新项目设置。

 

部署

我们希望有3个运行的服务器:

1. http://localhost:3000，服务于main-app应用程序。用户将使用它在web浏览器中打开门户。
2. http://localhost:3001，提供子app-angular包。
3. http://localhost:3002，服务于子app-react16 bundle。

这意味着，无论何时我们决定必须更新Angular应用程序(因为bug修复)，我们都必须构建新的包，并将它们复制到http://localhost:3001上提供的文件夹中。

子应用等进行实现细节

为了将模块导出为子应用程序，我们需要从入口点JS文件导出3个生命周期函数:

1. 引导-将被调用一次，就在注册的应用程序第一次挂载之前，
2. 挂载-当已注册的应用程式挂载时，
3. 卸载——将在卸载已注册的应用程序时调用。

幸运的是，我们不必手动实现这些函数，因为Single SPA为最常见的JS框架提供了默认实现。我们必须做的是在包中包含单spa-react和单spa-angular2库。json文件并编写一段代码。

React应用程序入口点文件可以是这样的:

React 16应用程序的入口点

我们必须为单spa反应提供以下特性:

• rootComponent —用于呈现React应用程序的根组件，
• domElementGetter ----函数，返回应用程序要呈现的DOM元素。

Angular应用程序入口点文件可以是这样的:

Angular 5应用程序的入口点

我们必须为单spa-angular2提供以下属性:

• mainModule -应用根Angular模块，
• domElementGetter——函数返回应用程序要呈现的DOM元素，
• template- Angular模板。

您可能想知道主应用程序在从服务器获取引导、挂载和卸载函数后如何找到它们。答案是我们必须做一些假设。我们假设，在获取并执行所有Angular应用程序包之后，这些函数都可以在窗口中访问。angularApp对象。类似地，对于React应用程序，我们希望在窗口中有这些函数。reactApp对象。这意味着子应用程序和模板都需要知道单个SPA生命周期函数的全局名称空间中的位置。我们可以将它称为子应用程序与其容器之间的契约。

我们如何执行这些函数的目标位置?我们当然可以使用Webpack !为此，我们必须向module.exports添加2个条目。每个子应用程序的Webpack配置文件中的输出对象。

对于React应用程序，它可能是这样的:

将React应用程序导出为window.reactApp

对于Angular应用程序，它可能是这样的:

将Angular应用程序导出为window.angularApp

太酷了!现在，我们准备配置一个模板项目——主应用程序。我们要做的是渲染:

• sub-app-react16 for /react or / in address bar
• sub-app-angular for /angular or / in address bar

模板工程实现

我们必须为子应用程序准备DOM占位符元素:

子应用等进行容器

接下来，我们必须将single-spa库添加到包中。json文件。

现在，我们准备在单个SPA库中注册子应用程序。React子应用程序由registerReactApp函数调用注册，Angular子应用程序由registerAngularApp函数调用注册。最后，我们必须启动单个SPA库。

main-app入口文件

registerReactApp是这样的:

反应应用程序注册

registerAngularApp是这样的:

角应用程序注册

singleSpa的registerApplication方法需要:

• 要注册的应用程序的逻辑名称，
• 应用程序加载器，它是一个函数返回承诺，解析为引导，挂载和卸载子应用程序提供的函数，
• 接受窗口的函数(谓词)。location作为第一个参数，并在应用程序应该为给定URL激活时返回true。

我们需要一些公用工具:

runScript函数获取外部JS脚本文件，并通过向文档添加一个新的脚本元素来运行它。

您可能会注意到子应用程序和模板项目之间的第二个约定:子应用程序和模板都需要知道子应用程序容器的DOM元素ID。

现在让我们看看我们取得了什么成果:

它完美地!

CSS样式表独立

在理想情况下，所有子应用程序都应该是独立的。这意味着不应该提供CSS选择器，这将影响其他子应用程序，例如:按钮，h1等。

因为我们的测试项目使用PostCSS，所以我们可以利用它提供的插件。其中之一是postcss-wrap。它将CSS规则封装在一个名称空间中，例如.selector{}被转换成.namespace .selector{}。在我们的示例中，每个子应用程序可能有自己的名称空间，仅限于其容器标识符。

这意味着对于使用ID React -app在DOM元素中呈现的React应用程序，所有CSS选择器都可以使用# React -app作为前缀。

为此，我们必须将postcss-wrap库添加到React应用程序依赖项中，然后在Webpack配置文件中配置它。它可以是这样的:

postcss-wrap Webpack配置的示例

最后，您可以看到引导样式表的作用域仅限于React应用程序:

带有名称空间的CSS选择器

这是一个非常简单和功能齐全的解决方案!

应用程序之间的通信

最后缺少的是应用程序间的通信。应用程序在理论上是独立的，但是它们可以对其他应用程序发送的一些事件作出响应。因为我们讨论的是事件，而不是直接同步调用，所以它不会在应用程序之间引入直接耦合。

您可能会注意到，React 16应用程序显示当前时间。我们可以实现的是从Angular应用程序发送的一个事件，它会停止或启动时钟。

我们如何在应用程序之间发送事件?最简单的方法是使用本地web浏览器事件机制，它不需要任何额外的库。

我们可以像这样从Angular应用程序发送一个事件:

发送toggleClock事件

此事件的接收者是React应用程序中的时钟组件。它可以在应用程序挂载时订阅，也可以在卸载时取消订阅:

现在通信已经准备好了。很简单的代码!

总结

我们所验证的是，基于客户端呈现的实现(由单个SPA库支持)可能是一个可行的选择。可能还有一些潜在的问题。

需要调查:

• 如果应用程序使用相同的库(例如Lodash)，但是版本不同，它会工作得很好吗?
• 有没有办法卸载不再使用的应用程序的JS代码?

可以改进的地方:

• 包缓存。下载自上次使用以来没有更改过的代码基没有任何意义。
• 减少模板应用程序和子应用程序之间的耦合。目前，主应用程序已经硬编码了每个子应用程序包的列表。这个列表可以作为清单文件移动到子应用程序，并通过公共URL公开。这意味着每个子应用程序将确切地告诉模板应用程序为了运行应用程序必须获取什么。模板应用程序只知道每个应用程序的清单文件的URL。

概念验证代码可以在Github上找到:https://github.com/pragmatists/microfron。它还没有准备好投入生产，但这个想法是为了验证我们的假设，并在一天的黑客马拉松中消除我们的疑虑。

希望你喜欢这篇文章!再见。

 

原文：https://blog.pragmatists.com/independent-micro-frontends-with-single-spa-library-a829012dc5be

本文：http://pub.intelligentx.net/node/566

讨论：请加入知识星球或者小红圈【首席架构师圈】

编写代码并将其作为组件发布是不够的

每个人都知道，根据定义，一个组件应该是可重用的，否则，你为什么一开始就想把代码变成一个组件，对吧？

好吧，虽然每个人都可能知道，但并不是每个人都知道制作可重用组件的最佳方法。有时最终的结果是一个次优的实现，虽然可以重复使用，但肯定会更好。

所以，让我们来看看我作为一名软件开发人员多年来学习的一些最佳实践。

模块化设计

在考虑如何设计新组件时，你应该想到的第一件事是“模块化”。

换句话说，你的组件应该被视为一块乐高积木，一块更大的结构，虽然它在原地工作得很好，但也可以（比喻）移动到其他有意义的地方，它也会同样工作。

用乐高积木构建应用程序正是像Bit这样的开源工具链所能实现的方法。通过将UI的原子单元提取到组件中，并独立地存储、测试和记录它们，您可以推动可组合的UI设计，使其能够更好地扩展和维护。

从上面的陈述来看，“有意义的地方”部分很重要，因为否则你会要求一个可以放在任何地方的神奇组件。

相反，关注现实世界中可以分享的场景，但要考虑以下内容：

• 不应该有任何不必要的外部依赖关系。例如，根据React，如果你正在构建一个React组件是可以的。但是，当你构建一个处理时间的组件时，依赖MomentJS（举个例子）就不是了。相反，尝试允许使用标准接口对库进行依赖注入，并使用所给的任何东西。
• 确保正确定义了所需的输入和预期的输出。如果您希望您的组件是模块化的，那么设计的一部分包括定义它期望的输入，以便其他人可以围绕它们进行编码，以及它返回的值。这样，其他人就可以确保它与他们现有的业务逻辑兼容。

诚然，我们生活在现实世界中，所以试着根据您的环境限制调整上述理想要求。

记住，它不一定是完美的，它需要尽可能好（两者之间有很大的区别）。

保持简单

通常的KISS原则也适用于此。保持简单愚蠢的想法是，你考虑的是谁将为他们使用你的组件和代码，而不是为你。

换句话说，试着让他们的生活更轻松，改善你的模块的开发人员体验，每个人都会想使用它。

同时，作为KISS原则的一部分，尽量保持您的组件较小。

我喜欢这样想的一种方式是将它与Linux的CLI工具进行比较。Linux终端有很多工具，它们都遵循相同的原则：它们只做一件事，而且做对了。您可以结合各自的功能创建极其复杂的脚本，但单独使用它们只能让您做这么多。

您的组件也应该如此。小的、可组合的组件比大的、无所不能的组件具有更大的灵活性和可重用性。

除此之外，您还可以获得额外的好处，即更小、更简单的组件更容易维护和调试。所以双赢！

文档、文档、文档

我知道这听起来很无聊，但如果你不让人们知道如何使用你的东西，你怎么能指望他们使用你的？

就这么简单，请注意，我不是在谈论自动生成的参考页面，您可以使用一些工具在2秒内构建该页面。这些文档可能对您很有用，但对于那些刚刚了解您的组件并想了解如何使用它、添加了什么样的配置选项以及它是否适合他们的特定用例的人来说就不方便了。这些开发人员需要更多。

他们需要例子，需要人工编写的解释（见鬼，你现在甚至可以使用ChatGPT，它可能会起作用），关于每个功能、每个方法和每个选项。

如果你想让你的组件受到重视，那么这种文档就必须存在。

此外，您还可以允许人们提出问题和提出问题。如果你在那里发布了代码，你可以使用GitHub。但这给新用户在使用你的代码时提供了额外的安全级别（毕竟，他们可以看到你关心你的用户），也让他们能够解决任何疑问，而无需联系你（如果其他人已经问过这个问题）。

你使用的工具取决于你，实际上，它可以是任何东西，从GitHub页面，到手动编写的网站，甚至像Bit.dev这样的东西。它们允许你在文档旁边的平台中发布自己的组件。您甚至可以在文档中添加活动部分，在那里人们可以尝试修改您的代码示例，以了解它们是如何工作的。这是一个很好的加分项，看起来很神奇。

看看我的一个旧组件的文档：

您有一个很好的UI、实时代码示例，甚至可以在页面上直接呈现一个可行的测试。除此之外，您的组件可以通过Bit平台发现。

我知道这听起来可能不好玩，但相信我，从长远来看，您会很高兴为您的组件构建了适当的文档。

彻底测试部件

这一个感觉它甚至不应该成为这个列表的一部分。

不是因为它不重要，而是因为完全相反的原因。我不应该告诉你这一点，你应该已经知道了：无论何时你想共享任何代码，测试都是强制性的。即使您在内部与自己公司内的其他团队共享组件，您唯一能做的负责任的事情就是确保代码按预期工作，这是通过测试来完成的。

单元测试是我的第一个建议，但如果你觉得很慷慨，其他测试，比如端到端甚至集成测试（尤其是如果你正在构建一个需要与专有系统集成的组件）都是不错的主意。

Bit也是一个很好的工具，可以帮助您简化测试实践，特别是如果您不太喜欢编写和运行自己的测试套件。使用Bit，您可以：

• 易于与流行的测试框架集成：Bit支持与一些最流行的前端测试框架（如Jest和Mocha）集成。这意味着您可以在平台内轻松配置和运行组件的测试。最重要的是，如果你正在使用另一个测试库，你可以按照这个详细的指南自己集成它。
• 自动化测试和验证：Bit包括一个自动化的构建和验证过程，确保您的组件没有错误并按预期运行。这个过程可以包括运行测试、linting和其他有助于确保组件质量的检查。不仅如此，无论何时准备发布，组件都会被隔离测试（我可以自动添加）。
• 协作测试：Bit允许开发人员测试和审查彼此的组件，从而实现开发人员之间的协作。这有助于识别问题，并确保组件在各种环境中正确工作。

记住：保持测试的更新，并找到一种自动执行测试的方法（比如使用Bit），这样无论何时发布新版本，都不会忘记运行测试。

使用语义版本控制

尤其是如果你正在建造别人会使用的东西。始终尝试将一些标准版本控制系统添加到组件中。

这样，他们就可以很容易地理解新版本对他们的影响。在semver的情况下，这是我最喜欢的一个BTW，如果你想更新，只需简单看一下新版本就可以理解。

基于semver的版本号由3个数字组成：（主版本）。（次要版本）。（修补程序版本）。

• 如果只是补丁版本发生了变化（即第三个数字），那么您肯定想要更新。这意味着作者发布了一个错误修复程序。
• 如果次要版本发生了更改（可能还有补丁版本），您可以选择忽略它或获取它。这通常意味着作者发布了一些向后兼容的新功能。因此，即使您没有使用它们，将组件更新到该版本也不会破坏系统！。
• 如果主要版本发生了更改，那么您最好在更新组件后测试代码。主要的版本更新意味着该组件上有中断性的更改。所以在进行更新之前，请记住这一点。

这些是您应该遵循的常规指南，它们让您的用户了解您的更新，这样他们就可以很容易地决定如何处理您的新版本，而无需向您提问或在文档中查找更多详细信息。

如果你想知道如何在你的组件库中实现这一点，像Bit这样的工具可以极大地简化这个过程，你甚至不必考虑那么多。

您获得的一些惊人好处包括：

• 自动版本控制：Bit为您的组件提供自动版本控制。每次您对组件进行更改时，Bit都会创建组件的新版本并跟踪它。您可以使用Bit标记命令指定实际版本，也可以让Bit自己决定。这意味着您可以很容易地跟踪组件随时间的变化。如果您想了解更多关于Bit如何处理组件版本控制的信息，请阅读本深度教程。
• 语义版本控制：Bit支持语义版本控制（这是我最喜欢的版本控制策略的原因！）。
• 版本管理：Bit提供了用于管理组件版本的工具。您可以查看零部件更改的历史记录，比较零部件的不同版本，并在必要时回滚到以前的版本。您可以通过Bit的开发人员查看此视频，展示如何使用组件比较功能。

通过使用Bit，您可以确保您的组件得到正确的版本控制，并且可以有效地跟踪更改并将其传达给用户。

也就是说，无论何时发布组件的新版本，都发布变更日志也是一个好主意。这会提供更多关于您发布内容的详细信息，以防您的用户需要该级别的详细信息。只要确保它们是有意义的，说“几个错误修复”是不够的，详细说明你改变了什么，如果有公共对话或公共问题是你修复的，请链接到它们，这样其他人就有必要的上下文来了解他们在系统中添加了什么。

约定高于配置

你可能不同意这种做法，但我喜欢这种做法。

它背后的想法是，默认情况下，您的组件应该在不需要任何配置的情况下工作。事实上，您可以提供一些“约定”，比如CSS类、子组件的命名，或者您的代码将学习并“神奇地”使用的其他约定。

当然，您应该始终让用户能够通过配置覆盖这些约定。这样，他们就可以确切地确定自己在做什么，并完全控制它。

不要，永远不要，只提供没有覆盖的第一部分。将功能隐藏在约定后面是一个糟糕的DX，您应该始终避免。它剥夺了使用它的人应该拥有的对组件的控制感，当这种情况发生时，他们不信任它。

所以，是的，提供一些“神奇的默认值”，但总是让开发人员根据需要覆盖它们。

考虑可访问性

组件在“理想”条件下工作并不意味着您的组件已经准备好了。是的，这是一个很好的第一步，但那些与您的组件交互但看不到您的“理想”用户的用户呢？或者，如果他们根本看不见呢？

“我的组件可以访问吗？”

这应该是你在称之为“完成”之前问自己的一个问题。特别是因为如果在开发阶段完成，检查可访问性问题并添加所需的代码以使其可访问性并不是一项困难的工作。

如果你想知道你能做些什么，请查看这篇详细的帖子，了解你可以通过在组件上做一些额外的工作来影响用户体验的所有方式。

在现有组件中改造可访问性非常困难，所以在规划下一个组件时请记住这一点。

最后，由您来决定您的组件何时“完成”。您可以自由发布和共享任何类型的代码，但在这样做时，您应该从开发人员和用户的角度考虑将要使用它的人。

在这两种情况下，您都有几个考虑因素，可以改善或破坏他们的体验，并确保或否定组件的成功和采用。

我是否错过了您在设计自己的组件时需要牢记的“最佳实践”？在评论中分享，让我们一起讨论！

使用可重复使用的组件构建应用程序，就像乐高一样

Bit的开源工具帮助250000多名开发人员使用组件构建应用程序。

将任何UI、功能或页面变成可重用的组件，并在应用程序中共享。协作更容易，构建速度更快。

• → Learn more

将应用程序拆分为组件，使应用程序开发更容易，并享受所需工作流的最佳体验：

best experience for the workflows you want:

• → Micro-Frontends
• → Design System
• → Code-Sharing and reuse
• → Monorepo

Redux 的创建者 Dan Abramov 说他不知道什么是领域驱动设计。 尽管如此，令人印象深刻的是 Redux 与 DDD 的相似之处。 在本文中，我解释了 DDD 是什么，一些关键概念，以及 Redux 如何实现其思想。 理解两者，我们可以提供更好的实现； 来自不同世界的两种方法相互碰撞并利用相同的设计原则。

领域驱动设计

领域驱动设计是一种软件建模技术，旨在创建强大的微服务架构以及集成多个现有解决方案。

Eric Evans 最初于 2003 年在《领域驱动设计：解决软件核心中的复杂性》一书中提出它。目前，DDD 有更多的书籍、更多的示例，并且已被证明可以有效地扩展和保持大型系统中的高级性能。如果您听说过 Event-Sourcing 或 CQRS，那么您已经与 DDD 擦肩而过。

我们可以将 DDD 分为两个领域：战略和战术。该策略引入了泛在语言和限界上下文。它在开发人员和业务之间创建了一种通用语言，但这种语言超越了会议：所有文档、故事甚至代码都共享该语言。每个声明的变量、函数、类或包名都与通用语言匹配。

策略更多的是关于如何实施系统。主要目标是在许多位置实现跨多个微服务的系统扩展。使用的抽象是查询、命令、域事件和聚合。应用程序将查询和命令指向聚合，聚合执行所有计算，域事件在整个系统中保持最终一致性。

战术的相关概念是：

• 查询：您可以对系统提出的任何问题。它不会更改其状态或任何数据。这是你要求的东西，它会以信息回应。没有副作用。查询示例：列出可用的帖子。

• 命令：是对突变的请求。 他们可能会工作，也可能会失败。 系统执行它们并返回结果。 某些变体，例如 CQS，不允许命令返回值。 命令示例：添加新帖子。

• 领域事件：是关键； 它们代表原因的结果； 它们是事实，是已经发生的事情。 事件不会失败，也无法取消。 应用程序中的任何组件都可以监听任何事件； 当它们中的任何一个接收到事件时，它们会更新自身并因此生成新事件。 领域事件使最终的一致性成为可能。 领域事件的示例是：添加了一个新帖子，或者是五点钟。

• Aggregates：是DDD的主要模式。 它代表小块模型（理想情况下只有一个实体和几个对象值）。 模型是合理隔离的。 聚合通过查询、命令和域事件相互通信。 他们消费领域事件以保持其状态一致，同时，他们为每个突变生成新的领域事件。 聚合示例：post。

不幸的是，许多人混淆了命令和领域事件。两者都是动词，都可能暗示状态的变化，但它们是不同的。命令是意图，领域事件是事实。这就是为什么命令可能会失败，但域事件不会。命令是我们想要发生的事情，而领域事件是已经发生的事情。

如果您想了解有关 DDD 的更多信息，我强烈建议您阅读 Vernon Vaughn «Domain-Driven Design Distilled» (2016) 的书。本书快速介绍了所有概念，并全面介绍了如何开始做 DDD。

Redux

Redux 与领域驱动设计有着惊人的关联。虽然它不共享相同的术语，但想法是存在的。 Redux 几乎是功能范式中 DDD 策略的实现。

让我们将之前的概念与 Redux 进行比较：

• 查询：它们是选择器。选择器从状态中获取一条信息。
• 命令：它们是动作。当我们调度一个动作时，我们提交一个新命令。 Redux 不提供结果，因为它实现了纯 CQS。
• 事件：它们也是动作。但是，¿当一个行动变成事实时？一旦减少。在减少一个动作之后，它就变成了一个事实，一个不会改变的东西。
• 聚合：聚合是计算所有更改的人；这是减速机(reducer)。

不幸的是，Redux 词汇表并不容易区分命令和领域事件。 DDD 使用不定式动词来表示命令；和事件的过去分词。尽管如此，通常会看到 redux 操作类型，例如命令“FETCH_POST”或事件“FETCH_POST_SUCCESSFUL”。

Redux 上的 DDD 模式

有两种模式使 DDD 流行起来：事件溯源和 CQRS。两者都源于提高可扩展性和性能的必要性，并且这两种技术通常都应用在 Redux 中。

第一个是事件溯源。

DDD 用于事件溯源的目标是增加数据库中写入的吞吐量。它不会将每个更改保存在数据库中，而是仅存储每个聚合发出的域事件，并在可能的情况下存储聚合的快照。推理很简单：您可以通过重放其事件来重建任何聚合的状态。

例如，您可以通过重播 PostAdded 事件来重建所有帖子。

你熟悉 Redux 中的这个概念吗？几乎可以肯定，是的。在 Redux 中，这称为 Time Traveling，您可能在开发人员工具中调试时经常使用它。

这种模式很棒；它不仅使我们能够更快地修复错误或加快服务器上的写入速度，而且有助于使应用程序更安全。数据丢失？没问题，重播事件，就可以重建状态。由于错误导致数据损坏？解决错误、重播事件并获得原始状态。你在帮助其他用户吗？只需重播他们的事件即可知道他们的状态。

第二个是CQRS。

CQRS 的 DDD 的目标是创建组合来自多个聚合的数据的模型。与其执行大量慢速查询，不如在一个模型上进行一次快速快速查询。如果事件溯源处理慢更新，它解决慢查询。这个想法是，一个独特的模型将消耗多个事件并一致地计算派生状态。然后，使用该新模型。例如，我们可以创建一个模型来统计帖子。它接收 PostAdded 事件并增加每个事件的计数。

Redux 中的等价物是多个 reducer 在不同的地方使用相同的操作进行更新。 尽管我们有带记忆的选择器，但有时，我们更喜欢保留计算得出的数据以提高性能。 例如，当我们有一个带有由键索引的实体的对象时，但我们有一个带有键的数组。 它加快了列表查询。

function reducePosts(state, action) {
  switch (action.type) {
    case ADD_POST:
      return { ...state, [action.post.id]: action.post };
    ...
  }
}function reducePostList(state, action) {
  switch (action.type) {
    case ADD_POST:
      return [...state, action.post.id];
    ...
  }
}function getPostList(state) {
  // instead of Object.keys(state.post)
  return state.postList; 
}

DDD 依赖解耦。

虽然它不是一种模式，但 DDD 很好地解耦了它们之间的聚合。 除了性能的可扩展性之外，它是 DDD 的主要优势之一。 聚合的概念以及它如何与其他人交互它提供了高度的可维护性和更好的实现。 正是这种精确的特性阻止了有害的大泥球的产生。

让我们看一个例子：我们有一家销售产品并使用营销活动来提供报价的公司。 商店中的现有商品最初标有相应的产品售价，但当活动开始时，它会用广告价格重新标记商品。

如果没有 DDD，我们有如下代码：

 

// Without DDD
class Campaign {
  ...
  startCampaign() {
    product.relabelUnits(advertisedPrice);
  }
}class Product {
  ...
  relabelUnits(price) {
    units.forEach(unit => unit.relabelPrice(price));
  }
}class Unit {
  ...
  relabelPrice(price) {
    labeledPrice = price;
  }
}

如果我们应用 DDD，我们可以中继域事件来更新其他聚合：

 

// With DDD
class Campaign {
  ...
  startCampaign() {
    emit(new CampaignStarted(..., productId, advertisedPrice));
  }
}class Unit {
  ...
  onCampaignStarted(event) {
    labeledPrice = event.advertisedPrice;
  }
}

你注意到不同了吗？ 现在产品已经消失了。 该产品不再依赖于该单元。 我们减少了应用程序的耦合，我们可以在不更改任何代码的情况下从系统中插入和拔出单元。

Redux 做同样的解耦。 每个组合的减速器就像一个聚合体。 当 reducer 收到一个动作时，它会独立地减少它。

function reduceUnit(state, action) {
  switch (action.type) {
    case START_CAMPAIGN:
      return { ...state, labeledPrice: action.advertisedPrice };
    ...
  }
}

结论

Redux 和 DDD 有许多相似之处，并且都具有许多优点。 尽管它们是从不同的抽象和不同的背景创建的，但它们都受益于相同的架构原则。

主要区别在于领域事件。 这个概念在 Redux 中并没有明确存在。 它有后果，可能会在进一步的文章中进行研究。

原文:https://levelup.gitconnected.com/redux-and-doman-driven-development-29f…

本文:https://jiagoushi.pro/node/2051