唠叨#

上一篇博客 (9月末) 的时候, 本人在写Nuxt 操作localstorage的时候遇到了一个问题, 起初以为是代码设计的问题, 后来发现是需要避免的 水合(Hydration)问题。 当时其实就挺想写一篇文章的, 不过无奈现实生活的繁忙 加上才疏学浅, ssr的水又太深 得花大精力研究我才能写出一篇文章。就拖到现在才写一小篇。悲

一开始我研究 水合问题 我想着就解决水合问题是什么就行了, 然后随便总结几个可能触发水合问题的情况。 后来再看, 水合问题是 SSR(Server Side Rendering) 和 SSG(Static Side Generation) 两种 渲染方式(Rendering Patterns) 共有的一种问题, 那我也得搞懂SSR和SSG是什么, 不然无法理解为什么要水合, 以及水合到底是在干什么。 那要理解SSR和SSG, 我又得知道渲染方式是什么 现在大概有哪些渲染方式…

所以那也只能原谅我了吧, 原谅我拖了这么久才写出这一小篇文章

不过虽然我好像关于SSR和水合问题没多少经验, 但回头一算我竟发现自己已经接触了三个带SSR的项目 (算上我的博客,它是Astro的孤岛渲染方式, 我对博客也改造过)。 那看来我应该还是有底气写好文章的吧。

概念引入#

从知识体系的层层递进来说吧, 我应当先说什么是渲染方式再说下什么是SSR再说什么是水合问题…

不过这可真是条长路, 那就先非常笼统的讲下几个核心名次概念(渲染方式, SSR), 再容我用简单的例子来让大家基本的理解理解SSR和水合问题,能明白几个简单的SSR报错情况, 之后再谈对SSR什么的深刻理解吧。

服务端渲染#

通过上面两种大家熟悉但是不知道名字的渲染方式, 相信大家已经对于浏览器渲染这一操作有了一定的理解了吧。 接下来来到重头戏SSR(服务端渲染)了

那么经常改造自己博客的朋友们都知道, 一般来首博客都是采用 ssr来渲染的; 它的具体渲染逻辑, 简单来说就是 在服务器上预先把页面渲染成完整的 HTML 字符串，然后返回给浏览器, 之后再想办法把js代码嵌到HTML上(实际表现为接管已经渲染好的DOM节点)

相比于CSR呢, 比如说如果你的博客采用CSR, 那么在用户进入博客的时候, 服务器传给用户的会是一个的空壳, 然后浏览器再运行服务器传来的js代码, 在空壳里渲染;

而如果用SSR, 那么服务器会直接把完整的预先渲染好的博客首页内容以带内容的HTML文件的形式传过来, 用户不用再去渲染; 也就是说

首屏加载速度 相比起来会非常的快, 类比餐饮就相当于给了你预制菜, 而SPA是搞了半天还得自己煮;

实例讲解及常见问题#

上面我讲归讲了, 但是实际上肯定还是难以理解的, 以及有很多细节只是看概念也根本懂不了, 下面我来实例讲解下。

虽然普遍来说大家通过博客接触到ssr会多一点, 不过博客的ssr用的框架各不相同, 也不方便我进行实例的书写; 所以这里我用Nuxt框架来讲解

除了Nuxt外, 还有React的Next.js, hexo(搭博客的那个), astro框架(群岛渲染) 比较常见且知名

这里你也不用具体了解Nuxt是什么, 你只要知道他是基于Vue的, 同时又支持SSR渲染就ok了; 不过处于尊重还是贴个中文官网链接

Nuxt中文官网

1
npm create nuxt@latest ssrNuxtProject

这样我们构建一个Nuxt新项目, 你不手动改配置的话那就是ssr渲染

我们来模拟一个key验证的场景

首先对于第一步-获取静态文件, 在自行书写一定的html模拟一个简单的页面后, 你应该也无法直观的感受到性能的提升(不过你大概率能感受到——SSR项目构建是真的慢) 想要体验性能提升的话还是去找找一些常规SSR网站, 或者听听一些框架吹的牛吧

以下来讲下SSR使用过程中的常见报错问题

1
<script setup lang="ts">
2
const key = localStorage.getItem("API_KEY")
3
</script>

1
import { useKey } from "~/composables/use-key";
2
const key = useKey()
3
//下为use-key.ts
4
export const useKey = () => {
5
  const key = localStorage.getItem("API_KEY")
6
  return key;
7
};

1
function getKey() {
2
  return ...
3
}
4
onMounted(()=> {
5
  getKey();
6
})

1
const res = fetch('https://api.example.com/login', { method: 'post' });
2
//下略对res一通操作

1
<client-only>
2
    <!-- 内容物 -->
3
</client-only>

尾声#

其实我还有好多想写的, 像是在我的博客astro项目里见到的如下神秘写法

1
---
2
//本文件是一个组件 叫ConfigCarrier.astro, 被直接挂载到layout.astro (即挂载到所有页面上)
3
import { siteConfig } from "../config";
4
---
5

6
<div id="config-carrier" data-hue={siteConfig.themeColor.hue} data-lightDarkMode={siteConfig.lightDarkMode.defaultMode}>
7
</div>

首先解释下, 这里config文件是博客使用者的设置, siteConfig是里面的存储设置的const变量; 这个组件在其他文件里会被通过dom操作获取到存储的config信息。

那, 为什么不直接在需要这些信息的地方import siteConfig呢?

我目前理解是: 因为config文件并不会被服务端渲染, 也就是说实际压根不会发给客户端

这个东西我接下来也会再研究, 上述猜想要是错了的话, 这篇文章里我也不再修改了, 会在下一篇SSR相关文章写一大段来讲述这相关的内容

碍于时间以及篇幅, 这里就先停笔了 希望你们很快就能看到我的SSR篇2文章捏