关于我的一点

我是建筑行业电气承包商的全栈开发人员。我是自学成才的,我只与其他开发人员一起工作了几年,他教会了我我所知道的,但现在我是唯一的开发人员。

我工作的公司是一家彻头彻尾的微软商店。我们在前端做 React,用 Dapper 作为我们的 API 的 ASP.Net Core,和作为我们的数据库的 MSSQL 服务器(2008 年,刚刚移动到 2016 年)。我们所有的东西都在公司防火墙后面托管,所以我们使用移动 VPN,这样我们的现场人员就可以在他们的 iPad 上访问我们的应用程序。这是真正的踢球者,我们使用 Windows Auth 而不是我们自己的授权或第三方服务。

我对这个臭鼬工厂类型项目的想法纯粹是基于我的知识和技能,并带有一点希望和梦想;]。

为什么,哦,为什么,另一个 Web 框架?

最近,当我开发一个新功能或一个新项目时,我遇到了 React 的问题,我希望我可以挥动一根魔杖并让它消失。大多数时候,它都在追查为什么这个组件不断地重新渲染。其他时候,它决定了我的状态应该如何构建。但有时,我发现我需要重构我的代码库的一部分,因为我最初认为会起作用的东西却不起作用。

回到我是开发者荒地中的独立开发者这一事实,我没有多少人可以从中汲取灵感。我想大多数时候我都在忙于就项目应该如何构建提出意见?这个状态应该在 Redux 中还是只在本地?我的自定义钩子在哪里?为什么有时管理 API 调用如此困难?这些挫败感最近爆发了,我编译了一个列表方面,如果我有自己的框架,我会修复它。

诚然,这些问题可能不是问题,我没有适当的技能/知识来有效地处理它们。所以这个项目更多的是对 Web 框架如何工作和进一步发展我的技能的探索。我不希望它成为下一个 React,甚至不会被使用。

那么我具体有什么问题呢?

我要列出的很多问题都围绕着 React 没有内置的实用程序或没有强烈的意见。我相信很多人都喜欢这种方式,但有时我发现在特定项目中处理它是一个挑战。以下是我通常遇到的问题:

状态管理

没有单一的方法可以有效地管理状态。我说的是本地和全球。是的,有很多方法,但它们似乎都有取舍。我不在乎道具钻探,但有时状态是如此之小,以至于它才有意义。其他时候我觉得被迫将状态放入 Redux,因为道具钻探会很荒谬,尤其是当它只是一个控制模态的布尔值时。

许多人试图解决的最大权衡是样板问题。我明白为什么我必须编写一堆代码来管理全局状态,你永远不会摆脱写东西。你必须写一些东西,而这些东西主要是状态。但是您必须小心如何构建该状态,因为糟糕的结构会导致其他组件在不应该重新渲染时重新渲染。

同级组件

与同级组件进行通信可能会很痛苦,因为在使用 prop Drill 还是 Redux 操作方面存在优势。例如,我有一个表格行,它触发一个侧面板以打开有关该行的更多信息。有时表格行嵌套很深,很明显你会使用 Redux。其他时候嵌套差异只有两个,您必须在 Redux 或拥有该功能的父级之间做出决定。

我并不真正关心拥有他们不关心的功能的组件。父母的唯一工作就是将此功能传递给它的孩子,因为孩子们自己不能互相交谈。这感觉不对,我觉得组件应该只包含他们关心的功能。

API 调用

处理 API 调用可能非常混乱。假设您有一个要在更新后自动保存的表单。但是您知道您的用户通常处于低信号环境中,并且很可能 API 调用失败。因此,您要么实现某种方式来进行离线故障转移,要么创建一种 Saga 风格的模式来撤消用户所做的更改,这是糟糕的用户体验。或者您提供自动保存和批量发布数据并添加保存按钮。

如果我有从 GET 请求中获得的数据,纯粹的信息不需要进入 Redux,并且这些数据在应用程序中的许多不同位置使用,该怎么办?实现数据缓存。您需要更新缓存,因为数据是从数据库中更新的?搞砸了,把数据扔进 Redux,然后添加 Redux-Persist。

即使数据的更新不在当前用户的控制范围内,大量数据的获取和处理通常也会在 Redux 中结束。我更喜欢只存在于 Redux 中的可操作数据,但它可以完成工作。

组件结构和重新渲染

