前端路由(一)

前端路由之变化url不发送请求

什么是路由?为什么要有前端路由?

首先,域名的组成:http://(协议)www.(子域名)abc.com(主域名):8080(端口号)/a/b(请求资源地址)。其中路径为  "/a/b",在web服务器中,把请求路径交给对应的处理逻辑去处理,这就是[路由分发],这就是路由做的事。

以前,路由工作都是由后端做,通过用户请求的url导航到具体的html资源文件来展示不同的页面。

导致前端开发中的痛点

一、我们在开发翻页看评论时,有两种方式,点击下一页,1、ajax post请求请求到下一页数据展示出来,他的优点是能不刷新页面更新数据,但不能记录页面位置,分享给别人或者自己刷新都会回到第一页。2、ajax get请求到下一页数据会把?page=n+1,记录在url中,它的优点是能记录翻页位置 刷新页面不会回到第1页,但每次翻页都会刷新页面

        其实就是能否在不刷新页面情况下,前端js能动态监听到url变化,根据不同url发送异步请求更新页面内容的问题。

二、后端路由每访问一个新页面都要向服务端发送请求,然后服务端再响应请求刷新页面,这个过程会有延迟,用户体验不好。

        两者总结一下就是希望,(主要)1、页面跳转不用异步请求来刷新页面,我们前端直接能做到,省时。(一些场景做不到)2、在只能用url记录页面状态的场景下(如分享),能不刷新页面就监听到url变化对视图做一些操作(如翻页),场景就是分享+翻页。

但是,我们 既想不刷新页面又能记录当前翻页状态访问新页面时只变化路径提升用户体验。所以我们前端需要自己来操纵路由,操纵路由就做到 改变url的同时 浏览器不向服务器发送请求。

能做到这点的有两个人,html5手下的history(html5特性,部分浏览器不支持)和url手下的hash(url中有#,对SEO不友好)。

history有3样武器,history.pushState(stateObject, title, url)、history.replaceState()、window.onpopstate 分别能够在浏览器history对象中偷偷的生成一条新的历史记录(不发送请求),替换一条历史记录(不发送请求),当前进后退history到前两者的留下的历史记录时做出反应。

hash我们可能不熟,但他的另外一个名字(锚)大家都应该熟悉,location.hash即返回url中#后面的部分。平时我们用它来做锚链接(<a href="#aa"></a>, <p name="aa" id="aa"></p>) 跳到页面相应位置。此外,它还有一个不为人知的功能就是 改变url的锚链接,页面不会发生跳转,且onhashchange可以监听hash变化,这正是我们需要的。

选谁?我们需要对这两个人做一下比较分析。

1、history的pushState()偷偷设置的url必须是与当前url同源的(同 协议/子域名/主域名/端口号,不然可以假冒淘宝url,有危害),不刷新情况下也是同文档的;hash只能修改#后面的部分,因此只能设置与当前url同文档的url。这点对于我们来说实际作用差别不大。

2、history的pushState() 设置的新 url 可以与当前url 一模一样,这样也会把记录添加到栈中;而 hash 设置的新值必须与原来不一样才会触发动作将记录添加到栈中。不太重要。

3、history的pushState() 可以通过 stateObject 参数可以添加任意类型的数据到记录中;而 hash 只可添加短字符串。用到不多。

4、url的hash, 仅 hash 符号之前的内容会被包含在请求中,无论如何改变hash都不会请求页面;history的pushState() 是需要后端配合的,因为 用户手动刷新页面或者手动修改url跳转页面(都会请求页面)是会报404错误的。这点挺有用。

5、history的pushState() 比url的hash(#)要美观。

6、history api 支持 ie 10+ ;url的hash 支持 ie 8+。浏览器兼容性。

概括一下主要区别:1、history比hash兼容性好。2、history当用户修改或手动刷新url时会发送真实请求,需要后端配合,在服务端增加一个覆盖所有情况的候选资源:如果 URL 匹配不到任何静态资源,则应该返回同一个 index.html 页面(app依赖的index页面)。这么做以后,你的服务器就不再返回 404 错误页面,因为对于所有路径都会返回 index.html 文件。为了避免这种情况,你应该在 Vue 应用里面覆盖所有的路由情况,然后在给出一个 404 页面作为警告。hash没有这个状况。3、hash导致url中的"#"对SEO不友好。4、history比hash,url更美观。

大家觉得自己的项目 适合哪个?

但是,history api和 hash 只是做到了变化路由 不发送页面请求,那么如何把路由和相应模版数据对应起来,vue-router有一个构造函数Router,实例化Router通过它把路由和模版数据对应起来,再绑定在vue实例上。

接下来我们会继续介绍 如何把路由和相应模版数据对应起来?

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,029评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,395评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,570评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,535评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,650评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,850评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,006评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,747评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,207评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,536评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,683评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,342评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,964评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,772评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,004评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,401评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,566评论 2 349

推荐阅读更多精彩内容