V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
React
nanxiaobei
V2EX  ›  React

20 年前的 React Server Components

  •  
  •   nanxiaobei · 84 天前 · 1797 次点击
    这是一个创建于 84 天前的主题,其中的信息可能已经有所发展或是发生改变。

    又看了一遍 React Server Components 的介绍视频。

    不禁想到,内个 ... 以前的 PHP 开发网页,不就是 Server Components 吗?

    而 JavaScript 这玩意最初的意图,就是与 Client Components 一样,处理客户端交互。

    而我们又知道,React 的诞生,本身与 PHP 开发网页的写法有关系。

    突然感到一阵眩晕,真是历史螺旋式上升。


    我们来分析一下故事脉络:

    1. PHP Server Components(90%) + JS Client Components(10%, JS)

    最开始,网页主要是看,交互并不多,PHP 吐「数据 + UI 」,JS 添加 UI 交互。

    2. PHP Server Components(50%) + JS Client Components(50%, jQuery)

    接着,网页交互越来越多,JS 需要操作越来越多的 UI ,不过还是 PHP 吐「数据 + UI 」。

    3. PHP Server Data + JS Client Components(100%, jQuery)

    终于,随着 Ajax 大量使用,JS 获取数据、拼装 UI 、局部更新网页,成了固定开发范式,PHP 觉得既然 JS 这么嘚瑟,这么爱处理 UI ,那就全给你好了,我只负责接口下发数据就行了。

    4. PHP Server Data + JS Client Components(100%, React & Vue)

    这是现在这个时代的 Modern 开发模式。既然 JS 拼装 UI 是为了渲染「数据」,那就改一下思路,让 JS 专门去关心数据,怎么更新 UI 交给框架就好。

    JS 处理了全部 UI 工作,JS 文件越来越大,就带来了新问题。

    JS 渲染 UI:下载 JS → 下载数据 → JS 处理数据 → 渲染 UI

    在 React Server Components 介绍视频中,最初痛点是为了分段渲染 UI ,那么此时,下载数据会慢(演示里为了有序渲染 UI ,希望接口一个等一个)。

    既然下载 JS 、下载数据很慢,而两者是为了得到 UI ,那么不能直接下载 UI 吗?

    于是,撒花,React Server Components 就诞生了。

    听起来多么吓人,其实 20 年前不就有了嘛,PHP Server Components 就是直接下载 UI 😒,20 年前的技术又被重新发明了,Yeah 。

    5. React Server Components(50%) + React Client Components(50%)

    展望未来,我们再回到 20 年前。把 JS 放 Server 端替代 PHP 的位置,React 吐「数据 + UI 」,React 添加交互。

    这么开发起来当然很分裂,尤其是文件名还得区分个 .server.js 与 .client.js ,还有限制,这多费劲啊,让人情不自禁的想崩溃。

    于是,我们还希望展望一下更未来。


    6. React Server Components(100%) + React Auto Client

    免责声明:我不知道技术上能不能实现,我只是瞎扯淡。

    我希望,也别分什么 .server.js 和 .client.js 了,全都是 Server Components ,还跟现在一样的开发习惯,要不然大脑得分裂。

    只不过 React 可以自动把交互有关的逻辑,比如 onClick onChange 等提取出来,放到客户端 JS 里,而把数据 + UI 有关的 JS 提取到 Server 里。客户端与 Server 的通信,也由 React 自动处理。

    现在 React Server Components 通过 stream 的形式下发 UI ,痛点就是函数不能下发,如果也能实现呢?是不是开发者不用关心写的东西在哪运行了,React 去关心就行。

    这觉得是革命性的,我愿意称之为 Modern React 。


    时代一直发展,时代一直在变,但变的总是外在,总有一些东西永远不变。

    如何更好的把 Server 的数据变成 Client 的 UI ,这个故事还会一直讲下去。

    我们拾起 20 年前的概念,发明新名词、描绘新大饼、造出新云雾,我们要改变世界!

    11 条回复    2021-11-03 13:47:50 +08:00
    liberty1900
        1
    liberty1900  
       84 天前 via Android
    所以说学习能力强,接受新东西快是不可信的,只是旧事物裹上了新衣裳,谁都学得快
    2i2Re2PLMaDnghL
        2
    2i2Re2PLMaDnghL  
       84 天前   ❤️ 1
    @liberty1900 所以说真正的接受新东西快,那就看他如何理解『熵』
    这个东西是真正的难解
    rioshikelong121
        3
    rioshikelong121  
       84 天前   ❤️ 1
    我觉得,其实用起来体验完全不一样啊。侧重点也不一样。
    其实 上一代的服务端渲染模式用起来是很头疼的,尤其涉及到一些精细的交互 / 异步的场景的时候。而且技术栈往往是割裂的 (ASP / JSP / PHP and JS),这些偏交互的部分还是放在客户端做起来会更容易一些。

    现在的 Server Component 又不是常见的 React 应用的重心。我是把它理解为一种在服务端运行并返回渲染结果的 API, 放在服务端的好处是和 DB/后端逻辑交互更加容易。

    另外一个和古老的服务端渲染模式相反的现代模式是微软的 blazor 的 server 模式:

    > Alternatively, Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR - a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM
    nanxiaobei
        4
    nanxiaobei  
    OP
       84 天前
    @rioshikelong121 #3 当然不是完全一致的,这里讨论的也不是完全一致的问题。
    duan602728596
        5
    duan602728596  
       84 天前
    问题在于以前是不同的语言写的,而现在是同一个语言写的,不用写两套逻辑
    pluvet
        6
    pluvet  
       84 天前
    我至今觉得 PHP 是很好用的语言,而且回看以前写 php 模板的套路,其实很多就是函数式组件
    ragnaroks
        7
    ragnaroks  
       84 天前
    webform 了解一下,已经淘汰的东西比 react “先进”
    kassadin
        8
    kassadin  
       83 天前
    大致看了一下,有点儿意思
    想到了 PowerBook 和 MacBook 的对比,外形一样,但内核完全不一样
    后端套 react 之类的组件化模板的话确实很香啊
    agagega
        9
    agagega  
       83 天前 via iPhone
    pinkSlime
        10
    pinkSlime  
       83 天前
    20 年前的 php 是一个纯粹的 interpreter 吧,且输出的是文档,如今输出的是 ui
    抖这种机灵没点意思
    aristolochic
        11
    aristolochic  
       83 天前   ❤️ 1
    与其认为是回到了 PHP 或者认为和 Rails 生态的 Hotwire 很像的,不如去看看 Phoenix LiveView ,这个才是完全一致。

    不管是 Phoenix LiveView 还是 React Server Component 还是微软在搞的一些,都要求通过 WebSocket 实现双向的状态共享,也即客户端的状态要么需要在服务端保存完整的镜像并通过 hash 校验检测一致性(状态和 UI 部件),要么通过 ID 作为更新的凭据。这既不是传统 HTTP 那样是服务端到客户端被动单向传输,也不是 Hotwire 用 WebSocket 实现主动单向传输,PHP 的 Laravel 和 Rails 的 Hotwire 因为不愿意实现高效大规模 WebSocket 连接,才要么轮询( Laravel )要么只推数据不维护状态( Hotwire )。尤其是 Hotwire ,意境上就是以前的 Stimulus+Turbolink 改名+现代版 iframe ,这套在以前就没火起来(当然 Turbolink/pjax 用的还是不少的),加上 WebSocket 能推数据了也不比以前的玩法更有革命性。

    明确声明了自己受到 Phoenix LiveView 启发的有一些,比如可以把 Hotwire 中的 Stimulus 改造成 StimulusReflux (早在把 Stimulus 并入 Hotwire 之前就有了),甚至连 Haskell 都有类似的。

    重点还是只靠后端就能在前端实现(稍微)富客户端的应用,如果 All in Live 的话会有问题,比如在 Phoenix LiveView 0.6 之前想要实现回车提交表单(比如做一个即时通信应用的输入框),那么要想自动清空,就需要把输入框中的值也引入前后端共有的状态中,这样用户每敲一个字都会产生一条 WebSocket 消息(当然也做了开箱即用的节流),然后写提交成功后清空这个状态字段的逻辑,要么就得写 JavaScript 钩子。现在倒是能够用后端写 JavaScript 逻辑了,不过还没发布。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2428 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 15:27 · PVG 23:27 · LAX 07:27 · JFK 10:27
    ♥ Do have faith in what you're doing.