我从来没有真正关心过容器/视图组件模型。我理解它的有效性,如果做得好,您可以将容器组件与 React-Native 和 BAM 一起使用!你是跨平台的。另一方面,我不喜欢用大量的钩子和函数来膨胀我的组件。我喜欢把它抽象成一个自定义的钩子,但是我把它放在哪里呢?它与容器/视图模型有何不同?

组件重新渲染是我经常处理的一个大问题。我真的希望我可以让我的组件只渲染一次所需的所有数据。使用开发工具我没有得到很多答案,因为它只说“道具已更改”。除非我安装“why-did-you-render”并将其添加到我不走运的地方。这是我希望开发模式下的 React 工具能够为我提供所有这些信息的情况之一。

那我该怎么办呢?

好吧,如果我有那根魔杖,我可能最终会得到 Svelte 和 React 之间的交叉。为什么不使用 Svelte?因为我很喜欢 JSX,所以感觉很不错,而且我不是 Svelte 中的车把样式语法的忠实粉丝。

所以详细地说,这是我一直认为的合理解决方案。

JSX 和组件

正如我所说,我喜欢 JSX,但我认为它还远远不够。就我个人而言,我会像这样抽象出所有 HTML 元素: div, span -> Container; p, h1, h2... -> Text 等。我认为这样做的主要好处是您可以提供标准的预样式组件,例如 Flex 和 Center。最重要的是,因为所有元素都是抽象的,您可以切换构建引擎,以便它可以构建到 Web、iOS 或 Android。

虽然我没有考虑太多,但我会采用更自以为是的方式来处理组件样式。我认为目前的情况很好,并且有很多很棒的想法正在使用,但我希望看到一些特定方法的融合。

另一件事,我会取消虚拟 DOM 和不变性。也许我对好处的理解不够,但我觉得有时我遇到了难以诊断的竞争条件,或者状态比较算法会产生过多的开销并真的让应用程序陷入困境。

状态管理

我希望看到某种基于事件的系统,其中组件具有其他组件可以直接与之对话的操作通道。在这些通道中,您可以拥有多个侦听器,因此一个操作可以触发多个其他组件进行更新。这将充当更直接的通信,而不像 Redux 那样将操作传递给每个 reducer 以查看是否匹配。

我不会取消全局与本地状态的想法。在我看来,我认为它在风格上类似于具有公共和私有属性的类属性。这些属性可以是静态的或只读的,它们可以是公共/私有的,这决定了其他组件是否可以读取它们。所以公共属性类似于全局,私有是本地状态。通过这样做,我们可以减少全球范围内的样板文件。

API 调用

我想要一个标准组件来抽象出数据获取中更繁琐的方面。更乏味的东西被称为去抖动/节流、轮询、短期缓存,因此数据可以通过刷新、预取和进度更新来生存。虽然我不想抽象太多,因为用户仍然需要控制授权和其他标头。

现在有一些我认为很酷的东西

我认为如果您可以在将应用程序构建为单页应用程序或多页应用程序之间做出选择,那将是非常棒的。我知道 SPA 有很多好处,并且能够将它们用作渐进式 Web 应用程序。但是,如果您更关心捆绑包大小怎么办?是的,您可以使用 Webpack 拆分捆绑,但我认为 MPA 有好处。

这种多页应用程序样式与您的传统 MPA 略有不同。如果您可以通过 API 调用将服务器端呈现的组件作为字符串或数据结构获取呢?然后,您可以使用该 API 调用与超轻量级渲染器相结合来渲染组件并将其自身附加到事件系统。或者如果事件系统是服务器端的并且前端只有轻量级渲染器怎么办。

这可以让我们更接近于更原生的微前端方法,我认为功能标记或 A/B 测试会更容易处理。

结论

我写这篇文章是为了了解其他人在处理 React 时是否有类似的感觉。归根结底,我仍然喜欢 React。这是一个了不起的框架,每当它有意义时,我都会去尝试它。但我相信我谈到的问题确实阻碍了完美的开发人员体验。

我正在慢慢研究这个框架的整体设计,一旦我取得了更大的进展,我可能会再写一篇文章。但就目前而言,我只是想看看这些想法是否对其他人感兴趣。有人愿意为此工作吗?

不知道,我是不是跑题了?是否有一些我遗漏的明显方面可以使处理这些问题更容易。或者您还有其他需要处理的问题吗?让我知道!