早在2022年，在disastrous conference期间，我有一个很好的机会与Solid和Astro的朋友交谈 - 这是会议中最好的部分！各方面都有健康的交流和思想的挑战。
的重复性只是水合。
那些dawgs挑战了我。
我有一个很强的直觉，他们错了，但是我怎么能说出自己的观点呢？哪种心理模型可以帮助显示差异？
jQuery有水合吗？
让我们进入基础知识。首先，我们将水合定义为什么？在我们的谈话中的某个时刻，情况转向侧面，任何东西都可以称为水合，甚至是您在Rails应用程序上的Ruby的一些jQuery脚本。
当Spa框架（例如React，Vue，Svelte或Angular添加SSR支持）之类的水疗框架时，首先看到水合作为算法。为了使这些框架在浏览器中变得互动，他们必须重新执行整个应用程序（如果运行任何JavaScript意味着水合，那么水合作为概念失去了所有含义。它没有用，并且尝试重写历史
<App/>）的整个应用程序，以恢复序列化为HTML（renderToString）时丢失的状态和事件处理程序。
所有水合实现都将单个组件作为root（通常是<App/>），为了使其互动，树上的每个组件都必须执行。只有在设置事件处理程序后，用户才能与之进行交互。
水合只能通过将交互性添加到先前在服务器中执行的组件树中添加交互性的过程来理解。这是O(n) 算法，其中n是要唤醒的组件的数量。
部分水合
Astro框架引起的部分水合的概念是从理解中出现的，即并非树的所有部分都需要水合，尤其是那些完全静态的部分。这种方法建立了“互动岛”，减少了浏览器上的工作量，从而导致更快的交互性。
部分水合正是：在不同时刻多次调用hydrateRoot()，所以名称恰好适合。
但是，必须强调，这些“互动岛”需要由开发人员手动创建。另外，这些岛屿建立了边界，这意味着每个岛屿都是独立的子申请，这可能会阻碍您应用程序的不同部分之间的通信。
React服务器组件是水合
就像部分水合一样，RSC是带有不同姓氏的水合，我们可以称之为稀疏水合。
，RSC不是创建孤立的岛屿，而是保持单个根，使组件可以相互通信。但是，根部的服务器组件不需要在浏览器中重新执行。取而代之的是，将这些组件的Vnodes序列化为数据。这是一个space-time trade-off。
就像岛屿体系结构一样，开发人员必须努力在React服务器组件中设置边界，使用“使用服务器”或“使用客户端”指令。
从根本上是一种不同的算法
最后，我们深入研究了简历，这是一种范式，它提倡即时互动，而无需补充水化或行走组件。它完全偏离了树结构。
可重复性是唯一的，因为根（或入口点）是事件处理程序，而不是组件。
在传统的水合，部分水合和React服务器组件中，该组件充当根。对于部分水合，您可能有几个根，而对于React服务器组件，您有一个。
另一方面，的可重复性将事件处理程序置于根部。箭头从事件回到组件，表明即使可以重新渲染的组件也不需要运行任何用户代码。这种方法有效地将所有组件视为静态，无论它们是否是静态。
可重复性是前端开发的哈希映射，a O(1) architecture where it does not matter how many components您的应用程序具有恒定的JS量。水合从根本上是一棵树上的步行，需要下载和执行所有交互式组件。
结论
不同的水合形状具有各种优势和缺点（这应该得到单独的博客文章）。从根本上讲，它们运行了相同的算法，使开发人员能够进行不同的权衡，从而改变了同等的O（n）算法的“ n”。
部分水合允许开发人员垂直将其应用于岛屿，而RSC则允许开发人员水平拆分应用程序。 app。
另一方面，可重复性的地形使它成为一种完全不同的算法，类似于您不能破坏球而不能将球变成甜甜圈的想法。如果不打破某些板块，基于水合的框架就无法重新恢复。
对于拓扑学家而言，球体与立方体相同：它们都是三维形状，没有任何孔。