中国兰州网pc主站,学校网站模板免费,杭州做网站公司排名,新乡网站seo优化远离JavaScript疲劳和框架大战#xff0c;了解真正重要的东西 几周前#xff0c;我的同事们对我们的前端架构、代码结构和面临的挑战很感兴趣。在做了几次关于如何构建可扩展且健壮的前端的演讲后#xff0c;我觉得把它们都总结一下并与社区分享我们的策略是一个不错的主意。… 远离JavaScript疲劳和框架大战了解真正重要的东西 几周前我的同事们对我们的前端架构、代码结构和面临的挑战很感兴趣。在做了几次关于如何构建可扩展且健壮的前端的演讲后我觉得把它们都总结一下并与社区分享我们的策略是一个不错的主意。废话不多说以下是第一部分。 我们先来看看一个典型的网页吧 一个典型的网页 普通用户看到的是垂直和水平的条形图一个主要内容区域其中包含一个艺术品列表和一个图表但对于前端开发人员来说只有组件VBarComponent、HBarComponent、OverviewComponent等等。 从前端开发者的角度来看网页 这些组件以树形结构排列通常以根节点的形式出现通常称为主组件。每个现代前端应用程序至少必须有一个组件即主组件。 这棵树是基于组件的架构的基础。从现在开始我们将看到它如何驱动前端世界的各个方面。 分析树形 人们很快就会注意到在同一分支上放置的组件会协同工作为用户提供一个独立且连贯的功能。然而由于不同的功能所提供的商业价值不同其在界面上的展示方式也不同因此同一分支上的组件形状也会有所不同。 这种多样性使得代码结构成为一个挑战因为与后端不同前端没有标准化的N层架构来帮助组织应用程序的文件。 n层架构的例子 这里的解决办法是基于功能而不是层类型来驱动。每个功能都将其组件放入一个子文件夹中这样可以帮助开发人员了解在何处添加新组件同时保持对分支任何可能形状的灵活性。 span stylecolor:rgba(0, 0, 0, 0.8)span stylebackground-color:#ffffffspan stylebackground-color:#f2f2f2span stylecolor:#242424AppRepo│ ├──/Overview * Overview feature folderstrong|/strong ├──/Components * Components folderstrong|/strong ├──/ListComponent * List component│ └──/ChartComponent * Chart component│├──/Details * Details feature folder├──/Components * Components folder├──SomeComponent * Some component└──SomeOtherComponent * SomeOther component/span/span/span/span 虽然这是个直观的解决方案。 它很快遇到了一些限制。该如何处理技术组件应该在哪里添加共享组件 我们从“ feature ”这个词过渡到一个更通用、与功能领域耦合更少的词我选择了“ brick ”。为什么呢可以说我的应用程序是由砖块组成的。每个砖块都有特定的作用但它们共同构成了应用程序的构建块。 在这个例子中我的应用程序是由不同的砖块组成的 核心包含应用程序启动所需的一切内容。它还为其他砖块监控、日志记录等提供了技术实用工具。共享共享工具、小部件等所有在所有砖块中使用的元素如提示框、错误对话框、排序函数等等。特点1, 2 3与用户特定附加价值相关的功能域特征。功能A、B与C也包含砖块功能但它们的附加价值旨在为功能服务而不是直接为应用程序服务可以在一些功能砖块之间共享例如功能A的情况。 在本文中我们了解到如何将网页转换为组件树。这种树形结构解释了我们的代码结构为何由功能驱动以及我们如何将应用程序分割为具有独特角色的不同砖块。 我将在下一篇文章 《如何将功能架构分为三层》中继续介绍现代前端架构深入探讨“砖块”的构成并重点介绍更多与树形结构相关的问题及其处理方法。 欢迎关注公众号清晰编程获取更多精彩内容
