day16/上午/323-尚硅谷-尚融宝-关于created和mounted渲染的问题

啊，首先呢，我们来看一下，就是咱们前面实现的这个功能呢，实际上呢，它是可以正常执行的，我们刷新一下。刷新一下的话呢，你会发现这个借款额度呢，实际上他拿到了啊，就证明呢，我们刚才调用的这个后端接口呢，貌似是没有问题的啊，但是呢，实际上它有个瑕疵哈，我们不能说它完全没有问题的，就是你这样写也是可以的，但是呢，呃瑕疵在哪呢？大家发现我呢，刚才把这个呃后台的控制台呢都清空了，清空了之后呢，我又重新的去访问了一下页面，访问完页面之后呢，虽然前端看起来没有任何问题，这边也获取了，这边也获取了，但是后台呢，他其实报了一个错，他后台报的错呢是这样的，就是他说未登录。什么时候我们这个后台会说未登录呢？啊，就是在这个JWT这个里面呢，他去获取这个token的时候，你看它是在这个地方报的，就说明呢，他这个token他没拿到。

啊，Token怎么会没拿到呢，我们来看一下，在我们这个地方，我们可以看一下F12 f12的话呢，Network这面我们还是重新刷新一下啊，啊刚才我们想看的呢，就是这个get borrow amount这个对吧，这个这个接口方法，这个接口方法它有没有携带ton过去呢？它实际上是携带了头N过去的。啊，它是携带了头款过去的，那所以呢，正常情况下呢，这面如果说是携带了头款过去的话呢，他就应该能够拿到啊，所以呢，在这个地方。在这个地方正常情况下。我们呢，是应该能够拿到token的。但是呢，实际情况呢，是是这个地方你会发现他并没有拿到token，但是原因是什么呢？原因是呢，我们的这个quiz方法。

这个create方法呢，它默认情况下呢，首先它会在服务器端执行，哪个服务器端不是后端服务器啊，是前端服务器端执行啊，前端服务就是现在我们的应用程序的架构呢，是这样的，我给大家画一下，就是这面呢是浏览器端。然后这面呢，是前端服务器端，然后这面呢，是我们的后端服务器啊，然后呢，这个create方法呢，它默认情况下呢，首先它实际上是在是在这个前端服务器端执行的。那么前端服务器端它脱离了浏览器环境，他如果脱离了浏览器环境呢，它是没有cookie的，因为cookie在浏览器当中才有，你如果没在浏览器当中执行这个create呢，它就没有这个啊，就是cookie，他如果没有cookie的话，大家想我们这个token是从哪取出来的？

是不是从cookie里面取出来？你看application cook吗？我token在这儿存着呢，我Ken是从这取出来的。在哪块写的来着，是不是在我们前端的这个。我记得我们当时是写了一个plug ins吧X对吧？对，给大家写好了，就是在前端的这个请求拦截器当中，我们呢，是通过cookie当中是吧，获取了user info啊，就是这个cookie当中的user in for，这不是cookie嘛，获取了user INF for，然后接下来呢，在cookie当中拿到user in for之后呢，付给了这个user in for这个变量，然后判断了一下这user ino在不在，如果user for在的话，我们就从这个user for当中呢，解析出什么呀，解析出Jason对象来，然后呃，这个对吧？啊，然后把这个Jason里面的这个user INF for里面的这个token，因为我们这个user INF for这个cookie里面，你看它是不是有一个token在呀。

看在哪看一下。应该知道吧，这个偷看我把它复制过来啊。通知一下。To。哎，我就偷看呢。这款啊。对吧，有啊好，这不就是我们的这个token嘛，所以呢，从整个user in for这个对象当中，咱们能拿到token，那这样的话呢，刚才这句话的意思呢，就是把user info字符串转换成user in对象，然后从user ino对象当中拿到token，然后再把这个token放在我们当前的请求参数的head当中，对吧？放进去之后，那么我们在后台的服务器当中呢，它才能取出来。啊，所以说我们发请求的时候呢，他第一次发的这个请求呢，是在前端服务器端执行的，他没有前端服务器，它没不是浏览器环境，它没有这个cookie，他没有cook的话，他也就取不着token，他取不着token的话，那这块那就宣告失败了，好如果在前端服务器端执行完这个过程宣告失败了的话，那么就是next有一个特点啊，他还会在浏览器端再发起一次请求。

