Get best of the week

不再需要Redux Toolkit吗？

每个人都知道使用Redux时需要大量样板代码的问题，每个人都尽力解决。而且我们在不同的项目中使用了不同的拐杖和脚踏车，同时又不失希望找到标准化和方便的东西。一年多以前，我们对搜索感到失望，并认真解决了该问题的解决方案。其结果描述如下。

外观故事


我们公司正在为全球的初创公司开发项目。对于这些受到疯狂启发的人，最重要的（或其中之一）就是时间。以前进入市场-生存的机会更高。因此，我们总是尝试在不牺牲质量的情况下减少开发时间，并减少人为因素导致的错误数量。在大多数情况下，我们选择标准的或多或少稳定的东西。在这种情况下，什么都找不到，所以他们卷起袖子，开始看到这里可以循环的东西。



像往常一样，我们从问题描述开始，得到以下信息：

  • 每个开发人员在编写代码时都有自己的微妙口音，很难实现“去个性化代码”的概念；
  • 很多代码（样板代码，复制粘贴和所有随之而来的问题），在CRUD上有100多个代码行；
  • 很多时间花在编写基本的东西上。您会忘记一件事，另一件事是：设置加载，处理错误等。
  • 商店的结构因项目而异，有时在项目的不同部分之间也不同。

正确回答的问题或提出的问题是解决方案的一半。经过一番思考，我们介绍了存储库的组成规则，描述了存储库的结构，并决定对代码进行重构和梳理。尽管我们的代码库不是非常庞大，但我们立即发现需要更改的代码量。

当PM困惑于一天中要增加几个小时的时间时，有一些爱好者产生并实现了一个简单的想法，以至平庸。是的，巧妙的想法在出现之后总是很简单。想法是这样的：只需生成单独的代码段，而不是手动重写代码即可。我不想使用摘要并在出口处获取工作表，因为任何更改都会导致灾难和重复的重构，因此很快就发现了一个将某些参数作为输入并构建了reducer，action和saga的函数。因此，通信的第一个版本诞生了（@ axmit / redux-communications） “通信”这个名称本身就以某种方式诞生，因为该库将Sagas和组件联系在一起。事情就这样过去了……

之后，幸福就来了。好吧，或者几乎马上。开发时间减少了约20％（根据我们的计算，这是另一篇文章的主题）。首先，由于爬虫的数量大大减少。更不用说开发人员因注意力不集中而犯愚蠢错误的事实了。



莱纳斯·托瓦尔兹（Linus Torvalds）曾说：““不值钱。给我看代码。“我完全同意他的看法。我不会在此处引用或重写扩展坞，也不会在此处提供代码表。我只举一个小例子。在文章的末尾也可以找到指向该库的完整描述和一个带有示例的沙箱的链接。

考虑一个典型的任务-我们需要为某个实体创建CRUD。以任务为例。我认为没有必要描述标准版本，因为 它将占用大量空间，并且遇到编辑器的每个人都可能会大致想象它的外观。为了获得交流，您需要执行以下操作：

1.描述运输方式，不带任何地方

const basePath = `/api/task`;

const taskTransport = {
   add: task => axios.post(`basePath`, task).then(r => r.data),
   get: id => axios.get(`${basePath}/${id}`).then(r => r.data),
   update: task => axios.put(`${basePath}/${task.id}`, task).then(r => r.data),
   delete: id => axios.delete(`${basePath}/${id}`, task),
   getCollection: () => axios.get(basePath).then(r => r.data)
};

2.描述名称空间
const namespace = 'task';

3.制定沟通策略
const strategy = new CRUDStrategy({
   namespace,
   transport: taskTransport
});

4.建立沟通
const taskCommunication = buildCommunication(strategy);

5.像往常一样，通过通信连接异径管和尾气
taskCommunication.reducers
taskCommunication.sagas

6.之后，仍然需要将侧面连接到组件
taskCommunication.injector(MyComponent)

