无状态去哪了(无状态组件到底好在哪里？该如何权衡选择？)

无状态去哪了(无状态组件到底好在哪里？该如何权衡选择？)，哪吒游戏网给大家带来详细的无状态去哪了(无状态组件到底好在哪里？该如何权衡选择？)介绍，大家可以阅读一下，希望这篇无状态去哪了(无状态组件到底好在哪里？该如何权衡选择？)可以给你带来参考价值。

我从今年 8 月份开始接手两个项目，项目均是使用 meteor+react。项目中组件的统一风格都是无状态组件。随后因为为了要契合项目编码风格，我也统一全部使用无状态组件。

经过几个月的开发，也做了几个新项目。其中发现挺多问题的，希望 V 友 帮我解惑，说说你们的看法。

1、经常会发现一个组件要传递 7-8 个状态，再加 5-6 个 action，特别是类似 form 表单的这种组件，这样组件入口要传递十几个参数+状态+数据，不但代码难看无状态去哪了，而且容易出错和混淆。另外给这些状态命名也是让人头疼的事情。

2、为了管理状态必须或可能会用到 redux、reactive-dict 等类似状态管理的功能，一个 form 组件 7-8 个状态无状态去哪了，多几个 form 组件全局状态可能就会有几十个。redux 还好，像 reactive-dict 这种没有结构的状态管理经常会发现有状态名冲突的情况，甚至有时候为了给状态起个名字要想半天。

3、状态因为不在组件内部，生命周期是从创建一直存在的，很多初始化工作要做在无状态组件的外面，避免我们在给无状态组件传递某个状态的时候有默认值或者上一次用过的状态信息。这样一来一个状态要初始化、要赋值、要销毁，且三个动作有可能不在同一个组件中完成，出错几率非常大。

4、action 和组件分离，写代码的时候文件切换来切换去的，非常麻烦。

为什么一直推崇无状态组件，他给开发到底带来了什么便捷，从哪个角度看优势显而易见？我以上说的算是缺点吗？如果不是如何避免呢？是否有更好的实现？

总结：以上内容就是针对无状态去哪了(无状态组件到底好在哪里？该如何权衡选择？)详细阐释，如果您觉得有更好的建议可以提供给哪吒游戏网小编，无状态去哪了(无状态组件到底好在哪里？该如何权衡选择？)部分内容转载自互联网，有帮助可以收藏一下。