godbasin.github.io
godbasin.github.io copied to clipboard
godbasin
被删前端博客--喜欢请star
Offer my love star❤  This is my goddess, so amazing！
你好。我先描述下背景吧。 我还没正经开发过小程序，最近在做相关工作（封装一个小程序框架） 比如有这样一个业务场景，一个页面里有一个组件，页面监听了某个子组件的事件，在回调里setData了，而这个子组件因为监听了生命周期或者UI事件也setData了，并 trigger 了页面监听的这个事件。我想了解一下这个过程到底是怎样的？ 1. 是否会引发两次渲染？ 2. trigger 是同步还是异步的？理论上同步的可能性比较大 不太清楚 setData 到 webview 那边的通信时间和内部放置的队列情况，不过应该是宏队列，但是浏览器本身也对宏队列做了优化（比如连续在 setTimeout 0 操作 dom，不论是重绘还是重排，浏览器也会有自己的一套 isNeedRender 的算法优化）
# 谈谈Angular 本文跟随着Angular的变迁聊聊这个框架，分享一些基础的介绍，以及个人的理解。 也用过其他框架，像React和Vue。 但与Angular结识较深，或许也是缘分吧。  --- # 内容概要 - **数据绑定 (updated)** - **模块化组织 (new)** - **依赖注入** - **路由和lazyload (new)** - **Rxjs (new)** - **预编译AOT (new)** - **拥抱变化，迎接未来** > updated:...
与其说是构建大型应用，或许更多地是常用的应用构建吧。很多时候我们的项目在搭建的时候通常都不会定位为大型项目，但我们还是需要考虑到拓展性，或者说是在当项目开始变得较难维护的时候，要进行调整的一些方面。 # 项目设计 在项目开始之前，我们需要做一系列的规划，像项目的定位（to B/C）、大小，像框架和工具的选型，还有很重要的一点是，项目和团队规范。 ## 框架选择 通常来说，框架选择是准备项目的第一步。 说到框架，目前主流三大框架 Angular、React 和 Vue，先从个人理解来看看这三个框架。 ### Angular 这里的 Angular 是指 Angular 2.0+ 版本，v1.0 我们通常称之为 AngularJS，目前已经不更新了，建议大家还是使用 Angular。 Angular 相对 React 和 Vue，最初的设计是针对大型应用来进行的。要是你认识 JAVA 的话，像依赖注入这一套你会觉得很熟悉。当然到了...
托目前主流框架的福，我们能从事件驱动脱离，来到了数据驱动的世界，可以参考以前的[《前端思维转变--从事件驱动到数据驱动》](https://godbasin.github.io/2017/09/29/data-driven-or-event-driven/)。在常常与数据打交道后，我们对组件的封装、配置化的思想一步步地深入和拓展之后，对于数据和状态的管理，也慢慢地出现了一些思考。 # 应用数据抽离 在把数据与逻辑分离到极致的时候，你再看一个应用，会看到一具静态的逻辑躯壳，以及数据如灵魂般地注入到应用里，使其获得生命。 数据的抽离，其实与配置化的思想有想通的地方，即把可变部分分离，然后通过注入的方式，来实现具体的功能和展示。 ## 状态数据 在一个应用的设计里，我们可能会拥有多个模块，每个模块又各自维护着自己的某些状态，同时部分状态相互影响着，最终呈现出应用的整体状态。 这些状态，都可以通过数据的方式来表示，我们简单称之为状态数据。 怎么定义状态数据？最浅显的办法就是这些数据，可以直接影响模块的状态，如对话框的出现、隐藏，标签的激活、失活，长流程的当前步骤等，都可以作为状态数据。用在 Vue 里面，可能常见如 `v-show`、`v-if`、以及其他状态判断逻辑。 我们的应用，大多数都是呈现树状结构，一层层地往下分解，直到无法分割的某个简单功能。同时，我们的组件也会呈现出来这样树状的方式，状态是跟随着组件维护，某个功能状态属于组件自己，最外层的状态则属于整个应用，当然这个应用也是组件的一种表示方式。 因此，我们的状态数据，也呈现一种树状的方式，与我们的组件相对应。就像 CSS 与 DOM 节点。 ## 动态数据 我们还有很多的数据，如内容、个人信息等，都是需要我们从数据库拉取回来的。这种需要动态获取然后展示或是影响配置的一些数据，我们称之为动态数据。 动态数据不同于状态数据，并不会跟随着应用的生命周期而改变，也不会随着应用的关闭而消失。它们独立存在于外界，通过注入的方式进入应用，并影响具体的展示和功能逻辑。 和状态数据不一样，动态数据并不一定呈现为树状的形式。它可以是并行的，可以是联动关系，但是随着注入的地方不一样，最终在应用中形成的结构也会不一致。我们可以简单理解为每个动态数据都是平等的。 ## 将数据与应用抽离 要怎么理解将数据与应用抽离呢？形象点形容，就像是我们一个公司，所有的桌子椅子装修和电脑都是静态的，它们相当于一个个的组件，同时每个办公室也可以是一个大点的组件或是模块。 那么在我们这个公司里： - 状态数据：椅子的位置、消耗的电量、办公室的照明和空调状态等...
配置化思想，其实可以在很多的地方使用。很多时候，我们在设计接口、应用、数据等情况下，配置化的方式可以允许我们获得更高的自由度。这里我们简单讲讲组件的配置化吧。 # 配置化思想 ## 可配置的数据 数据的配置，或许大家会比较熟悉。像一些静态数据呀，或者说我们很多的管理端都是用来进行数据配置的。 ### 应用中的可配置数据 最常见的数据配置，大概是应用里面的配置，文案呀、说明等，为此我们有了运营这样的职位。常见的方式，则是搭起一整套的运营管理平台，一些简单的文字或是数据，则可以通过平台进行配置。 ### 代码中的可配置数据 有些时候，我们也会在代码里面放置一些可配置的数据。例如说，这个需求需要查询一周的数据，常见的做法是将天数配置为7天： ``` javascript const QUERY_DAY_NUM = 7; ``` 这样，当需要在紧急情况支持其他天数（五一、国庆、过年能假期）的时候，我们就可以只需要改动这里就好啦。 ### 文件里的可配置数据 有些情况下，一些影响逻辑的配置数据，要是直接写到代码里，在调整的时候通常需要重新打包部署，这样情况下开销大、效率低。 所以在一些时候，我们会把这样的可配置数据，单独写到某个文件里维护。当需要调整的时候，只需要下发一个配置文件就好啦。 ## 可配置的接口 关于接口的配置化，目前来说见过的不是特别多。毕竟目前来说，我们的很多数据和接口并不是简单的增删查改这样的功能，很多时候还需要在接口返回前后，做一系列的逻辑处理。 简单地说，很多的业务接口场景复用性不高，前后端除去协议、基础规范的定义之后，很少再能进行更深层次的抽象，导致接口配置化的改造成本较大。 配置化的实现有两点很重要的东西：**规范**和**解决方案**。如果说目前较好的从前端到后台的规范，可能 [GrapgQL](https://graphql.cn/)...
曾经我在面试的时候，面试官问我，觉得做过的有意思的东西是什么，答组件相关的。结果被面试官鄙视了，sign~不过呢，再小的设计，当你把满腔热情和各种想法放进里面，它似乎有了灵魂。或许是我当时面试的表达，没有传达到真正的想法，那么在这里，我希望能很好地表达。 # 组件的划分 前面我们简单说明了下组件的封装和划分，参考[《页面区块化与应用组件化》](https://godbasin.github.io/2018/05/26/app-component-isolation/)。 ## 通过视觉和交互划分 通常来说，组件的划分，与视觉、交互等密切相关，我们可通过功能、独立性来判断是否适合作为一个组件。 这次我们拿知乎的内容卡片来说吧，上图：  可以看到，这里我们每个卡片，内容都稍微有些不一样。但毫无疑问，它们拥有相同的功能，可通过一个组件来控制内容的展示。 那么我们大概可以这样来表示这个组件（为了方便，该文章大部分代码基于 Vue 来表示吧）： ``` html ``` 其中，innerData 传入卡片内容，包括标题、文字、图片、附加信息（点赞数、评论数、日期等）。 同时，我们可以通过 cardType 来告诉组件，这是个视频类型、图片类型、还是纯文字类型的内容，来让组件控制内容和样式展示。 ## 通过代码复用划分 我们在写代码的时候，观察到一些代码，他们在结构和功能上其实是可复用的，这个时候我们也可以通过封装的办法，把它们封装一起，以减少重复的代码。 同样的，我们拿右侧的一个快捷导航模块来看：  一般来说，从功能划分的话，我们会把外面那层封装成一整个组件： ``` html ......