是时候进行数据优先的前端革命了！ 回归MVC? - Kea

早在2015年，在了解React和Redux之后不久，我就爱上了它们背后的函数式编程范例，通过遵循不变性和纯度的一些原则，与诸如Ember或Angular的现代替代品相比，React前端通常编写得更好，更稳定且更易于调试。
看了一些函数式编程对JavaScript的作用后，我开始研究当时最受欢迎的函数式语言Clojure和ClojureScript前端框架： reagent (死了), quiescent (死了), om (死了), om.next (死了), re-frame (still alive). 
突出的特点是他们如何处理应用程序状态。他们都至少开发了三个全局隔离的层：

// obvious pseudocode
async function renderApp() {
    while(await waitForChanges()) {
        //收集输入（检查url并调用API）
        const input = await getInputFromURLAndAPIs(window)
       //将其标准化为中间应用程序状态
        const appState = convertInputToApplicationState(input)
      //从该中间状态创建HTML
        const html = convertApplicationStateToHTML(appState)
        
        render(html)
    }
}

async function renderApp() {
    while(await waitForChanges()) {
        //收集输入（检查url并调用API）
        const input = await getInputFromURLAndAPIs(window)
        //根据输入内容创建HTML
        const html = convertInputToHTML(input)
        render(html)
    }
}

Frontend > React > [state management library of choice]

Frontend > Data Layer > View Layer (React)

数据占主导地位。如果您选择了正确的数据结构并组织得当，那么这些算法几乎总是不言而喻的。数据结构而非算法是编程的核心。
 
黑客新闻网友
这不就是回到MVC？
为什么今天使用临时Redux进行React的原因是：复杂的部分通常需要保证，简单的部分通常不需要保证。这些想法并没有什么新颖或革命性的，它们常常被人们遗忘。这是阻力最小的途径。
 
我认为，React和MVC将是一个很好的组合。我使用Backbone.js而不是redux进行了一些早期的React项目，并且效果很好。
 
Frontend中的状态管理确实是一个已解决的问题。使用诸如swr，react-query或Apollo-client之类的工具。
我个人使用graphql，前端客户端自动管理大多数全局状态。更改一个字段，它会在其他组件中更新。模态转换和其他常规逻辑的简单本地状态……这就是我所需要的。每周都有一篇新文章抨击前端复杂性，以redux作为替罪羊。
当然，如果您的前端主要是GraphQL，并且数据流得到了很好的照顾，那么您应该不需要单独的状态管理解决方案。
但是，有时您必须使用各种AP​​I并过滤/显示/修改/更新/删除/更改/修补收到的响应的各个部分。在这种环境中，像Kea（在博客文章中提到）之类的解决方案应运而生。
 
我已经在JS世界工作了很长时间，以至于我已经看到了许多主要的迭代-每个迭代都解决了最后一个问题。

• -jQuery解决了JS的浏览器不一致和局限性
• -Backbone在大型，杂乱的Jquery汤中添加了MVC结构
• -Angular + Ember为您提供了功能更全的MVC，因此您不必在每个主干应用程序之上重建通用逻辑。
• -当我们意识到MVC不适用于前端时，React切换到了面向组件的体系结构。(增加中间状态层)

• 它是可组合的：让一个或多个流轻松创建新的派生流；
• lazy：您可以在数据可用之前描述如何处理数据。
• 多步或异步操作的处理状态（加载状态，取消请求，重试操作）轻而易举。
• 使用rxjs“连接”您的应用程序，您将永远不会遇到麻烦的使用状态建模的麻烦。Typescript友好。它允许对值（BehaviourSubject）和异步（Observable）的同步访问。