@@ -17,10 +17,8 @@ cases the :ref:`Basic Hooks` should be enough, however the remaining
17
17
Basic Hooks
18
18
===========
19
19
20
- Common hooks that should fulfill a majority of use cases.
21
20
22
-
23
- use_state
21
+ Use State
24
22
---------
25
23
26
24
.. code-block ::
@@ -45,8 +43,8 @@ of ``new_state``.
45
43
.. note ::
46
44
47
45
The identity of ``set_state `` is guaranteed to be preserved across renders. This
48
- means it can safely be omitted from dependency lists in :ref: `use_effect ` or
49
- :ref: `use_callback `.
46
+ means it can safely be omitted from dependency lists in :ref: `Use Effect ` or
47
+ :ref: `Use Callback `.
50
48
51
49
52
50
Functional Updates
@@ -92,7 +90,7 @@ result in a re-render:
92
90
set_state(state)
93
91
94
92
95
- use_effect
93
+ Use Effect
96
94
----------
97
95
98
96
.. code-block ::
@@ -186,18 +184,15 @@ There are **three important subtleties** to note about using asynchronous effect
186
184
Supplementary Hooks
187
185
===================
188
186
189
- Hooks that fulfill some less common, but still important use cases using variations of
190
- the :ref: `Basic Hooks `.
191
-
192
187
193
- use_reducer
188
+ Use Reducer
194
189
-----------
195
190
196
191
.. code-block ::
197
192
198
193
state, dispatch_action = use_reducer(reducer, initial_state)
199
194
200
- An alternative and derivative of :ref: `use_state ` the ``use_reducer `` hook, instead of
195
+ An alternative and derivative of :ref: `Use State ` the ``use_reducer `` hook, instead of
201
196
directly assigning a new state, allows you to specify an action which will transition
202
197
the previous state into the next state. This transition is defined by a reducer function
203
198
of the form ``(current_state, action) -> new_state ``. The ``use_reducer `` hook then
@@ -218,17 +213,17 @@ We can rework the :ref:`Functional Updates` counter example to use ``use_reducer
218
213
219
214
The identity of the ``dispatch_action `` function is guaranteed to be preserved
220
215
across re-renders throughout the lifetime of the component. This means it can safely
221
- be omitted from dependency lists in :ref: `use_effect ` or :ref: `use_callback `.
216
+ be omitted from dependency lists in :ref: `Use Effect ` or :ref: `Use Callback `.
222
217
223
218
224
- use_callback
219
+ Use Callback
225
220
------------
226
221
227
222
.. code-block ::
228
223
229
224
memoized_callback = use_callback(lambda: do_something(a, b), [a, b])
230
225
231
- A derivative of :ref: `use_memo `, the ``use_callback `` hook returns a
226
+ A derivative of :ref: `Use Memo `, the ``use_callback `` hook returns a
232
227
`memoized <memoization >`_ callback. This is useful when passing callbacks to child
233
228
components which check reference equality to prevent unnecessary renders. The of
234
229
``memoized_callback `` will only change when the given dependencies do.
@@ -243,7 +238,7 @@ components which check reference equality to prevent unnecessary renders. The of
243
238
244
239
245
240
246
- use_memo
241
+ Use Memo
247
242
--------
248
243
249
244
.. code-block ::
@@ -277,7 +272,7 @@ after) and should not incur side effects.
277
272
to help enforce this.
278
273
279
274
280
- use_ref
275
+ Use Ref
281
276
-------
282
277
283
278
.. code-block ::
@@ -290,7 +285,7 @@ The identity of the ``Ref`` object will be preserved for the lifetime of the com
290
285
291
286
A ``Ref `` is most useful if you need to incur side effects since updating its
292
287
``.current `` attribute doesn't trigger a re-render of the component. You'll often use this
293
- hook alongside :ref: `use_effect ` or in response to component event handlers.
288
+ hook alongside :ref: `Use Effect ` or in response to component event handlers.
294
289
:ref: `The Game Snake ` provides a good use case for ``use_ref ``.
295
290
296
291
0 commit comments