chore: update docs

Author: yiludege

packages/.vitepress/config.cn.mts

@@ -20,6 +20,7 @@ export default {
           text: "指南",
           items: [
             { text: "简介", link: "/cn/guide/introduce" },
+            { text: "动机", link: "/cn/guide/motion" },
             { text: "快速开始", link: "/cn/guide/quick" },
           ],
         },

packages/.vitepress/config.en.mts

@@ -20,6 +20,7 @@ export default {
           text: "Guide",
           items: [
             { text: "Introduction", link: "/en/guide/introduce" },
+            { text: "Motivation", link: "/en/guide/motion" },
             { text: "Quick Start", link: "/en/guide/quick" },
           ],
         },

packages/core/useFluth/index.cn.md

@@ -1,6 +1,6 @@
 # fluth
 
-`fluth` 是一个基于 `promise` 的流式编程库。`fluth-vue` 默认集成 `fluth`
+`fluth` 是一个类 `promise` 的流式编程库。`fluth-vue` 默认集成 `fluth`
 
 具体使用详情见：[fluth](https://fluthjs.github.io/fluth-doc/)
 
@@ -22,8 +22,8 @@ promise$.next(3);
 
 // Logs:
 // resolve 1
-// reject 2
 // resolve 3
+// reject 2
 ```
 
 ## 自动取消订阅
@@ -57,7 +57,7 @@ promise$.then((data) => {
 当`test`组件销毁时`promise$`流在组件内的订阅节点都会自动取消订阅，即当`promise$`流推流后也不会再进行打印了。
 
 ::: info 提示
-`fluth-vue`对`fluth`的`Stream`流内置了一个插件，当在`vue`组件`setup`使用`Stream`后，组件销毁能够自动销毁`stream`的所有订阅，插件实现原理：
+`fluth-vue`在`Stream`内置了一个`then`插件，当在`vue`组件`setup`使用`Stream`后，组件销毁能够自动销毁`stream`的所有订阅，插件实现原理：
 
 ```javascript
 import { getCurrentScope, onScopeDispose } from "vue";
@@ -69,4 +69,5 @@ const vuePlugin = {
 };
 ```
 
+对于还不支持`getCurrentScope`的`vue`版本，需要自行实现取消订阅。
 :::

packages/core/useFluth/index.en.md

@@ -1,6 +1,6 @@
 # fluth
 
-`fluth` is a Promise-based streaming programming library. `fluth-vue` includes `fluth` by default.
+`fluth` is a Promise-like streaming programming library. `fluth-vue` includes `fluth` by default.
 
 For detailed usage, see: [fluth](https://fluthjs.github.io/fluth-doc/)
 
@@ -22,8 +22,8 @@ promise$.next(3);
 
 // Logs:
 // resolve 1
-// reject 2
 // resolve 3
+// reject 2
 ```
 
 ## Operators
@@ -49,8 +49,8 @@ const [selection$, unSelection$] = partition(promise1$, (data) => data % 2 === 1
 const racePromise$ = race(promise1$, promise2$);
 ```
 
-::: warning Note
-`fluth-vue` includes a built-in plugin for the `fluth` `Stream` that automatically destroys all stream subscriptions when a Vue component is destroyed when using `Stream` in the component's `setup`. The plugin implementation principle:
+::: info Note
+`fluth-vue` includes a built-in `then` plugin for `Stream` that automatically destroys all stream subscriptions when a Vue component is destroyed when using `Stream` in the component's `setup`. The plugin implementation principle:
 
 ```javascript
 import { getCurrentScope, onScopeDispose } from "vue";
@@ -62,4 +62,5 @@ streamInstance.plugin.then = [
 ];
 ```
 
+For Vue versions that don't support `getCurrentScope`, you need to implement unsubscription manually.
 :::

packages/guide/motion.cn.md

@@ -0,0 +1,50 @@
+# 动机
+
+## 前端业务模型
+
+在 Web 开发领域中，Web 服务的核心职责通常是接收请求、处理请求并返回响应，从系统建模的角度看，它是一个单输入单输出的同步处理过程。
+这使得 Web 服务的逻辑天然适合抽象为洋葱模型（onion model）：外层中间件包裹内层中间件，请求按顺序穿透各层中间件进入核心业务处理逻辑，再逐层返回响应。常见的中间件包括身份验证、权限校验、日志记录、缓存处理等。
+
+<div class="flex flex-col items-center justify-center">
+  <img src="/model.drawio.svg" alt="motion" />
+</div>
+
+而 Web 前端的业务模型与此完全不同。前端页面运行在用户浏览器中，是一个多输入多输出的复杂系统。它面向用户直接交互，输入来源包括用户点击、输入、滚动、窗口变化、定时器触发、网络 API 响应等，这些事件发生的时间不确定、频率不一致，构成了一个`高度异步、事件驱动*`\*的环境。
+
+与此同时，前端系统也会产生多样化的输出，这些输出不再局限于一次性返回的响应，而是持续、分散地反馈到多个目标上。常见的输出包括更新页面中的 DOM 结构以反映状态变化，执行动画或过渡效果增强用户体验，发送新的 API 请求以拉取或提交数据，修改本地状态（如缓存、存储或组件状态）以准备后续交互甚至与浏览器原生功能交互（如剪贴板、通知、文件系统等），这些输出通常也是`动态分发、异步反馈`的方式。
+
+复杂的输入和输出方式，与传统 Web 服务的“请求-响应”式单一输出形成鲜明对比。
+
+## 前端框架
+
+为了应对前端页面中高度异步、事件驱动、多输入多输出的复杂环境，前端开发逐步演化出一套结构化的建模范式，其中最具代表性的就是 `MVVM（Model-View-ViewModel）`框架。这一范式的核心思想是：将页面的显示逻辑与状态逻辑解耦，并通过“响应式绑定”让它们自动协同。
+在 MVVM 模型中：
+
+- View（视图） 代表用户界面（UI），它是用户交互的前端展现层。
+- Model（模型） 承载了数据与业务状态，是系统运行的核心信息源。
+- ViewModel 是连接 View 和 Model 的桥梁，它负责将 Model 中的数据“转换”为视图需要的格式，同时监听用户操作并更新 Model。
+
+MVVM 框架的最大优势在于：
+当 Model 发生变化时，View 会自动更新；反之，用户操作 View 时，也能自动反映到 Model 上。
+
+这一“自动同步”机制，本质上是一种声明式响应式编程。开发者不再需要显式地组织输入事件、手动更新视图，而是专注于描述“状态如何映射为界面”，让框架负责具体的事件监听和 DOM 更新。
+
+借助这一模型，前端框架能够高效地组织来自用户、网络、定时器等多源输入，并以结构化的方式触发 UI 渲染、状态更新、逻辑调用等多通道输出，使得原本混乱的异步交互逻辑被框架层稳定接管。
+
+## 复杂业务场景
+
+虽然前端框架在处理数据变化更新页面这件事情上做的非常出色，但是随着业务的复杂度不断提升，框架提供出来的编程范式反而会将成为业务的瓶颈。前端框架的编程范式大多都是以组件为核心，以 hooks为颗粒度，将业务逻辑组织在组件中。
+
+将数据的请求、逻辑的处理统一放置在组件中进行处理，数据和逻辑链条通过组件树层层递进，功能也是通过组件来进行组织。对于简单业务这样做似乎没有问题，但是对于复杂业务，下面这些问题就会暴露出来：
+
+1. **组件过于臃肿**：数据的请求、数据的转换、数据的逻辑处理、全部堆在组件内部
+2. **代码阅读困难**：业务逻辑散落在各个组件中，需按照组件链条来理解业务
+3. **通信复杂**：组件层层嵌套，通信非常复杂，也难以理解
+4. **定位困难**：定位问题需要按照组件链条来排查，成本非常高
+5. **无法复用**：视图的差异性导致数据处理和业务逻辑无法复用
+6. **重复请求**：组件内部请求数据导致可以复用的数据难以复用
+7. **复杂度高**：数据流呈现螺旋网状调用，牵一发而动全身
+
+此时按照`DDD`领域驱动设计的思想将业务进行抽离是一个比较正确的选择，当将业务模型从组件抽离后，组件变成了`受控`，只消费模型提供的数据。那么我们该如何组织业务模型呢？我们的代码已经不在组件内，`vue`或者`react`提供的编程范式也不再适用，前端的高度异步特性如果用 class 来组织业务模型此时并不是一个非常好的选择。
+
+## TODO...

packages/guide/motion.en.md

@@ -0,0 +1,51 @@
+# Motivation
+
+## Frontend Business Model
+
+In the field of Web development, the core responsibility of Web services is typically to receive requests, process them, and return responses. From a system modeling perspective, this is a single-input, single-output synchronous processing flow.
+This makes Web service logic naturally suitable for abstraction as an onion model: outer middleware wraps inner middleware, requests penetrate through each layer of middleware in sequence to reach the core business processing logic, then return responses layer by layer. Common middleware includes authentication, authorization, logging, caching, etc.
+
+<div class="flex flex-col items-center justify-center">
+  <img src="/model.drawio.svg" alt="motion" />
+</div>
+
+However, the business model of Web frontend is completely different. Frontend pages run in user browsers and constitute a complex system with multiple inputs and multiple outputs. They face direct user interaction, with input sources including user clicks, input, scrolling, window changes, timer triggers, network API responses, etc. These events occur at uncertain times and inconsistent frequencies, creating a `highly asynchronous, event-driven` environment.
+
+Meanwhile, frontend systems also produce diverse outputs. These outputs are no longer limited to one-time responses but continuously and dispersedly feedback to multiple targets. Common outputs include updating DOM structures in pages to reflect state changes, executing animations or transition effects to enhance user experience, sending new API requests to fetch or submit data, modifying local state (such as cache, storage, or component state) to prepare for subsequent interactions, and even interacting with native browser features (like clipboard, notifications, file system, etc.). These outputs are typically delivered through `dynamic dispatch and asynchronous feedback`.
+
+The complex input and output methods form a sharp contrast with the traditional Web service's "request-response" single output pattern.
+
+## Frontend Frameworks
+
+To cope with the highly asynchronous, event-driven, multi-input multi-output complex environment in frontend pages, frontend development has gradually evolved a structured modeling paradigm, with the most representative being the `MVVM (Model-View-ViewModel)` framework. The core idea of this paradigm is to decouple page display logic from state logic and make them automatically coordinate through "reactive binding".
+
+In the MVVM model:
+
+- View represents the user interface (UI), which is the frontend presentation layer for user interaction.
+- Model carries data and business state, serving as the core information source for system operation.
+- ViewModel is the bridge connecting View and Model. It's responsible for "transforming" data from Model into formats needed by the view, while listening to user operations and updating the Model.
+
+The greatest advantage of MVVM frameworks is:
+When the Model changes, the View automatically updates; conversely, when users operate the View, it can automatically reflect to the Model.
+
+This "automatic synchronization" mechanism is essentially a form of declarative reactive programming. Developers no longer need to explicitly organize input events or manually update views, but focus on describing "how state maps to interface", letting the framework handle specific event listening and DOM updates.
+
+With this model, frontend frameworks can efficiently organize multi-source inputs from users, networks, timers, etc., and trigger multi-channel outputs like UI rendering, state updates, logic calls, etc. in a structured way, allowing the originally chaotic asynchronous interaction logic to be stably managed by the framework layer.
+
+## Complex Business Scenarios
+
+Although frontend frameworks excel at handling data changes and updating pages, as business complexity continues to increase, the programming paradigms provided by frameworks can become bottlenecks for business development. Most frontend framework programming paradigms are component-centric, with hooks as granularity, organizing business logic within components.
+
+Placing data requests, logic processing uniformly within components for handling, with data and logic chains progressing layer by layer through the component tree, and functionality organized through components. This seems fine for simple business, but for complex business, the following problems emerge:
+
+1. **Overly bloated components**: Data requests, data transformation, data logic processing all piled up inside components
+2. **Difficult code reading**: Business logic scattered across various components, requiring understanding business through component chains
+3. **Complex communication**: Components nested layer by layer, communication is very complex and difficult to understand
+4. **Difficult positioning**: Problem location requires troubleshooting along component chains, with very high costs
+5. **Cannot reuse**: View differences make data processing and business logic unable to reuse
+6. **Duplicate requests**: Component internal data requests make reusable data difficult to reuse
+7. **High complexity**: Data flow presents spiral network calls, affecting the whole system when touching one part
+
+At this point, abstracting business according to `DDD` Domain-Driven Design thinking is a relatively correct choice. When business models are abstracted from components, components become `controlled`, only consuming data provided by models. So how should we organize business models? Our code is no longer within components, and the programming paradigms provided by `vue` or `react` are no longer applicable. Given the highly asynchronous nature of frontend, using classes to organize business models is not a very good choice at this point.
+
+## TODO...