打脸系列
欢迎使用全新虚拟列表解决方案 vv-react-table 🤐
开源地址：vv-react-table
使用文档：文档
前言
在过去的三个月里，我从vue技术栈切换到了react技术栈,并使用react技术栈高质量完成了公司一个大型内部项目。而vv-react-table就是在此项目中沉淀出来的关于虚拟列表列表解决方案。
即便如此，我还是想说 我并不喜欢React
令人发指的 useState
我们知道，在 react-hook中,我们需要使用 useState声明一个响应式变量，如下所示：
const [name,setName] = useState('刘小灰')
调用 setName方法就可以改变 name 的值。
但是由于 React响应式并没有采用 Vue 那一套数据劫持的解决方案，导致每次更新响应式变量时，页面需要重新执行。在不采取任何优化策略情况下，一个响应式变量的改变就会影响到整个组件乃至子组件的更新。
尤其是在大型项目中，React的渲染逻辑会变的扑朔迷离，作为开发者，我们需要时刻小心不必要的渲染、或者不正常的渲染。
个人觉得 React 非直觉 的渲染逻辑，在UI层面会给开发者带来不小的心智负担。我把这种设计称之为不合理设计。
能力不足的 useEffect
这一点有社区 ahooks 来补充，尚且不说。但是单从语法层面，当 useEffect 的第二个参数是一个引用类型时，很容易当代码进入死循环,比如一下代码：
import React, { useEffect, useState } from 'react';
const Demo = () => {
const [count, setCount] = useState<number[]>([]);
const newArr = [4, 5];
useEffect(() => {
setCount((count) => {
return [...count, Math.random()];
});
}, [newArr]);
return <div>我是demo </div>;
};
export default Demo;
更多情况下 newArr 变量是从 props 中传递过来的，所以处理起来变的十分麻烦。
过于灵活的语法
有的人可能会问，语法灵活可扩展性强，难道不好吗？但是在一个项目团队里，尤其是团队成员技术能力参差不齐的时候，你会发现React会在每个人手里各显神通。最后会导致整个项目的代码可读性很差。如果来个新人维护项目话就会带来不小的维护成本及安全隐患。
还有就是，因为太灵活，导致连官网都没有给出写React的最佳实践。
没有统一的技术方法
Create React App 作为唯一一个 React 官方脚手架,显得过于简陋，拿来学习尚可，但作为项目开发，没有给开发者提供一套完整的服务，这就导致我们必须借助第三方框架，比如过于臃肿的 umi 等。
对于初学者，你可能会很纠结选哪个框架去学习？选哪个框架作为状态管理...
为什么大厂都倾向于React
抛开一切，如果现在把 Vue3 和 React放在一起做抉择的话，我想大厂也会很大概率选择 Vue。但现实是有太多的 历史原因。导致他们只能使用React。
总结
当然 React 也有很多优点，比如 Props的设计以及友好的 TS 支持。但从语言的设计层面来讲，React 可能有太多历史包袱，很多东西设计的不符合直觉，需要开发者深入理解。最后倒是觉得 vue3 是 React 的最佳实践。
那么，你觉得呢？欢迎下方留言讨论
补充
在我写补充内容的时候，离这篇文章的发布仅仅过去了一天就收到大家一百四十多条的评论。原来 V R 之争还是如此的激烈。我觉得这是一个好现象，不论谁对谁错，至少评论的人留下了他们对 框架的理解和对技术的思考。我觉得这一点对于一个技术人来说至关重要。
就个人而言，我对 vue（指的是vue3版本） 和 react 的对比很纯粹。就单单看他们的语言设计。我还是喜欢Vue这种符合常理和直觉的设计，更确切的说是中庸的设计，或许是因为我自己就是个中庸的人吧。
喜欢哪个框架是要用哪个框架是两把事。在工作中我也使用 react 去开发项目，使用react造轮子 比如 vv-react-table虚拟列表解决方案。但是没办法，我还是喜欢vue，这种感觉说不清，或者说是一种信仰。