7.并开始使用
componentDidMount() {
   const { getTaskCollection } = this.props;
   getTaskCollection();
}

render() {
   const { taskCollection } = this.props;
   return  taskCollection.data.map(item => <span>{item.title}</span>)
}

实际上，无论如何都需要创建传输和组件，并且完整的通信代码如下：

import { taskTransport } from './task.transport';
import { CRUDStrategy, buildCommunication, StoreBranch } from '@axmit/redux-communications';
 
const namespace = 'task';
 
const strategy = new CRUDStrategy({
   namespace,
   transport: taskTransport
});
 
export const taskCommunication = buildCommunication(strategy);


这是拥有完整功能的CRUD所需要做的一切。如果您需要做一些更复杂的事情，则可以扩展CRUD通信或使用BaseCommunication。在极端情况下，它仍然是具有所有功能的老式老式编辑器。灵活性没有受到影响。传输位于单独的层中，其实现可以是任何东西。我们在项目上使用了graphQL，并使用axios进行了简单的查询，在这方面我们没有遇到任何困难。细心的读者可能已经注意到图书馆出口了萨加斯酒，这是其最重要的局限之一。如果由于某种原因您不能使用sagas，那么很遗憾，此库不适合您。

为什么现在？


阅读这篇文章后，才决定写一篇文章。戳这个工具，我很惊讶地发现通信更加简单，简洁，给商店提供了更清晰的结构，同时灵活性也不差。在将示例的源代码整理到redux-toolkit并花了一个小时之后，我将其重写以进行通信。尽管我认为示例的结构非常混乱，但我试图对更改进行最小化以使其更容易跟踪差异。我特别在代码上留下了注释，以使其更易于比较它的外观和变成方式。请注意* .communication.ts文件和它们替换的切片。



行数要少得多，代码本身看起来更令人愉悦（主观），这一事实并不是那么重要，因为 在产品方面，我们的沟通非常繁琐。还有一个重要的区别。该代码是声明性的。我们只需确定要获取的数据和位置以及如何处理数据以及如何处理数据-我们根本不在乎。
结论- 应该使用redux-toolkit 进行自定义，对于其他所有内容，都可以使用MasterCa ... @ axmit / redux-communications。

总结一下


  • 该代码已在所有项目中以及与所有开发人员保持一致。相似的问题得到统一解决，解决方案通常以单独的软件包提供，并在将来重用。同时，代码量已大大减少。
  • 6月收到清晰易懂的流量。
  • 老年人为他们不必编写大量的样板代码而感到高兴，并正在考虑如何进一步改善沟通。
  • 调试得以简化，并且商店的结构变得简单，并且公司中的每个开发人员都可以理解。
  • 项目或系统不同部分之间的过渡不会引起麻烦。
  • 下午也很开心。错误的数量减少了-客户感到满意。编写变得更容易-开发人员感到高兴。PM还要幸福吗？
  • 您可以逐步进行通信，甚至可以使用混合方法（通信+分片）。

当然，图书馆也有弊端。

  • 没有示例代码和文档，很难理解。
  • 随意更改商店的结构将不起作用，因为 所有自动化都基于商店的结构。但值得注意的是，在我们的工作中，我们从未遇到过任何困难。
  • 您只能使用sagas。Thunk不适合我们，我们总是使用sagas，因此这对我们来说不是问题。但是，如果由于某种原因sagas不适合您，那么您将无法使用该库。

我希望，尽管存在缺陷，但我们的图书馆对某人有用。如果您有任何改进建议或使用疑问，请写信，我将很高兴进行讨论。
如果有我们找不到的更酷的类似物-让我知道，我们一定会研究它们的！

可以在这里找到对该库的完整描述，并在此处在线戳戳。

为了从ReduxToolkit扩展坞进行通信而重写的示例的完整代码在此处，但是您可以在此处戳一下。

More articles:


All Articles