Origin of Ray

之前的博客我们讲了我们创建VueRouter实例并通过Vue.use应用之后，VueRouter内部如何生成一整套自己的数据结构来存储路由配置的，这次博客我们继续解读Vue Router的源码，大致内容是Vue Router的路由守卫的执行逻辑。

这几天遇到个问题，就是在vue-router嵌套子路由的时候，如果深层的router-view组件没有声明key，且路由配置中的component是函数式的组件，就会导致在router.push的时候无法更新。

对于函数式组件和函数式编程，需要了记得可以我之前的相关博客;

本文主要是分析vue-router的源码，vue-router的源码主要是两部分，第一部分是做路由匹配，第二部分是做路由跳转的，本文先主要关注第一部分

函数式编程和函数式组件是现在开发的一个趋势，过去一直在用，但是没有从概念上理解，本文就把二者放在一起总结一下并进行一定的对比。

函数式编程是一种编程范式，而函数式组件是这种范式下的一种产物。

我们接着上一篇博客继续总结和学习JavaScript的常用设计模式，这一次我们总结两个在JavaScript角度来讲比较像的模式，也就是代理模式，策略模式。

这两个模式在非函数式编程编程的语言中，如Java中区别是比较明显的，但是用JavaScript来看则是比较相似的。

上一篇博客我们介绍了Qiankun的沙盒机制，也就是不同的子应用之间是如何做环境隔离的，这篇博客我们就基于上一篇博客讲一下如何利用沙盒去进行子应用的加载和切换。

qiankun是基于single-spa实现的，所有内部用到了部分single-spa的接口，简单说一下single-spa和qiankun的区别，single-spa只做了子应用的注册，切换，路由监听等，还没有达到一个商用的水准，而qiankun在此之上加了js和css的沙箱隔离，按照官方文档，qiankun是达到了商用的要求。

为什么需要微前端

微前端其实诞生两个大的背景下，在提倡拥抱变化的前端社区可以看到新的框架、技术、概念层出不穷，并且随着WEB标准的演进，前端应用已经具备更好的性能、更快的开发效率。但随着而来的是应用的复杂程度更高、涉及的团队规模更广、更高的性能要求，应用复杂度已经成为阻塞业务发展的重要瓶颈。如何让现有系统拥抱最新技术提高生产力、并且解耦单体应用，是现在前端工程不得不面临的挑战。

随着对JS的知识的了解和实际的开发需要，内心对于重读设计模式的感触越来越深，所以就重新拿起了《JavaScrip设计模式与开发实践》一书，并结合《设计模式之美》的部分内容，先做个总结，并先讲一下单例模式，剩下的后续慢慢讲。

首先提出几个问题，也是我这次的几个比较总结性的收获：

• JavaScript是面向对象还是面向过程
• 函数是一等公民这一点是面向对象还是面向过程

然后抛出我这次对设计模式的一个最大的收获，就是所有的设计模式，其实都是识别出代码中不变的部分和易变的部分，分别封装起来，然后组合二者,而要准确地识别出这一点，不仅需要代码能力的深厚，更是要真正地去理解业务。

比如策略模式，一个个策略就是易变的部分，而对策略的调用则是不变的部分。代理模式中，被代理的操作就是不变的，而代理本身就是易变的。

其实，设计模式的出现某种程度上就是为了弥补语言的不足，比如原型模式算是一种设计模式，但是JavaScript本身就通过原型链支持了这种模式。

最近在阅读《Web高效编程与实践优化》的计算机基础一节，看到他讲了JS中Set和Map的区别，以及Object的实现，算是解决了往常的一点疑惑吧，这里简单总结下：

基础知识

首先我们回顾下操作系统的知识，即：

• 为什么会出现进程和线程的概念，他们的出现是为了解决什么问题
• 进程和线程的概念与定义
• 线程的调度
• 线程的同步与互斥
• 死锁问题

Redux是一个web前端的状态管理库，通用与所有前端页面，并不依赖于什么框架，是一个纯js的项目，其原理和源码比较简单，我们先要理解redux源码，再去看redux-toolkit源码，才能明白redux-toolkit的源码为什么要那么写，然后才能结合react源码理解react-redux的源码。这次我们就先来理解redux的源码。