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

21-05-19 banq

早在2015年,在了解React和Redux之后不久,我就爱上了它们背后的函数式编程范例,通过遵循不变性和纯度的一些原则,与诸如Ember或Angular的现代替代品相比,React前端通常编写得更好,更稳定且更易于调试。

看了一些函数式编程对JavaScript的作用后,我开始研究当时最受欢迎的函数式语言ClojureClojureScript前端框架: 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)
    }
}

没有框架会跳过应用程序状态步骤。

也就是说,上面框架没有像下面这样做(好像是Jquery做法):

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

 

三层

所有这些框架得出的结论是,将API响应转换为DOM节点的最佳方法是首先将它们转换为中间表示:全局应用程序状态。

这三层(输入,数据和视图)具有重叠但又独立的并行层次结构:

输入数据的结构与应用程序状态的结构不同,而应用程序状态的结构也与DOM节点的结构不同。

Facebook / React上的人们都同意:要建立出色的用户体验,您将从并行的数据和视图树中受益。他们毕竟会使用Relay作为其状态。

你会使用 Concurrent ModeSuspenseuseTransitionstartTransitionuseDeferredValue,。被建议:开始在事件回调早期抓取,React的方向是越来越多将职责从数据层中剥离出来。

我认为这是可维护性的明显倒退。

 

数据第一

我认为是时候改变了。现在是进行范式转变的时候了。

现在是时候在数据优先的前端框架中进行革命了,该框架将React赋予其最擅长的功能:渲染和DOM差异。输入值,输出动作,但是没有useState。没有useEffect。

实际上,这意味着采用数据层作为应用程序的核心。

这意味着要从:

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切换到了面向组件的体系结构。(增加中间状态层)

我认为,下一个JS大更改将解决的下一个大问题是组织和与数据层进行交互是很痛苦的。edux很复杂*,并且在许多用例中都需要大量的开销。诸如React-Query之类的工具使处理一种全局状态变得容易,但是会通过将其与视图层混合来实现的。

下一个主要的前端方法(无论是单个框架,使用React的数据层还是新的工具集)的有力竞争者将是真正能够很好地解决数据层问题的人。

* Redux的核心实际上确实很简单,但是它是如此令人难以置信,因为每个人都不可避免地构建自己的复杂定制工具来处理它。

  

我相信rxjs解决了数据层问题。

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

去年,我与之紧密合作,没有出现无法使用rxjs建模的情况。

但是人们会坚持使用知名互联网公司大肆宣传的内容。营销能力赢了,而不是质量。

 

在过去的7年中,主要工作一直是构建大型Web应用程序,并逐渐摆脱了FE生态系统的混乱局面,因此,我开始对React的未来感到不那么乐观了。这就是为什么像redux这样的东西对我们中的某些人如此诱人的原因。Redux并不是那么复杂,并且样板大部分已减少到几行代码。

随着钩子、suspense、异步渲染以及服务器组件的影响,React的复杂性持续增长。我认为对于个人项目,我可能会接触到Svelte之类的东西。

  

始终使用redux + redux-saga来获得数据。我没有使用过reframe,但是已经阅读了很多次文档。redux-saga似乎是一个很好的替代方案,在react / redux世界中非常流行。

 

1
猜你喜欢