一个这么小的技巧，提升 React 开发体验，我花了十年才领悟

作为一个资深 React 开发者，长期以来我都因为一个非常小的事情而感到烦恼，那就是，在 JSX 中写三目运算和条件判断

例如这样的代码

{isGis && (
  <>
    <div className='border-b mt-20 mb-8 text-lg font-bold pb-3'></div>
    <Giscus />
  <>
)}

和这样的

{
  auth 
  ? renderArticle(code) 
  : <EnterCode />
}

从开发体验上来说，这并不是一个非常明显的痛点，但是属于是一种隐隐作痛，所以有的时候我会感觉很烦。而且当代码结构变得复杂的时候，写三目运算会让我的代码变得非常难看也不好理解。

但是这样的代码写了很多年，始终都没有掌握到一个很好的办法去解决它。一方面是没有想过要彻底解决，觉得好像勉强可以接受，另外一方面也是没有找到一个好的思路。

直到，我学习了 Solid.js

---

只要学习过 Solid.js 的控制流，就知道解决方案比较简单。因此本文的重点在于跟大家分享一下我的思考过程与心得体会。

---

Solid.js 的 Show 组件

Solid.js 中提供了一个 Show 组件，用于解决条件判断或者三元运算符。它的语法如下

import { Show } from "solid-js";

function Show<T>(props: {
  when: T | undefined | null | false;
  keyed: boolean;
  fallback?: JSX.Element;
  children: JSX.Element | ((item: T) => JSX.Element);
}): () => JSX.Element;

在使用过程中，我们可以这样做

<Show when={state.count > 0} fallback={<div>Loading...</div>}>
  <div>My Content</div>
</Show>

只有我自己知道，当我看到 Solid.js 的这个语法时，我有多激动。一直以来，我都不喜欢在 React 的 JSX 中写 {}，更讨厌写一堆条件判断，但是很多时候不得不写。

看到这个思路之后，我立马在 React 中复刻了一个 Show 组件，代码也非常简单。

export default function Show(props) {
  const {when, fallback = null, children} = props
  return when ? children : fallback
}

有了这个组件之后，开篇那两段代码，就可以改写如下

// 之前
{
  auth 
  ? renderArticle(code) 
  : <EnterCode />
}


// 之后
<Show when={auth} fallback={<EnterCode />}>
  {renderArticle(code)}
</Show>

// 之前
{isGis && (
  <>
    <div className='border-b mt-20 mb-8 text-lg font-bold pb-3'></div>
    <Giscus />
  <>
)}

// 之后
<Show when={isGiscus}>
  <div className='border-b mt-20 mb-8 text-lg font-bold pb-3'></div>
  <Giscus />
</Show>

对我个人而言，开发体验提升了好多。

---

第一个思考

这里一个比较有意思的事情就是，这么简单的一个优化提升，居然困扰了我很多年。他很难吗？一点也不难。但是这么多年的开发过程中，我确实没有想到过。

所以，可以预见的是，有的道友心里面肯定在想，一个这么小的封装，居然也能水一篇文章，然后对此嗤之以鼻。

但是站在我的角度来说，这个技巧非常珍贵，因为它困扰了我很多年才领悟到。我甚至觉得这已经足够作为一个项目亮点，在面试的时候分享给面试官。

当然肯定是有很多人对我的这个想法是不信的。

因为这很简单。 但是我还有另外一个结论：只要是真的彻底掌握了的知识点，在我看来都是简单的。 比如困扰很多人的闭包，并发模式，各种架构思维等等。所以我可以轻松的让我的学生掌握很多困扰他很久的知识。

所以，如果我觉得简单的东西，不能再面试里分享了，那么，我在面试里分享啥？分享我不会的难点吗？

在教学过程中，我发现还有另外一种非常有趣的现象：有的人会因为解决方案过于简单，而自我怀疑：为什么这么简单的东西，我就是想不到。

持有这样想法的人，往往很难在学习过程中，感受到成就感。 很显然，这肯定并不是一个健康的想法。

我突然想到，我看过的一本玄幻小说，里面有这样一句话富含哲理的话。

---

第二个思考

有一些朋友因为我一直写文章吹 React 而对我怨念颇深，所以时不时的就发私信来骚扰我。他们的观点大概是觉得 React 已经过时了，有其他更先进的技术栈为啥不用，非要一直吹 React...

✓

至于为什么发私信，我猜测是因为直接在文章里评论，言辞过于激烈的表达会直接被系统和谐，我根本看不到

所以当我分享这个知识点的时候，有的道友一定会想：这个知识点，在 Vue 的指令系统中，是一个最基础的概念，你看还被博主当成宝。这个博主水平真低...

事实上，长期看我文章的朋友应该知道，其实我并不是一个有明显技术偏好的人，我是一名大前端架构师，因此对市面上大多数前端方案都有所涉猎。就算是 React，我也经常在文章里和付费群里吐槽他的许多不好之处。

例如，我曾经试图寻找如何在 React 中注册全局组件，一些基础组件我不想额外引入。但是这个特性在 Vue 中支持了。于是群里就有人开玩笑说我带头叛变...

