react路由与项目实践 | 青训营笔记
01 课程简介
02 写过的路由
路由的概念
路由是桥梁，帮助需求方找到供给方，并进行交换
DNS解析寻址、Nignx反向代理、tcp握手级联
parser url：解析url
router Match 匹配对应的路由
response：回溯返回
前端的历史
静态网站
当网页输入url，返回相应的资源，解析头是content-tpye是text/html,说明资源是html。
问题：更新不便利，难以管理
动态网站
左侧是php服务端代码（路由代码的声明） 右侧是html代码
前后端分离
xml筷子，网站数据的展示可以在后端加载后发起接口请求，异步拿到结果，放在前端作展示
html放在服务端托管
js文件由工程打包出来更新到html模板上
单页应用
将共属于同一个频道多张页面的代码仓库整合在一起，做到代码复用；同时将多页的代码构建打包一个bundle资源，通过路由判断究竟哪一个页面要被展现出来，资源包也只会在网页加载的时候进行等待，后续的跳转页面都可以做到及时响应，不会出现白屏。
前端侧会出现路由的概念
03 React-Router
react-router是核心包，dom面向web前端
history负责管理浏览器url的前进后退，react主要提供的是router和route组件，决定视图如何渲染
解析url———url和路由进行匹配———渲染
单页应用部分
Parser Url（history）
memoryhistory 没有浏览器的环境下，比如像test或者reactnative环境下，把location和url 的相关信息存在内存里面
browserhistory 是常见的history
hashrouter 是不想服务端参与，不想 location被服务器感知 就做纯浏览器路由
这三个方法都返回了一个history实例
这里是一个hash history源码
第一个方框里，它依旧调用了windows里面的history，还是借助的ecma标准规范去实现的
第二个方框里，浏览器标准提供的addeventlistener中的popstate和hashchange这两个监听函数去感知到url的变动，之后进行处理抛出去的对应的实例，关于url相关信息和如何去操作url
总结来说：感知并操作url
router match
是用react route做承接
源码
第11行这里创建了一个history，就是上述history返回的一个实例，以标准组件化的形式向下传递
history实例已经注册到了route组件这里，而history还提供了一系列对外的方法，其中有一个listener方法，通过对history的listen做出的一些回调就能立马感知到整个网站发生了什么变化 ，同时借助react中的setstate变更我们的location，再将变更后的信息透传到react的provider里面中去，然后对应的信息由下游嵌套的children层的consumer进行消费
当包裹route层的router透传下来了一系列location的信息，传递下来url是什么，对比当前声明的url看是否一致
总结一下，1.从history开始，暴露封装后history的方法，抹平hash和history的差异
2.返回一个会话管理的实例，灌注给了最外层router的这个组件，这个组件因为是基于react compoment，所以具有reacr生命周期，同时又具有单向数据流向下传递的能力，在router内部的话同时又去监听了history的变动，变动完之后通过setstate给到了contextprovider这一层，并且把变动的信息透传给了嵌套层的里面的consumer，即route组件，在进行url匹配之后，在通过setstate最后去决定页面如何渲染
如果服务端没有定义a/b/v这样的一个router，那么传统的url打到服务端的时候应该会返回一个404
解决方法就是在后端路由定义一个通配符，当通道以根目录为首或以某一个配置时为目录时，那永远只返回一个contorler，而这一块的处理函数，路由对应的解析就完全在前端里面发生了
04 路由项目实践
应用开发构建交付进行切割瘦身
在微前端里面路由扮演什么？
以single spa的源码来演示
调用浏览器上原生的a---listener，感知到浏览器上发生的变化，知道url发生变化之后，加载啥子应用呢
通过rerouter中的getappchanges感知router的变化，从而知道哪些app需要加载是需要进行卸载的
getappchanges的源码：
核心就是拿到了windows上的location，拿完之后在单个的app里面逐个进行判断，判断在当前的路由状态下，当前这个子应用是否需要进行渲染。
包含两个页面，一个homepage和errorreoprtpage ，home访问的uv（电脑客户端访问数）很高，error的pv（页面访问数）极低，但是他的体积很大。存在一些体积较大的单个页面不给他加载
进行异步懒加载
数据加载处理耗时（内容多，接口多）
如果网站的变更频次比较低，可以预先将网站内容生成好分发到cdn上去，所以之后加载的资源直接是从cdn上分发的，不用再经过ajax和fetch，通过bff把数据做提前聚合直接透出给前端，避免在前端侧进行很多api请求
