这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天 冲冲冲!
next实战项目
B端应用---内部
C端应用---外部---对SEO要求比较高
CSR、SSR、SSG
CSR
首屏时间比较长
客户端渲染(Client-Side Rendering),常见B端Web应用开发模式,前后端分离,服务器压力相对更轻,渲染工作在客户端进行,服务器直接返回不加工的HTML用户在后序访问操作
SPA:单页面应用,它所需的资源(HTML、CSS、JS等),在一次请求就加载完成,不需刷新地动态加载,首屏时间更长
SSR
SSR(Server-Side Rendering),从原先的JSP/PHP就已经体现了服务器端渲染
代码耦合度高,且模板语言中混杂变成语言对于一些复杂的功能,很难维护
这种模式下Java、php负责渲染的逻辑,而前端只负责UI和交互
同构SSR
BFF:Backend For Frontend,服务于前端应用的后端
前后端一体化,一套React代码在服务器上运行一遍,到达浏览器又运行一遍。前后端都参与渲染,而且首次渲染出的HTML要一样
SSG
静态站点生成(Static Site Generation),在构建的时候直接把结果页面输出html到磁盘上,每次访问直接把html返回给客户端,相当于静态资源
CDN:建立在覆盖在Internet之上,由分布在不同区域的边缘节点服务器群组成的分布式网络
相比SSR,因为不需要每次请求都由服务器端处理,所有可以大幅度减轻服务器端的压力
缺陷在于只能用于偏静态的页面,无法生成与用户相关的内容,也就是所有的用户访问的页面都是相同的
SSR、SSG的优势
- 利于SEO
浏览器的推广程度,取决于搜索引擎对站点检索的排名,搜索引擎可以理解是一种爬虫,它会爬取指定页面的html
,并根据用户输入的关键词对页面内容进行排序检索,最后形成我们看到的结果
- 更短的首屏时间
SSR/SSg只需要请求一个html
文件就能展现出页面,虽然在服务器上会调取接口,但服务器之间的通信要远比客户端快,甚至是同一台服务器上的本地接口调取,因为不再需要请求大量js
文件,这就使得SSR/SSG可以拥有更短的首屏事件
什么是Next.js
SSR的实现
基于React提供的相关服务器端渲染API实现,整个过程实现比较繁琐重复,从零实现对新上手同学很不友好
迫切需要一个封装好的集合来快速上手服务器端渲染
脱水、注水
next.js是一个构建于node.js之上的开源Web框架,支持基于React的Web应用程序功能,例如服务端渲染和生成静态网站
初始化
npx create-next-app@latest --typescript
Next.js客户端开发
初始化
- next-env.d.ts:确保
TS编译器选择next.js类型,可以放到.gitignore中,不需要变更 - next.config.js:
nextjs的配置,可以补充webpack的一些配置- 比如说补充一些别名
数据注入
- getServerSideProps
- SSR,与
getInitialProps不同的是即时使用router跳转当前页,也只会在服务端执行这部分逻辑
- SSR,与
- getInitialProps
- 在服务器端执行,只能在页面层面进行绑定,采用同构,首次渲染服务器端渲染,路由跳转使用客户端路由
- 意味着如果使用
router跳转当前页,会在客户端执行这部分逻辑
- getStaticProps
- SSG,在服务端构建时执行
- 如果涉及动态路由(带参数),需要使用
getStaticPaths配置所有可能的参数情况
CSS Modules
Next.js支持使用文件命名约定的CSS模块,[name].module.css
Layout
通过在入口文件导入layout,可以实现每个页面公共的页眉页尾
文件式路由
Next.js有一个基于页面概念的基于文件系统的路由器。当一个文件被添加到pages目录中时,它会自动作为一个路径可用
预定义路由优先级更高,预定义路由能直接匹配的路由就不会分发给下面的动态路由
BFF层的文件式路由
BFF,作为服务器构建包,不影响客户端构建bundle体积
相同的router生成方式,不过是作为API访问,而不是page
路由跳转
next/link跳转useRouter跳转- 除了这些外,还可以使用原生方法跳转,不过原生方法不会进行
Diff比对渲染性能上nextjs提供的路由跳转会更好
header的修改
可用于修改TDK(title、description、keywords)
多媒体适配---CSS适配
rem
多媒体适配---JS适配
大图优化---webp
jpg--->webp
Next.js服务端开发
cms---数据管理平台
BFF层开发
和Express等开发类似 区别是并没有参数可以直接区别请求类型
调试方式
npm run debugger
Strapi-headless CMS
初始化:
npx create-strapi-app my-project --quickstart
一个接口的生成的过程:
- content-type builder 编辑结构体
- content manager 配置数据源,并且发布
- setting roles里选择对应角色并勾选要发布的接口类型
- 如果涉及嵌套,在接口后加上
populate=deep参数(npm i strapi-plugin-populate-deep --save),没有安装加参数populate=* ,但只能嵌套一层
核心功能
首页功能实现
- 页面 & 动画 & 多媒体适配
- BFF
- Strapi
文章页实现
- 页面 & 动画 & 多媒体适配
- BFF
- Strapi 分页(/api/articles?pagination[page]=1&pagination[pageSize]=10 //按10个/页分页,返回第一页的数据)
- 多媒体格式的转换
- markdown 转 html:npm i showdown --save
- html 转 dom:dangerousSetInnerHTML
- 公共样式的定义
主题化功能实现
- 基础样式和背景的抽离
- 主题化 context全局注入
- 从注入数据中取出 theme 和 setTheme
- 多进程间的主题同步