前端服务器端发起的这个create宣告失败了之后，那么它在浏览器端还会再发起一次请求，所以呢，后面。在浏览器端就是这边宣告失败之后，在浏览器端呢，又发起了第二次请求，好在浏览器端发起的这个第二次请求呢，他成功了，成功了之后呢，就把这个token呢，就传过去了啊传过去了之后呢，也就是第二次在浏览器端执行的这个。

这面哈，这个create的方法呢，他找到了浏览器端的cookie，然后把cookie呢就传过去了，所以实际上这个create他执行了两次，第一次的时候这个宣告失败了，然后第二次的时候在浏览器端执行成功了，然后呢，他就后面就继续执行，继续执行之后呢，就把页面当中的这个数据呢，就就拿到了啊就拿到了，所以这个是这样的一个场景啊好，那我们能不能说把它优化一下呢？也可以，如果这样做的话呢，其实也没问题，只不过第一次取值的时候失败，又进行了第二次取值成功了，那如果你想优化一下的话，不让它后端报错，那你这个地方就可以写market。这样market它是一定是在浏览器端执行的，它就不在服务器端执行，因为这个是渲染完成之后，所谓的渲染就是在浏览器端执行，对吧，你都渲染出来，都展示出来了给用户，那么一定它是在浏览器端执行的啊，所以呢，这面呢，就一定啊会拿到这个cookie啊，那这样的话呢，他就不会报错，所以呢在这面。

我们把它清空一下啊，清空一下的话，然后这面呢，我再刷新，大家看结论是一样的，结果都是一样的啊，但是呢，我们这面呢，你看就没有那个一开始的那个cookie获取不到的那个错误了，他直接呢，就通过cookie获取到当前用户的信息，然后继而执行查询了，所以呢，这个地方呃，大家就是你可选择性的去修改一下，包括之前可能呃某些地方也有这个问题啊，那如果有这个问题出现的话呢，大家就把这个create改成mount就可以了，但是其实这一块呢，它涉及到的是next里面的一个create的执行的一个复杂流程，所以一开始呢，就没给大家去详细的讲，我相信我刚才讲完了之后，可能也有很多同学也不太明白，那我们不用去纠结，因为那个里面其实涉及到的前端的知识还挺多的，里面挺绕的，我也没有办法，就是在大家已掌已经掌握的这种非常少的前端知识的基础上呢，给大家。

他呃，真正的把这个内部的这个执行流程呢，就是更为详细的说出来，因为说你们可能也听不懂哈，所以大家就知道什么就行了呢，就是如果不想让它的这个后端报错的话，那么我们就换mount就行了，但是如果你写critic的话，它后端虽然报错，最后的执行结果也是没有问题的。明白吧啊，所以其实这块更严谨的写法是写monkey，但是呢，写monkey的话，对于大家来说不太好理解，不太好解释啊，那么写credit的话呢，会出现一个问题，会出现一个错误，然后所以大家了解这块就可以了，明白吧啊所以就不用深究啊，因为我们作为后端的话，对前端这块确实不是不是特别了解的情况下，你你不好理解它啊，所以我们就不去追根刨底，刨根问底了啊好吧啊，所以这块的问题我给大家说说明白了，然后呢，解决方案呢，也给大说了，就是用market来解决好吧啊好，然后呢，所以呢，这块大家根据自己的情况吧，你就选择必要的方法就可以了，那前提呢，就是print的这个里面调用的方法，它涉及到有什么呀，涉及到有这个O路径啊，凡是有奥路径的，我们后台都要干嘛呀，都要去获取token啊，这个时候会出现这个问题啊，所以这个大家了解一下就可以了。