事实上，我选择持续深入 React 的学习与使用，除了我确确实实感受到了 React 在设计理念的优秀之处之外，还因为他确实有其他框架无可匹敌的生态系统。当然最最重要的原因是，专注 React 在职场里的薪资收益大概率会更高。

✓

注意看，我说的是大概率，不是绝对...

另外一个点，如果你想要逃脱国内这个高度内卷的环境而考虑出海、国内外企、或者寻求一份远程工作的话，React 更是不二选择。

很多人往往会有比较极端思维，认为我吹 React 好的地方，就表示我感受不到 React 坑的地方...

就正如，我吐槽 Vue 坑的地方，很多人就以为我不懂 Vue 好的地方。

我其实非常不理解这种极端思维为什么会如此盛行

之前其实我有认真思考过指令系统的运用。因为我最开始用的是 angular 1.x，因此对指令系统非常熟悉。但是由于自定义组件的存在，我一直都觉得自定义指令的运用实际上一直处于一个可有可无的状态。

由于在鸿蒙原生应用开发中，第一次接触了完整的容器组件理念之后，我的架构理念就发生了一些变化，因此，我又重新审视了指令系统这种为单元素标签赋能的方式。

我可以自定义一些全局指令，不需要 import，然后还能支持完整的容器能力。但是认真思考过之后，还是发现不合适。因为逻辑和样式 无法通过自定义指令统一成一个完整的整体。自定义指令仍然只适合运用于单元素、纯逻辑的封装，所以想来想去，感觉它的适用场景，确实太少了。所以最后也就不了了之。

但确实很无语的是，我没有从指令系统中，得到灵感来解决我的这个问题。

<h1 v-if="awesome">Vue is awesome!</h1>

不过我还是要狡辩一下。

同样是针对单元素的逻辑操作，和自定义指令不同的是，容器组件是一种包含了明确语义的定义方式。

<Show></Show>

我们可以很自然的知道，这可以是一个逻辑容器，也可以是一个布局容器。我们不需要花费太多的心思去区别他们的。

但是自定义指令必须依附于具体的元素标签，他是从给元素赋能的角度来定位自身的。而不是从容器组件的角度来定位自身的。

因此，虽然我们在得到了结果的角度去思考，很容易能够看到 Show 组件与 v-if / v-show 有明显的相似之处，但是他们思考的出发点是完全不同的。这种不同的出发点导致了思考问题的角度和结果会差别很大

例如，在学习之初，我们需要花额外的精力去辨别，多个指令共用于同一个元素，会产生什么样的结果。有的可能是变得更好，但是有的指令可能会出现意想不到的问题

但是从容器组件的角度考虑，就非常的纯粹，我们不需要担心给一个组件套两个容器会发生什么事情，只需要考虑封装的应用场景是否准确即可。

---

关于技术是否过时

有朋友常常会担心自己用的技术已经过时了。所以对于新技术很焦虑。

我的观点是，想办法把一个技术用好用深，是比老想着用一个新技术更靠谱的选择。

虽然我经常会学习新出的技术，但是我学习他们的目的很多时候并不是真的要在项目里去使用他们，更多的是去借鉴他们的一些优秀的开发思维，然后再研究研究是否能用到自己的项目中来。例如，我从鸿蒙开发中全面借鉴了容器组件的理念，从 Solid.js 中借鉴了条件判断组件，从 Vue 中借鉴了全局组件思路等等，然后把这些想法运用在了 React 中...

✓

这里也解释了为什么我要学习 React 19，这个阶段他太新了，很多人会担心就算学了也用不了，为啥要学习呢。因为有的时候，学了，并不一定是为了用他。

所以我感受到的 React 和其他人感受到的 React 可能完全不一样。因此我并不是很想反复的去探讨到底哪一个框架更好或者说更差，我更多的是思考如何取长补短。

我虽然我更多的在使用 React，但我同样有极强的自信，能够把 Vue3 用到大多数人都达不到水平。

另外一个案例就是，我有一个学生因为工作原因，不得不长期使用 jQuery，所以他非常的焦虑，觉得自己已经完全与时代脱节了，什么 Vue React 用都没用过，所以找到我学习。

可是我了解之后发现，他对 jQuery 的使用水平确实已经非常高了。所以我推荐他可以关注一下这方面的机会，说不定有意外的惊喜。好巧不巧，真的有这样一个机会，被他给逮到了。

然后在几个月之前他找到了一份国企的高薪工作，就是继续写 jQuery。然后进去之后他发现，那家企业因为有几个项目是用 jQuery 写的，但是长期苦于找不到一个合适的人来接手。所以不得不提高薪资待遇。

然后我在写这篇文章的时候，特意去 boss 直聘上翻了一下，依然发现了一个岗位，只要求 JQuery，还能给到 30K 的工作

所以，我们为什么要因为技术过时而感到极度的焦虑呢？

况且，到目前为止，React 依然保持了最强的活力，拥有最强的生态系统，远远还没达到有的人口中所谓的过时的地步。

另外一个角度就是，只要用好了其中一门技术，其实切换到另外的技术栈也花不了多长时间就能达到一个很高的水平。

所以我觉得，就算是要焦虑，那焦虑的原因至少也应该是，我用的这个技术栈，我还没有用好它。