这是一个创建于 427 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
Leonard 2023-10-27 23:12:17 +08:00 via iPhone
感觉国内关注 next 的不多
|
 |
2
owen800q 2023-10-27 23:14:39 +08:00
好奇 next 的 ssr 功能是 不支持 vue 嗎
|
 |
3
enchilada2020 2023-10-27 23:17:06 +08:00 via Android  2
@owen800q ？？？ next 不是 react 生态圈的吗 干 vue 毛事
|
 |
4
9ki 2023-10-27 23:38:53 +08:00
懂你意思, 本来不想水但是既然有人提出来....!
https://imgur.com/vQ67ct0 https://imgur.com/wWZRRe7 https://imgur.com/kZJoD9J |
 |
6
hez2010 2023-10-28 00:18:17 +08:00
亮点：复刻 webforms 。
|
 |
7
a632079 2023-10-28 00:28:28 +08:00
楼上发的三张图都是 React 刚移除 experimental 前缀的 Server Actions 以及配套的 useFormStatus 那些吧
 我已经尝试使用 RSC + Server Actions 开发了有一段时间了。总结下来，使用 Server Actions 的方案，其实不如 tRPC 舒服 —— 都是类似的写法，但是 Server Actions 没有中间件的概念，这意味着鉴权啥的都需要你在方法里做😂 按 React 的路径，RSC 用于服务端初次渲染，Server Actions 用于突变、表单（失效状态），但还是有一些边界情况，比如说验证后二次加载获取数据这个分支覆盖不到的，这时候要么 dirty 得将 Server Actions 打破边界，当获取函数用，要么还是得写 `route.js` 定义 API 。 P.S 楼上三张图都是直接 FormAction 里传 Server Actions 的用法，实践里太过恶心了……尤其是前后端穿的状态类型不一致——当你需要使用 Action 返回的 State 就会比较恶心了。此外，必须包装一下 useFormState ，才能比较正确的使用传回来的 State （本质上里面得套个 useEffect ）。 ——所以，个人建议 useTransition 里调用 Server Action —— 里面调用就和调用自然函数一样，而且不需要再封装个 Button 组件用 useFormStatus 以使用 Pending （这玩意必须 Form 子级才能用）。 |
 |
8
HaroldFinchNYC 2023-10-28 01:05:07 +08:00
|
 |
9
hugepizza 2023-10-28 02:12:58 +08:00 via iPhone
@9ki server action 让我有种自嗨的玩具的感觉 使用场景太有限 middleware httprequest 取值 cache mutate 用起来都很局限
想不通他到底比直接 fetct 一下 api/route 加 swr 执行 mutate 好在哪里 |
 |
10
rocmax 2023-10-28 07:18:32 +08:00 via Android
server action 补齐了 next.php 的最后一块拼图:P
next 致力于砍掉所有的 API ，同时也就简化了页面的状态管理。有关数据的逻辑都放到 server 端执行，页面上只管展示的部分。 conf 没顾上看直播，今天补一下。看了点 blog ，next14 主要做各种优化吧，使用上没有什么变化，加了个增强安全的 Taint api 。 前一阵开始用 app router 开发，感觉页面上是干净了不少，但是心智负担从状态管理移动到了区分代码在服务端和客户端 |
 |
11
SorcererXW 2023-10-28 08:29:13 +08:00
习惯了前后端分离，感觉 server action 感觉还是有点儿戏了，至少我是不敢把一个数据库连接对象放在前端页面中操作，最多在 server action 做一些做一些强依赖 nodejs 环境的逻辑。
|
 |
12
Terry166 2023-10-28 12:29:56 +08:00 via iPhone
@hugepizza server component 目的之一是为了在浏览器禁用 js 的时候仍然能正常运行。
One benefit of using Server Actions is their ability to execute even in scenarios where JavaScript is disabled within the browser. This guarantees that crucial operations can still be performed by making server calls, without solely relying on JavaScript functionality. |
 |
13
RedNax 2023-10-28 13:34:18 +08:00 via iPhone
@Terry166 但这个需求也太小众了……
React 最大的应用场景还是做 App ，做 App 有多少情形要关心 Javascript 不能用的需求呢…… 我觉得整个 SSR 都挺奇怪的，为什么做 90%的工作来获得 10%的提升…… |
 |
14
bingtsingw 2023-10-28 13:41:46 +08:00
@RedNax 有 SSR 需求的很多是为了搜索引擎优化，还是有场景和价值的。RSC 纯粹就是脱裤子放屁，就是 vercel 搞出来为了卖他的服务器的。从架构上来说就是一坨屎山，绑定技术栈，拓展和维护都很困难。想不到 web 发展这么多年，还能复古到 10 年前
|
|
15
Terry166 2023-10-28 14:24:18 +08:00
@RedNax 主要是为了 seo friendly ，nextjs 的出现就是为了提升 react spa 的 seo 而出现的
|
|
16
RedNax 2023-10-28 17:23:58 +08:00 via iPhone
@Terry166 我知道 SSR 是为了 SEO ，但 react 最大市场还是做 app （所以有那么多组件库），就像 vercel 自己，需要做 SEO 的其实也就落地页吧……这直接用 wordpress 也没问题啊。
当然我能理解有些场景既想要 SEO 又想要 react ，但就为了这些场景花那么大功夫个人感觉不太值得 |
|
17
Terry166 2023-10-28 19:10:39 +08:00
@RedNax SEO 有落地页，也包括 app router 下的页面比如产品页也可以是 server side generated static page(SSG)，通过 getStaticPaths 用来指定哪些产品需要生成静态页面，可通过 getStaticProps 的 revalidate 设置页面 rebuild 时间间隔。另外 getServerSideProps 是 SSR ，不会生成静态页面，返回的是最新的数据，所以比 SSG 慢一些。
SSG and SSR are both great for SEO. This is because both of them generate their HTML outputs on the server at either build or request time. This means both can be crawled and indexed by search engine bots. Both rendering methods also render pages quickly, which will help SEO rankings. However, out of the two, SSG does render faster so if you have particularly large pages and can use it, SSG will help more. |
Select Language