这是我参与第五届青训营伴学笔记的第八天
next.js实战项目
web应用
B端应用：用户群体为内部用户 几乎没有sceo的要求
C端应用：用户群体为全体互联网 对sceo的要求很高
next.js是C端应用
2.CSR SSR SSG
CSR
客服端渲染 常见的B端web应用开发模式，前后端分离 服务器直接返回不加工的HTML 不会显示所有元素 要在后面的加载才能全部加载出来 在一次请求中就加载完成，首屏时间长（第一次打开这个页面所需要的时间）
SSR
服务端渲染 代码耦合度高，且模板语言中混杂编程语言对于一些复杂的功能 维护起来很痛苦 这种模式下java，PHP负责渲染的逻辑 前端只负责UI 交互
同构SSR
请求的HTML元素都会一次性带过来
前后端一体化，一套React代码在服务器上运行一遍，到达浏览器 又运行一遍，前后端都要参与渲染，而且首次渲染的HTML都一样
意思就是前端后端都需参与渲染
BFF
服务于前端应用的后端
是前端和后端的一个中介
接口只需要在乎数据本身，提高大项目中的复用性和效率
SSG
静态站点生成
在一开始构建的时候把html返回给客户端，相当于一个静态资源 可以大幅度减轻服务器的负担
缺陷是无法生成与用户相关的内容，也就是所有的用户访问的页面都是 相同的
SSR SSG优势
C端应用最重要的点就是搜索排名
那么因为SSR SSG会一次性爬取HTML，并且根据用户输入的关键字 对页面内容进行排序检索，最后形成我们看到的结果 这对整个站点的排名会有很大的帮助
更短的首屏时间
只需要HTML文件就可以展现出页面，服务器之间的通信远比客服端快 就不需要请求大量js文件，使得SSR\SSG的首屏时间更短
3.什么是next.js
帮助更好更快的开发SSR,SSG的项目
SSR的实现
SSR核心是同构 客户端做的事情服务端也会做
服务器端渲染
注水 脱水 在服务器端返回一个页面时，把客户端的数据脱出来 渲染客户端的时候再把数据返回 保证数据同步 同构
next.js可以避免react要做很多重复步骤，对于前后端一体化很友好
next.js客户端开发步骤
1.初始化
2.数据注入
getInitialProps
用于SSR
比较老的API 一开始只有它 这个api并不是只走服务端，内部的跳转会走客户端 直接打开会在服务器端走
getseversideprops
用于SSR
它只会在服务器端走
最好使用getseversideprops
initial和sever的写法几乎一样
getstaticprops
SSG，在服务器端构建时执行
/getstaicpaths会把所有情况都列出来/
css Modules
在类名的后面加入哈希值，就不会出现样式互串
layout
通过在入口文件导入layout,可以实现每个页面公共的页眉页尾
就不需要重复开发
文件式路由
预定义路由优先级更高，预定义能直接匹配的路由就不会分给下面的动态路由
next.js有一个基于页面概念的基于文件系统的路由器，当一个文件被添加 到pages目录中时，它会自动作为一个路径可用
BFF层的文件式路由
BFF作为服务器构建包，不影响客户端构建bundle体积，相同的router 生成方式，不过是作为API层访问，而不是page
路由跳转
next/link跳转
useRouter跳转
也可以使用原生跳转方式，因为原生跳转不会进行Diff比对渲染，性能上 next.js提供的路由跳转会更好一点
header修改
可用于修改TDK（title,descrption,keywords）
多媒体适配 CSS适配
rem可以灵活换算，会根据设备的fand-size来换算 可以适配大部分，但不是完全一样
如果不同设备整个组件负担表达方式都改变了 我们就需要使用js适配
大图优化-webp
把体积大的图片减小到很小 webp需要更多的解析时间，在快网速的情况下会比png更慢一些 它和所有设备不是全部兼容的
在head部分会显示出来支不支持webp格式
当浏览器不支持时，我们需要使用png格式来兜底
BFF层开发
和express等开发类似
区别是并没有参数可以直接区别请求类型，它没有中间键
调试方式
数据管理平台
会比较数据库更为简单
Strapi-headless CMS
一个接口的生成有以下几个过程:
1.content-type builder 编辑结构体
2. content manager 配置数据源，并且发布
3. settings roles 里选择对应角色并勾选要发布的接口类型
4.如果涉及嵌套，在接口后加上 populate=deep 参数 (npm install strapi-plugin-populate-
deep --save) ，没安装加参数 populate=* ，但只能嵌套一层
