cangdu
# 前言 最近研究各大网站的font-family字体设置，发现每个网站的默认值都不相同，甚至一些大网站也犯了很明显的错误，说明字体还是有很大学问的，值的我们好好研究。 不同的操作系统、不同浏览器下内嵌的默认字体是不同的，错误的字体设置会导致页面在不同环境渲染的混乱，选择一套合适的字体是打造优秀网页的第一步。通过本文，我们会介绍字体的知识点，并探索在PC和Mobile两端该如何正确的设置字体。 # 字体基础知识 ### 字体的分类 * serif(衬线) * sans-serif(无衬线) * monospace(等宽) * fantasy(梦幻) * cuisive(草体) 这些不是指某一个字体，而是一个字体族，是一系列字体的集合，我们接触最多的就是衬线字体和无衬线字体。 #### serif(衬线字体) & sans-serif(无衬线字体) Serif的意思是，在字的笔划开始及结束的地方有额外的装饰，而且笔画的粗细会有所不同。衬线字体的风格都比较突出，常见的衬线字体有`Times New Roman`、`宋体`。 Sans Serif字体没有这些额外的装饰，笔划粗细大致差不多，字形端庄，横平竖直，常见的无衬线字体有`Tahoma`、`Verdana`、`Arial`、`Helvetica`、`苹方`、`微软雅黑`等等。  ####...
## 做React需要会什么？ react的功能其实很单一，主要负责渲染的功能，现有的框架，比如angular是一个大而全的框架，用了angular几乎就不需要用其他工具辅助配合，但是react不一样，他只负责ui渲染，想要做好一个项目，往往需要其他库和工具的配合，比如用redux来管理数据，react-router管理路由，react已经全面拥抱es6，所以es6也得掌握，webpack就算是不会配置也要会用，要想提高性能，需要按需加载，immutable.js也得用上，还有单元测试。。。。 ##React 是什么 用脚本进行DOM操作的代价很昂贵。有个贴切的比喻，把DOM和JavaScript各自想象为一个岛屿，它们之间用收费桥梁连接，js每次访问DOM，都要途径这座桥，并交纳“过桥费”,访问DOM的次数越多，费用也就越高。 因此，推荐的做法是尽量减少过桥的次数，努力待在ECMAScript岛上。因为这个原因react的虚拟dom就显得难能可贵了，它创造了虚拟dom并且将它们储存起来，每当状态发生变化的时候就会创造新的虚拟节点和以前的进行对比，让变化的部分进行渲染。整个过程没有对dom进行获取和操作，只有一个渲染的过程，所以react说是一个ui框架。 ##React的组件化 react的一个组件很明显的由dom视图和state数据组成，两个部分泾渭分明。state是数据中心，它的状态决定着视图的状态。这时候发现似乎和我们一直推崇的MVC开发模式有点区别，没了Controller控制器，那用户交互怎么处理，数据变化谁来管理？然而这并不是react所要关心的事情，它只负责ui的渲染。与其他框架监听数据动态改变dom不同，react采用setState来控制视图的更新。setState会自动调用render函数，触发视图的重新渲染，如果仅仅只是state数据的变化而没有调用setState，并不会触发更新。 组件就是拥有独立功能的视图模块，许多小的组件组成一个大的组件，整个页面就是由一个个组件组合而成。它的好处是利于重复利用和维护。 ##React的 Diff算法 react的diff算法用在什么地方呢？当组件更新的时候，react会创建一个新的虚拟dom树并且会和之前储存的dom树进行比较，这个比较多过程就用到了diff算法，所以组件初始化的时候是用不到的。react提出了一种假设，相同的节点具有类似的结构，而不同的节点具有不同的结构。在这种假设之上进行逐层的比较，如果发现对应的节点是不同的，那就直接删除旧的节点以及它所包含的所有子节点然后替换成新的节点。如果是相同的节点，则只进行属性的更改。 对于列表的diff算法稍有不同，因为列表通常具有相同的结构，在对列表节点进行删除，插入，排序的时候，单个节点的整体操作远比一个个对比一个个替换要好得多，所以在创建列表的时候需要设置key值，这样react才能分清谁是谁。当然不写key值也可以，但这样通常会报出警告，通知我们加上key值以提高react的性能。  ##React组件是怎么来的 组件的创造方法为React.createClass() ——创造一个类，react系统内部设计了一套类系统，利用它来创造react组件。但这并不是必须的，我们还可以用es6的class类来创造组件,这也是Facebook官方推荐的写法。  这两种写法实现的功能一样但是原理却是不同，es6的class类可以看作是构造函数的一个语法糖，可以把它当成构造函数来看，extends实现了类之间的继承 —— 定义一个类Main 继承React.Component所有的属性和方法，组件的生命周期函数就是从这来的。constructor是构造器，在实例化对象时调用，super调用了父类的constructor创造了父类的实例对象this，然后用子类的构造函数进行修改。这和es5的原型继承是不同的，原型继承是先创造一个实例化对象this，然后再继承父级的原型方法。了解了这些之后我们在看组件的时候就清楚很多。 当我们使用组件< Main />时，其实是对Main类的实例化——new Main，只不过react对这个过程进行了封装，让它看起来更像是一个标签。 有三点值得注意：1、定义类名字的首字母必须大写 2、因为class变成了关键字，类选择器需要用className来代替。 3、类和模块内部默认使用严格模式，所以不需要用use...
README =========================== 该文件用来测试和展示书写README的各种markdown语法。GitHub的markdown语法在标准的markdown语法基础上做了扩充，称之为`GitHub Flavored Markdown`。简称`GFM`，GFM在GitHub上有广泛应用，除了README文件外，issues和wiki均支持markdown语法。 **** ### Author:果冻虾仁 ### E-mail:[email protected] =========================== ##目录 * [横线](#横线) * [标题](#标题) * [文本](#文本) * 普通文本 * 单行文本 * 多行文本 * 文字高亮 * 换行 * 斜体...
sandBox在micro-app元素创建之后、代码执行之前获取 ```js microApp.getSandBox(appName).then((sandBox) => { sandBox.exec('code') // 在子应用中执行js代码 sandBox.getWindow() // 返回子应用的window sandBox.getDocument() // 返回子应用的document sandBox.inject(data: Object) // 注入子应用全局变量 sandBox.deleteInjectData(key) // 删除指定注入子应用的全局变量 sandBox.clearInjectData() // 删除所有注入子应用全局变量 }) ``` **注意：** 1、预加载也会创建沙箱，但不会触发then，只有在代码执行前才会触发 2、注入的变量在应用卸载时不会被自动清除
## 前言 MicroApp是一款基于类WebComponent进行渲染的微前端框架，不同于目前流行的开源框架，它从组件化的思维实现微前端，旨在降低上手难度、提升工作效率。它是目前市面上接入微前端成本最低的框架，并且提供了JS沙箱、样式隔离、元素隔离、预加载、资源地址补全、插件系统、数据通信等一系列完善的功能。MicroApp与技术栈无关，也不和业务绑定，可以用于任何前端框架和业务。 本篇文章中我们会从业务背景、实现思路介绍MicroApp，也会详细介绍它的使用方式和技术原理。 ## 业务背景 随着这些年互联网的飞速发展，很多企业的web应用在持续迭代中功能越来越复杂，参与的人员、团队不断增多，导致项目出现难以维护的问题，这种情况PC端尤其常见，许多研发团队也在找寻一种高效管理复杂应用的方案，于是微前端被提及的越来越频繁。 微前端并不是一项新的技术，而是一种架构理念，它将单一的web应用拆解成多个可以独立开发、独立运行、独立部署的小型应用，并将它们整合为一个应用。 在实际业务中，我们也遇到同样的问题，并且在不同的业务场景下尝试了各种解决方案，如iframe、npm包、微前端框架，并对各种方案的优劣进行了对比。 **iframe**：在所有微前端方案中，iframe是最稳定的、上手难度最低的，但它有一些无法解决的问题，例如性能低、通信复杂、双滚动条、弹窗无法全局覆盖，它的成长性不高，只适合简单的页面渲染。 **npm包**：将子应用封装成npm包，通过组件的方式引入，在性能和兼容性上是最优的方案，但却有一个致命的问题就是版本更新，每次版本发布需要通知接入方同步更新，管理非常困难。 **微前端框架**：流行的微前端框架有single-spa和qiankun，它们将维护成本和功能上达到一种平衡，是目前实现微前端备受推崇的方案。 由于iframe和npm包存在问题理论上无法解决，在最初我们采用qiankun作为解决方案，qiankun是在single-spa基础上进行了封装，提供了js沙箱、样式隔离、预加载等功能，并且与技术栈无关，可以兼容不同的框架。 #### 业务诉求 qiankun虽然优秀，但依然无法满足我们的预期。第一个问题是在我们实际使用场景中，每个接入微前端的项目运行已久，且每个项目由不同的人员和团队负责，如何降低对源代码的侵入性，减少代码修改和沟通成本，这是我们非常关心的点，所以我们需要一种比qiankun接入成本更小的方案。第二个问题是在多方应用接入的情况下，沙箱并不能完美规避所有问题，但qiankun处理此类不可预料的问题的能力并不是非常高效。在不停的摸索中，我们找到一种极致简洁的实现思路，它像使用组件一样简单，只修改一点点代码就可以接入微前端，并且还提供插件系统，赋予开发者灵活处理问题的能力。  ## 实现思路 微前端分为主应用和子应用，主应用也称为基座应用，是其它应用的容器载体，子应用则是被嵌入方。我们分别从主应用和子应用的角度出发，探寻一种更简洁和有效的接入微前端的方式。 #### 关于qinkun和single-spa的思考 在single-spa和qiankun中都是通过监听url change事件，在路由变化时匹配到渲染的子应用并进行渲染。这种基于路由监听渲染是single-spa最早实现的，作为出现最早、最有影响力的微前端框架，single-spa被很多框架和公司借鉴，也导致目前实现的微前端的方式大多是基于路由监听。 同时single-spa要求子应用修改渲染逻辑并暴露出三个方法：bootstrap、mount、unmount，分别对应初始化、渲染和卸载，这也导致子应用需要对入口文件进行修改。这个特点也被qiankun继承下来，并且需要对webpack配置进行一些修改。  基于路由监听的实现方式和对子应用入口文件以及webpack配置的修改是必须的吗？ 其实并不是，微前端的核心在于资源加载与渲染，iframe的渲染方式就是一个典型，只要能够实现一种元素隔离的功能并且路由符合要求，子应用理论上不需要修改代码就可以嵌入另外一个页面渲染，我们试图从这个角度中找到不一样的实现思路。 #### 微前端的组件化...
### Discussed in https://github.com/micro-zoe/micro-app/discussions/1299 Originally posted by **front-refined** July 15, 2024 0.x 时只针对应用卸载时处理 release effect，当 keep-alive app hidden 时，推入后台但是仍然会运行脚本（一些通信监听代码），以往我们在 0.x 时就依赖了这一特性。但 1.x 在 keep-alive hidden 时处理了 release effect 导致后台不能运行 是否可以有个开关类似...