短信预约-IT技能 免费直播动态提醒
喔！React19 中的 Hook 可以写在 If 条件判断中了。Use 实践：点击按钮更新数据
接下来，我们将会以大量的实践案例来展开 React 19 新 hook 的运用。
本文模拟的实践案例为点击按钮更新数据。这在开发中是一个非常常见的场景。
案例完成之后的最终演示效果图如下：
我们直接用 React 19 新的开发方式来完成这个需求。
一、基础实现
首先创建一个方法用于请求数据。
const getApi = async () => {
const res = await fetch('https://api.chucknorris.io/jokes/random')
return res.json()
}
这里一个非常关键的地方就在于，当我们要更新的数据时，我们不再需要设计一个 loading 状态去记录数据是否正在发生请求行为，因为 Suspense 帮助我们解决了 Loading 组件的显示问题。
与此同时，use() 又帮助我们解决了数据获取的问题。那么问题就来了，这个就是，好像我们也不需要设计一个状态去存储数据。那么应该怎么办呢？
这里有一个非常巧妙的方式，就是把创建的 promise 作为状态值来触发组件的重新执行。每次点击，我们都需要创建新的 promise
代码如下：
// 记住这个初始值
const [api, setApi] = useState(null)
这个时候，当我们点击事件执行时，则只需要执行如下代码去触发组件的更新。
function __clickToGetMessage() {
// 每次点击，都会创建新的 promise
setApi(getApi())
}
getApi() 执行，新的请求会发生。他的执行结果，又返回了一个新的 promise。
因此，点击之后会创建的新 promise 值，api 此时就会作为状态更改触发组件的更新。
完整代码如下：
export default function Index() {
const [api, setApi] = useState(null)
function __clickToGetMessage() {
setApi(getApi())
}
return (
点击按钮获取一条新的数据
loading...
}>
)
}
const Item = (props) => {
if (!props.api) {
return
nothing
}
const joke = use(props.api)
return (
{joke.value}
)
}
案例写完之后。我们基本上就能够实现最开始截图中的交互效果了。但是现别急，还没有完。我们还需要进一步分析一下这个案例。
二、案例分析
这里我们需要注意观察两个事情。
一个是观察当前组件更新，更上层的父组件是否发生了变化。我们可以在 App 组件中执行一次打印。
此时可以发现，当我们重新请求时，当前组件更新，但是上层组件并不会重新执行。
我们可以出得结论：更简洁的状态设计，有利于命中 React 默认的性能优化规则。
具体的规则请在 React 知命境合集中查看。
更简洁的状态设计，也是 React 19 所倡导的开发思路。
另外一个事情，是我们要特别特别注意观察子组件 Item 的实现。
首先因为我们初始化时，给 api 赋予的默认值是 null。
// 记住这个初始值
const [api, setApi] = useState(null)
之后，我们就将 api 传给了子组件 Item。
然后在 Item 组件的内部实现中，因为我们直接把 api 传给了 use，那么此时直接执行肯定会报错。
const joke = use(props.api)
要注意的是，我们刚才说，使用 Suspense 会捕获子组件的异常，但是不是捕获所有异常，它只能识别 promise 的异常。因此，这里的报错会直接影响到整个页面。
所以，为了处理好初始化时传入 api 值为 null，我在内部实现代码逻辑中，使用了 if 判断该条件，然后执行了一次 return。我试图让 use(null) 得不到执行的时机。
const Item = (props) => {
if (!props.api) {
console.log('初始化时，api == null')
return nothing
}
const joke = use(props.api)
return (
{joke.value}
)
}
那么，我的意图是否能成功呢？
我们在 return 后面插入一个 console.log 来观察代码的执行情况，代码如下：
const Item = (props) => {
if (!props.api) {
console.log('初始化时，api == null')
return nothing
}
console.log('初始化时这里是否执行');
const joke = use(props.api)
return (
{joke.value}
)
}
演示效果如下图所示：
我们发现，当我反复刷新页面，让初始化流程执行时，return 后面的代码并不会执行。
再然后，我们新增一点内容，比如在 return 后面使用一个 useEffect。
const Item = (props) => {
if (!props.api) {
console.log('初始化时，api == null')
return nothing
}
useEffect(() => {
console.log('xxx')
}, [])
console.log('初始化时这里是否执行')
const joke = use(props.api)
return (
{joke.value}
)
}
然后演示再看看。我们发现 effect 也不会执行。然后我们还可以搞点好玩的。
Item 代码改造如下：
const Item = (props) => {
if (!props.api) {
const [count, setCount] = useState(0)
console.log('初始化时，api == null')
return setCount(count + 1)}>nothing, {count}
}
console.log('初始化时这里是否执行')
const joke = use(props.api)
return (
{joke.value}
)
}
注意看，我们在 if 条件判断中，单独创建了一个 useState，并在对应的元素上添加了一个让 count 递增的交互。
这段在之前版本的开发中一定会触发语法错误提示的代码。
最终也是能勉强运行，但是代码会疯狂报错。
代码演示结果如下：
然后，我继续一个骚操作，我在 if 中条件判断中，使用 useEffect，代码如下：
const Item = (props) => {
if (!props.api) {
useEffect(() => {
console.log('useEffect 在 if 中执行')
}, [])
return nothing
}
console.log('初始化时这里是否执行')
const joke = use(props.api)
return (
{joke.value}
)
}
也能正常执行。观察一下演示效果：
结论：
很明显，react 19 的 hook 在底层发生了一些优化更新，我们可以不用非得把所有的 hook 都放在函数组件的最前面去执行了。
在 React 19 中，我们可以把 hook 放到 return 之后，也可以放到条件判断中去执行。
但是，我们一定要注意的是，并非表示我们可以随便乱写。当条件互斥时，状态之间如果存在不合理的耦合关系，依然不能正常执行。我们列举两个案例来观察这个事情。
第一个案例，我们依然在 if 中执行一个 useEffect，但是不同的是，我把在 if 之外的状态 counter 作为依赖项传入。
代码如下。
const Item = (props) => {
const [counter, setCounter] = useState(0)
if (!props.api) {
useEffect(() => {
console.log('useEffect 在 if 中执行')
}, [counter])
return nothing
}
console.log('初始化时这里是否执行')
const joke = use(props.api)
return (
setCounter(counter + 1)}>{joke.value}
)
}
此时一个很明显的问题就是，if 内部在 UI 逻辑上本和外部是互斥的关系，但是我们在状态逻辑上却相互关联。因此这个之后，代码执行就会报错，明确的告诉你这种写法不合理。
第二个案例。我在条件判断中，定义了一个状态 bar，但是我并没有在 if 中 return，而是继续往后执行。代码如下：
const [counter, setCounter] = useState(0)
if (counter == 0) {
const [bar, setBar] = useState('bar')
console.log('bar', bar)
}
const [foo, setFoo] = useState('foo')
console.log('foo', foo)
return (
)
这个现象的解释就是我们之前在面试时经常会聊的一个话题：为什么不能将 hook 放在条件判断中去执行。
由于在 fiber 中，是通过有序链表的方式来存储 hook 的值。因此，当随着 counter 递增，条件判断中的 hook 不再执行，但是它的值已经被缓存上了，后续的执行中，foo 就变成了第 1 个 hook，从而导致 foo 获取到了 bar 的值。
好在 react 19 对这种情况做出了明确的判断，当你这样写时，代码会明确报错终止程序的运行。所以在开发过程中我们也不用特别去区分什么情况下不能用。
三、需求变动
现在我们做一点小小的需求变动。
在之前的案例实现中，组件代码初始化时，并没有初始化请求一条数据。因此，默认渲染结果是 nothing。
此时，我们如果希望组件首次渲染时，就一定要请求一次接口，我们的代码应该怎么改呢？
在以前版本的实现中，接口数据的触发方式不同，因此我们需要分别处理这两种触发时机。
初始化时的数据请求，我们利用 useEffect 来实现。
function PreIndex() {
const [data, setData] = useState({value: ''})
const [loading, setLoading] = useState(true)
useEffect(() => {
api().then(res => {
setData(res)
setLoading(false)
})
}, [])
}
按钮点击事件触发时，我们通过回调函数来实现。
function PreIndex() {
const [data, setData] = useState({value: ''})
const [loading, setLoading] = useState(true)
useEffect(() => {
api().then(res => {
setData(res)
setLoading(false)
})
}, [])
function _clickHandler() {
setLoading(true)
api().then(res => {
setData(res)
setLoading(false)
})
}
...
}
然而，在新的开发方式中，我们只需要在上面的案例做一个非常小的变动，那就是把 api 的参数使用 getApi() 去初始化，而不是 null，就可以做到了。
// 只需要改这一点代码
const [api, setApi] = useState(getApi())
改完之后，演示效果如下：
非常的方便省事。
当然这样写会造成冗余的接口请求执行。因此我们可以稍作调整就可以了。
这里需要根据需求调整，案例只做演示。
const _initApi = getApi()
function Index() {
const [api, setApi] = useState(_initApi)
...
}
OK，今天的案例就介绍到这里，后续的章节我们还会继续更多的实战案例的分析。
免责声明：
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
