## 路由及转场解决方案
### 路由
这个不用讲,和后端的路由原理一样,即什么地址做什么(这里的做什么就比较复杂了,有做什么决定了怎么渲染页面)。
* * * * *
### 转场
我们的任何软件都在有限的屏幕上运行,每一个功能界面都在这块屏幕上展现,切换,我们可以把传统的软件(手机软件、桌面软件)每一个界面间的切换都看做是一个转场,桌面软件`Windows`软件也是转场,我们每天都在和它们打交道,这种场景我们再熟悉不过,以至于忽略他的东西,现在[web app](http://www.kancloud.cn/xiak/quanduan/255922)中出现了,为了提供跟传统app一样的操作体验,现代web应用也引入了这种传统软件中的概念 —— 转场。
> 路由转场也有叫路由动画的
* * * * *
[路由及转场解决方案](https://open-doc.dingtalk.com/docs/doc.htm?spm=a219a.7629140.0.0.YlP1Hp&treeId=177&articleId=104961&docType=1)
更新时间:2016/07/28 访问次数:8217
SaltRouter 为钉钉微应用提供路由及转场解决方案。
salt-router基于页面预加载及转场效果等原生能力,提供了一套简明的路由api。
对于目前大部分h5应用,在页面跳转时,例如A页面跳B页面时,存在以下两个问题:
* 跳转到B页面时,B页面会有一段时间的白屏
* 跳转过程生硬,没有连贯的转场体验
salt-fetch通过提供预加载和转场效果等能力,解决以上这两个问题,优化微应用转场体验:
* 微应用可以根据自身业务,提前预加载下级页面,在跳转时便可加载准备好的页面,避免白屏
* 提供了多种原生级别的转场动画效果,使转场更加连贯,避免生硬的跳转。
![](https://static.dingtalk.com/media/lAHOTX2Ie80CmM0BdA_372_664.gif)
使用方式
~~~javascript
<script type="text/javascript" src="/xx/xx/salt-router.js"></script>
<script type="text/javascript">
window.salt.router.preload({}).then().catch();
</script>
~~~
### 其他
- [浏览器加载初探](http://www.kancloud.cn/xiak/quanduan/245636)
>[danger] **注意:**测试是否为单页最好在PC浏览器上面看,跳转新的页面时**加载状态**会转,但是在微信(PC/手机)或者一些手机浏览器上面,由于没有“转”的状态,而是用**页面顶部加载进度条**的表示加载状态,在手机端即使没有跳转页面(PC浏览器上没看到“状态转”),某个单页需要加载图片等资源,那么加载进度条还是会有,所以手机上面看不出来到底是跳转还是单页。
* * * * *
### 前端路由思考
我们使用的应用都是通过显示屏展示的,并与其交互的,而在屏幕上,使用应用时,随着用户交互,应用的形态都是从一种形态转换为另一种形态,或者从一个页面跳转到另一个页面上,这些特性,元素,构成了我们日常使用的应用。
这种页面的形态,不同功能放在不同页面,之间的切换,转换,这些形成了一些其它的概念,路由,转场等等,其实这些东西都是抽象的,包括页面,什么是页面呢,页面就是我们用来描述显示屏上显示的那些东西。都是应用给我们的一种呈现。
两个页面的切换转换怎么做呢,一般常见的,就是最粗暴的,A页面隐藏,B页面显示,相互这样,这两个动作很快,所以看不出来什么问题,基本不会出现卡顿或者白屏之类的。事实上目前可以说99%的应用都是以这种形态切换页面的,这里所说的应用不局限于web应用,也包括桌面应用,不管怎么样,它们都是通过显示屏显示的。
而现在一些应用为了做的好看,体验上更细腻,则在切换页面上下了不少功夫,比如各种转场特效,入场和出场特效(显示屏就是舞台,页面就是角色),都是不一样的,比如B要进场时,A出场淡出,往左倾斜翻转,B淡入,从右边倾斜翻转过来。这样页面间切换就不会显得生硬了,当然这也对硬件渲染要求也较高,现阶段web的动画效果没有原生动画流畅,这也是为什么很多人说路由转场用原生实现好的原因。
而应用形态的转换也和这差不多,只不过页面覆盖的范围更大,可以这么说, **应用是由一个个页面组成的,而页面中又可以有很多个元素。** 当一个页面元素太多,功能聚合过多,太复杂时,我们就会拆分为多个页面,以减少页面的复杂度,并让功能,操作更合理。
这是在移动端和一些屏幕较小的设备上,应用都是一个页面一个页面的,页面一般占整屏,但是在PC上就不是这样的,PC上一般是以窗口的形式,比如资源管理器一个窗口,QQ一个窗口,酷狗一个窗口。因为屏幕比较大,所以可以同时放多个窗口一起工作,所以PC端效率比较高,可以做更复杂的操作,总之移动端手持设备和PC端各有优劣,各有自己的特点。
* * * * *
last update:2018-3-26 16:21:48
- 开始
- 微信小程序
- 获取用户信息
- 记录
- HTML
- HTML5
- 文档根节点
- 你真的了解script标签吗?
- 文档结构
- 已经落后的技术
- form表单
- html实体
- CSS
- css优先级 & 设计模式
- 如何编写高效的 CSS 选择符
- 笔记
- 小计
- flex布局
- 细节体验
- Flex
- Grid
- tailwindcss
- JavaScript
- javascript物语
- js函数定义
- js中的数组对象
- js的json解析
- js中数组的操作
- js事件冒泡
- js中的判断
- js语句声明会提前
- cookie操作
- 关于javascript你要知道的
- 关于innerHTML的试验
- js引擎与GUI引擎是互斥的
- 如何安全的修改对象
- 当渲染引擎遇上强迫症
- 不要使用连相等
- 修改数组-对象
- 算法-函数
- 事件探析
- 事件循环
- js事件循环中的上下文和作用域的经典问题
- Promise
- 最佳实践
- 页面遮罩加载效果
- 网站静态文件之思考
- 图片加载问题
- 路由及转场解决方案
- web app
- 写一个页面路由转场的管理工具
- 谈编程
- 技术/思想的斗争
- 前端技术选型分析
- 我想放点html模板代码
- 开发自适应网页
- 后台前端项目的开发
- 网站PC版和移动版的模板方案
- 前后端分离
- 淘宝前后端分离
- 前后端分离的思考与实践(一)
- 前后端分离的思考与实践(二)
- 前后端分离的思考与实践(三)
- 前后端分离的思考与实践(四)
- 前后端分离的思考与实践(五)
- 前后端分离的思考与实践(六)
- 动画
- 开发小技巧
- Axios
- 屏幕适配
- 理论基础
- 思考
- flexible.js原理
- 实验
- rem的坑,为什么要设置成百分比,为什么又是62.5%
- 为什么以一个标准适配的,其它宽度也能同等适配
- 自适应、响应式、弹性布局、屏幕适配
- 适配:都用百分比?
- 番外篇
- 给你看看0.5px长什么样?
- 用事实证明viewport scale缩放不会改变rem元素的大小
- 为什么PC端页面缩放不会影响rem元素
- 究竟以哪个为设备独立像素
- PC到移动端初试
- 深入理解px
- 响应式之栅格系统
- 深入理解px(二)
- 一篇搞定移动端适配
- flex版栅格布局
- 其他
- 浏览器加载初探
- 警惕你的开发工具
- JS模块化
- webpack
- 打包原理
- 异步加载
- gulp
- 命名规范
- 接口开发
- sea.js学习
- require.js学习
- react学习
- react笔记
- vue学习
- vue3
- 工具、技巧
- 临时笔记
- 怎么维护好开源项目
- 待办
- 对前端MVV*C框架的思考
- jquery问题
- 临时
- 好文
- 节流防抖