Kuitos
需要完善或补充的文档，可以在 issue 下回复并描述自己的需求 - [ ] 升级指南 （可以先看[这里](https://zhuanlan.zhihu.com/p/131022025)） - [ ] API 文档目录调整 - [ ] 官方的微应用通信指导文档 - [ ] Contribution Guide
such a code with property decorator usage: ```js class Controller { name = 'xx'; @inject(Store) store: any = null; } ``` after a tsc compiling: ```js var Controller = /**...
> 本文主要介绍总结了一些基于 qiankun 的微前端应用场景与实践 ## 基础场景 ### 与路由绑定的方式渲染微应用 通常情况下，我们接触的最多的微前端的实践，是以 URL/路由 为维度来划分我们的微应用，以 OneX 平台（蚂蚁金融云基于微前端架构打造的统一接入平台）为例：  接入这类平台的微应用，通常只需要提供自己的 entry html 地址，并为其分配一个路由规则即可。 这背后的实现则是基于 qiankun 的 registerMicroApps API，如： ```js import { registerMicroApps } from 'qiankun';...
## 问题 这两天在排查一个 [qiankun 的 bug](https://github.com/umijs/qiankun/issues/1121) 时，发现了一个我无法解释的 js 问题，这可要了我的命。 略去一切细枝末节，我们直接先来看问题。 假如有这么一段代码： ```javascript (() => { 'use strict'; const boundFn = Function.prototype.bind.call(OfflineAudioContext, window); console.log(boundFn.hasOwnProperty('prototype')); boundFn.prototype = OfflineAudioContext.prototype; console.log(boundFn.hasOwnProperty('prototype')); })(); ``` 假设我们已知，函数通过...
一道js面试题引发的思考
## 一道js面试题引发的思考 原文写于 2015-02-11 前阵子帮部门面试一前端，看了下面试题(年轻的时候写后端java所以没做过前端试题)，其中有一道题是这样的 ``` js 比较下面两段代码，试述两段代码的不同之处 // A-------------------------- var scope = "global scope"; function checkscope(){ var scope = "local scope"; function f(){ return scope; } return f(); }...
> [原文地址](https://zhuanlan.zhihu.com/p/131022025) > 距 qiankun 开源已过去了 11 个月，距上次官方 [发声](https://zhuanlan.zhihu.com/p/78362028) 已过去 8 个月。 **Announcing [email protected]** 2019 年 6 月，微前端框架 [qiankun](https://github.com/umijs/qiankun) 正式发布了 1.0 版本，在这一年不到的时间内，我们收获了 4k+ star，收获了来自 single-spa 官方团队的问候，支撑了阿里 200+ 线上应用，也成为社区很多团队选用的微前端解决方案。 在今天，qiankun 将正式发布...
### 前端工程化知识要点回顾&思考 本文是近期对一系列 前端工程化&架构 文章的观点的整理及总结，特此鸣谢: [2015前端组件化框架之路](https://github.com/xufei/blog/issues/19) [张云龙系列blog](https://github.com/fouber/blog/issues) > #### 编程技术及生态发展的三个阶段 > - 最初的时候人们忙着补全各种API，代表着他们拥有的东西还很匮乏，需要在语言跟基础设施上继续完善 > - 然后就开始各种模式，标志他们做的东西逐渐变大变复杂，需要更好的组织了 > - 然后就是各类分层MVC，MVP，MVVM之类，可视化开发，自动化测试，团队协同系统等等，说明重视生产效率了，也就是所谓工程化 #### 前端工程是软件工程的一个子类别 > 软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。 #### 前端是一种GUI软件 > 从本质上讲，所有Web应用都是一种运行在网页浏览器中的软件，这些软件的图形用户界面（Graphical User Interface，简称GUI）即为前端。 前端又不同于传统的客户端软件／后端，因为前端应用具备“免安装”、“增量安装”等特性。也“得益”于这些特性，前端应用会遭遇客户端应用不可能碰到的资源管理问题，这也是前端最容易引起工程问题的点。...
# 基于 MobX 构建视图框架无关的数据层-与 Vue 的结合(1) *[mobx-vue](https://github.com/mobxjs/mobx-vue) 目前已进入 mobxjs 官方组织，欢迎试用求 star！* 几周前我写了一篇文章描述了 mobx 与 angularjs 结合使用的方式及目的 ([老树发新芽—使用 mobx 加速你的 AngularJS 应用](https://github.com/kuitos/kuitos.github.io/issues/38))，这次介绍一下如何将 MobX 跟 Vue 结合起来。 ## 安装 ```bash npm i...
# [译注] MVVM 模式 > 原文：[The MVVM Pattern](https://msdn.microsoft.com/en-us/library/hh848246.aspx) MVVM 模式跟 Silverlight 这类 XAML 应用平台是天生合拍的。这是因为 MVVM 模式利用了Silverlight 的一些特殊能力，比如说 数据绑定，命令，行为等。MVVM 跟其他一些将表现及UI布局 与展示层逻辑的职责进行分离的模式很相似；如果你对 MVC 模式熟悉的话，你会发现它与 MVVM 之间存在很多相似的概念。 > 译者注：XAML(Extensible Application Markup Language)是微软为构建GUI程序而创建的一种标记语言，你可以将它等同于 web...
## 基于ui-router的非侵入式angular按需加载方案 用过angular1.x(后面提到的angular均指代的angular1.x框架)的同学应该都知道，angular自身的模块系统是不具备按需加载的能力的，笔者也赞同angular的模块系统是真正称得上设计上的败笔的观点的。2015年被黑的最惨的前端主流框架莫过于angular了，但实际上angular真正设计上的硬伤只有两个：鸡肋的模块系统以及相比其他MVVM框架略显丑陋的脏值检测机制。关于其他各种所谓致命缺陷的立论其实都是站不住脚的，这些观点的提出我可以归结于使用者对angular的不熟悉，不服的同学欢迎来辩😂 #### angular模块系统的问题 扯远了，说回正题。由于angular自身模块系统的限制，module不支持运行时添加依赖，也就是我们在定义入口模块时必须声明所有依赖项。当我们面临多项目整合的场景时(往往这类场景有按需加载的需求)，这个就很恶心了，我们总不能在入口页写好所有可能会嵌入系统的项目的依赖项吧，而且要确保入口模块能找到所有依赖项对应的模块，相应的js还必须在入口处就加载好。。 更多关于angular模块化的问题，具体可以参见民工叔的这篇文章[Angular的模块机制](https://github.com/xufei/blog/issues/17) #### 市面上angular实现按需加载的通常方案 目前市面上流行的解决方案大概是这样的：基于requirejs等模块加载器，我们子模块的代码包裹在requirejs的模块定义语法下(define)，然后在具体需要的时候在require回调里invoke我们子模块的controller或service等，可以参见这个seed项目[angular-requirejs-seed](https://github.com/tnajdek/angular-requirejs-seed) 但是这种方式也有一些明显的问题： 1. requirejs配合angular实现的那一套按需加载的方案实在是太挫了，真的是有碍观瞻啊！😂它是一套完全侵入式的方式，我个人是无法接受的。而且我认为在中小型规模的系统中，基于angular框架，我们自己需要写的代码量其实不会太大，即使在首页全部引入，在经过简单的合并压缩再配合gzip，文件体积完全在可控范围内，按需加载在这样的场景下价值有限。这也是我一直拒绝在angular体系中引入requirejs的原因。 2. 如果我们采用angular的纯module的方式开发，那么我们自然会有包含各种controller、service、directive的不同模块，类似`angular.module('directives',[]).directive('grid',function(){})` 的写法，而这些子模块必须在入口模块定义时声明其为依赖项，像这样`angular.module('app',['directives'])`即便你采用requirejs做按需加载。 3. 我们不采用子单元纯module的方式开发，而是将所有的子单元都挂载在入口模块上，子模块写法类似`angular.module('app').directive('grid',function(){})`，这种做法副作用会相对少点，但是如果碰到多个项目在各个系统之间作嵌入时，很难做到不用修改代码即可完成嵌入，除非你能确保所有的系统入口模块命名一样。 #### 基于ui-router的解决方案 刚好最近公司在做整个系统的去iframe化(没错之前各个产品嵌入主系统的做法是通过iframe。。不要笑！！😂)，因为各个产品之间的切换是通过tab完成的，tab的切换又是通过ui-router控制去定位到各个产品的入口html，所以基于ui-router，我的思路是这样的： 1. 首先要理清ui-router的工作方式：tab切换时触发ui-router的路由，ui-router会通过配置好的路由规则找寻相应的模板配置(这里假设我们路由配置的都是templateUrl的方式)，得到url后会去发起ajax请求拿模板，拿到模板再会填充到ui-view内容区，最后做compile、link处理(省去其他细节)，这时候ui-view区域显示的就是编译好的模板内容了。 2. 基于此，我们可以在模板做编译之前，分析并拿到模板中的script标签，然后通过简单的脚步加载器将模板中定义的js加载到浏览器内存里，在所有的js资源加载完毕之后再去调用编译流程，一切OK！这里要顺带解释一个事情，因为ui-router里采用element.html(tpl)的方式将模板填充到ui-view中的，所以模板中的script标签并不会被浏览器按正常方式解析，而link、style标签不会受到影响(出于安全考虑？具体原因没查到知道的同学请不吝指教)。 但是我们要做的当然不能是直接去找到ui-router这一块的代码然后修改源码，这种做法是有违开闭原则的也是我一直批判的方式，不到万不得已绝不要去修改第三方插件的源码！ui-router处理路由模板的主逻辑在uiView指令里，然后angular里面又提供了强大的decorator机制。开码！ ``` js angular .module('ui.router.requirePolyfill',...