└── README.md


/README.md:
--------------------------------------------------------------------------------
  1 | # React pitfalls v18.2.0
  2 | Collection of react pitfalls as described in react documentation
  3 | 
  4 | ---
  5 | <br>
  6 | 
  7 | ## Describing the UI
  8 | 
  9 | <br>
 10 | 
 11 | ## 1 - capitalize component name
 12 | React components are regular JavaScript functions, but their names must start with a capital letter or they won’t work!
 13 | 
 14 | *source: https://react.dev/learn/your-first-component#step-2-define-the-function*
 15 | 
 16 | <br>
 17 | 
 18 | ## 2 - parentheses after return
 19 | 
 20 | Without parentheses, any code on the lines after return [will be ignored](https://stackoverflow.com/questions/2846283/what-are-the-rules-for-javascripts-automatic-semicolon-insertion-asi)!
 21 | 
 22 | ```javascript
 23 | return (
 24 |   <div>
 25 |     <img src="https://i.imgur.com/MK3eW3As.jpg" alt="Katherine Johnson" />
 26 |   </div>
 27 | );
 28 | ```
 29 | 
 30 | *source: https://react.dev/learn/your-first-component#step-3-add-markup*
 31 | 
 32 | <br>
 33 | 
 34 | ## 3 - don't nest component definitions
 35 | 
 36 | Components can render other components, but **you must never nest their definitions**:
 37 | 
 38 | ```javascript
 39 | export default function Gallery() {
 40 |   // 🔴 Never define a component inside another component!
 41 |   function Profile() {
 42 |     // ...
 43 |   }
 44 |   // ...
 45 | }
 46 | ```
 47 | 
 48 | The snippet above is [very slow and causes bugs](https://react.dev/learn/preserving-and-resetting-state#different-components-at-the-same-position-reset-state). Instead, define every component at the top level:
 49 | 
 50 | ```javascript
 51 | export default function Gallery() {
 52 |   // ...
 53 | }
 54 | 
 55 | // ✅ Declare components at the top level
 56 | function Profile() {
 57 |   // ...
 58 | }
 59 | ```
 60 | 
 61 | When a child component needs some data from a parent, [pass it by props](https://react.dev/learn/passing-props-to-a-component) instead of nesting definitions.
 62 | 
 63 | *source: https://react.dev/learn/your-first-component#nesting-and-organizing-components*
 64 | 
 65 | <br>
 66 | 
 67 | 
 68 | 
 69 | 
 70 | ## 4 - *aria-** and *data-** keep their dash
 71 | 
 72 | For historical reasons, [aria-*](https://developer.mozilla.org/docs/Web/Accessibility/ARIA) and [data-*](https://developer.mozilla.org/docs/Learn/HTML/Howto/Use_data_attributes) attributes are written as in HTML with dashes.
 73 | 
 74 | *source: https://react.dev/learn/writing-markup-with-jsx#3-camelcase-salls-most-of-the-things*
 75 | 
 76 | <br>
 77 | 
 78 | 
 79 | ## 5 - camel case for style properties
 80 | 
 81 | Inline `style` properties are written in camelCase. For example, HTML `<ul style="background-color: black">` would be written as `<ul style={{ backgroundColor: 'black' }}>` in your component.
 82 | 
 83 | *source: https://react.dev/learn/javascript-in-jsx-with-curly-braces#using-double-curlies-css-and-other-objects-in-jsx*
 84 | 
 85 | <br>
 86 | 
 87 | 
 88 | ## 6 - curly braces in props destructuring
 89 | 
 90 | **Don’t miss the pair of `{` and `}` curlies** inside of `(` and `)` when declaring props:
 91 | 
 92 | ```javascript
 93 | function Avatar({ person, size }) {  // ...}
 94 | ```
 95 | 
 96 | This syntax is called [“destructuring”](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Unpacking_fields_from_objects_passed_as_a_function_parameter) and is equivalent to reading properties from a function parameter:
 97 | 
 98 | ```javascript
 99 | function Avatar(props) {
100 |   let person = props.person;
101 |   let size = props.size;
102 |   // ...}
103 | ```
104 | 
105 | *source: https://react.dev/learn/passing-props-to-a-component#step-2-read-props-inside-the-child-component*
106 | 
107 | <br>
108 | 
109 | ## 7 - no numbers after `&&`
110 | 
111 | **Don’t put numbers on the left side of `&&`.**
112 | 
113 | To test the condition, JavaScript converts the left side to a boolean automatically. However, if the left side is `0`, then the whole expression gets that value (`0`), and React will happily render `0` rather than nothing.
114 | 
115 | For example, a common mistake is to write code like `messageCount && <p>New messages</p>`. It’s easy to assume that it renders nothing when `messageCount` is `0`, but it really renders the `0` itself!
116 | 
117 | To fix it, make the left side a boolean: `messageCount > 0 && <p>New messages</p>`.
118 | 
119 | *source: https://react.dev/learn/conditional-rendering#logical-and-operator-*
120 | 
121 | <br>
122 | 
123 | 
124 | ## 8 - explicit return in arrow functions
125 | 
126 | Arrow functions implicitly return the expression right after `=>`, so you didn’t need a `return` statement:
127 | 
128 | ```javascript
129 | const listItems = chemists.map(person =>
130 |   <li>...</li> // Implicit return!
131 | );
132 | ```
133 | 
134 | However, **you must write `return` explicitly if your `=>` is followed by a `{` curly brace!**
135 | 
136 | ```javascript
137 | const listItems = chemists.map(person => { // Curly brace
138 |   return <li>...</li>;
139 | });
140 | ```
141 | 
142 | Arrow functions containing `=> {` are said to have a [“block body”.](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#function_body) They let you write more than a single line of code, but you _have to_ write a `return` statement yourself. If you forget it, nothing gets returned!
143 | 
144 | *source: https://react.dev/learn/rendering-lists#filtering-arrays-of-items*
145 | 
146 | <br>
147 | 
148 | 
149 | ## 9 - don't use array's item index and random numbers as keys
150 | 
151 | You might be tempted to use an item’s index in the array as its key. In fact, that’s what React will use if you don’t specify a `key` at all. But the order in which you render items will change over time if an item is inserted, deleted, or if the array gets reordered. Index as a key often leads to subtle and confusing bugs.
152 | 
153 | Similarly, do not generate keys on the fly, e.g. with `key={Math.random()}`. This will cause keys to never match up between renders, leading to all your components and DOM being recreated every time. Not only is this slow, but it will also lose any user input inside the list items. Instead, use a stable ID based on the data.
154 | 
155 | Note that your components won’t receive `key` as a prop. It’s only used as a hint by React itself. If your component needs an ID, you have to pass it as a separate prop: `<Profile key={id} userId={id} />`.
156 | 
157 | *source: https://react.dev/learn/rendering-lists#why-does-react-need-keys*
158 | 
159 | ---
160 | 
161 | <br>
162 | 
163 | ## Adding Interactivity
164 | 
165 | <br>
166 | 
167 | ## 10 - pass a function, not call a function
168 | 
169 | Functions passed to event handlers must be passed, not called. For example:
170 | 
171 | | passing a function (correct) | calling a function (incorrect) |
172 | | --- | --- |
173 | | `<button onClick={handleClick}>` | `<button onClick={handleClick()}>` |
174 | 
175 | The difference is subtle. In the first example, the `handleClick` function is passed as an `onClick` event handler. This tells React to remember it and only call your function when the user clicks the button.
176 | 
177 | In the second example, the `()` at the end of `handleClick()` fires the function _immediately_ during [rendering](https://react.dev/learn/render-and-commit), without any clicks. This is because JavaScript inside the [JSX `{` and `}`](https://react.dev/learn/javascript-in-jsx-with-curly-braces) executes right away.
178 | 
179 | When you write code inline, the same pitfall presents itself in a different way:
180 | 
181 | | passing a function (correct) | calling a function (incorrect) |
182 | | --- | --- |
183 | | `<button onClick={() => alert('...')}>` | `<button onClick={alert('...')}>` |
184 | 
185 | Passing inline code like this won’t fire on click—it fires every time the component renders:
186 | 
187 | ```javascript
188 | // This alert fires when the component renders, not when clicked!
189 | <button onClick={alert('You clicked me!')}>
190 | ```
191 | 
192 | If you want to define your event handler inline, wrap it in an anonymous function like so:
193 | 
194 | ```javascript
195 | <button onClick={() => alert('You clicked me!')}>
196 | ```
197 | 
198 | Rather than executing the code inside with every render, this creates a function to be called later.
199 | 
200 | In both cases, what you want to pass is a function:
201 | 
202 | - `<button onClick={handleClick}>` passes the `handleClick` function.
203 | - `<button onClick={() => alert('...')}>` passes the `() => alert('...')` function.
204 | 
205 | [Read more about arrow functions.](https://javascript.info/arrow-functions-basics)
206 | 
207 | *source: https://react.dev/learn/responding-to-events#adding-event-handlers*
208 | 
209 | <br>
210 | 
211 | ## 11 - events propagation
212 | 
213 | All events propagate in React except `onScroll`, which only works on the JSX tag you attach it to.
214 | 
215 | *source: https://react.dev/learn/responding-to-events#event-propagation*
216 | 
217 | <br>
218 | 
219 | ## 12 - call hooks only at top level of component
220 | 
221 | **Hooks—functions starting with `use`—can only be called at the top level of your components or [your own Hooks.](https://react.dev/learn/reusing-logic-with-custom-hooks)** You can’t call Hooks inside conditions, loops, or other nested functions. Hooks are functions, but it’s helpful to think of them as unconditional declarations about your component’s needs. You “use” React features at the top of your component similar to how you “import” modules at the top of your file.
222 | 
223 | *source: https://react.dev/learn/state-a-components-memory#meet-your-first-hook*
224 | 
225 | <br>
226 | 
227 | ## 13 - rendering must always be a pure calculation
228 | 
229 | Rendering must always be a [pure calculation](https://react.dev/learn/keeping-components-pure):
230 | 
231 | - **Same inputs, same output.** Given the same inputs, a component should always return the same JSX. (When someone orders a salad with tomatoes, they should not receive a salad with onions!)
232 | - **It minds its own business.** It should not change any objects or variables that existed before rendering. (One order should not change anyone else’s order.)
233 | 
234 | Otherwise, you can encounter confusing bugs and unpredictable behavior as your codebase grows in complexity. When developing in “Strict Mode”, React calls each component’s function twice, which can help surface mistakes caused by impure functions.
235 | 
236 | <br>
237 | 
238 | 
239 | ## 14 - slice yes, splice no
240 | 
241 | Unfortunately, [`slice`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice) and [`splice`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/splice) are named similarly but are very different:
242 | 
243 | - `slice` lets you copy an array or a part of it.
244 | - `splice` **mutates** the array (to insert or delete items).
245 | 
246 | In React, you will be using `slice` (no `p`!) a lot more often because you don’t want to mutate objects or arrays in state. [Updating Objects](https://react.dev/learn/updating-objects-in-state) explains what mutation is and why it’s not recommended for state.
247 | 
248 | *source: https://react.dev/learn/updating-arrays-in-state#updating-arrays-without-mutation*
249 | 
250 | <br>
251 | 
252 | ---
253 | 
254 | <br>
255 | 
256 | ## Managing State
257 | 
258 | <br>
259 | 
260 | 
261 | ## 15 - update all fields in object state
262 | 
263 | If your state variable is an object, remember that [you can’t update only one field in it](https://react.dev/learn/updating-objects-in-state) without explicitly copying the other fields. For example, you can’t do `setPosition({ x: 100 })` in the above example because it would not have the `y` property at all! Instead, if you wanted to set `x` alone, you would either do `setPosition({ ...position, x: 100 })`, or split them into two state variables and do `setX(100)`.
264 | 
265 | *source: https://react.dev/learn/choosing-the-state-structure#group-related-state*
266 | 
267 | <br>
268 | 
269 | 
270 | ## 16 - position in UI tree is what matters
271 | 
272 | Remember that **it’s the position in the UI tree—not in the JSX markup—that matters to React!** This component has two `return` clauses with different `<Counter />` JSX tags inside and outside the `if`:
273 | 
274 | ```javascript
275 | import { useState } from 'react';
276 | 
277 | export default function App() {
278 |   const [isFancy, setIsFancy] = useState(false);
279 |   if (isFancy) {
280 |     return (
281 |       <div>
282 |         <Counter isFancy={true} />
283 |         <label>
284 |           <input
285 |             type="checkbox"
286 |             checked={isFancy}
287 |             onChange={e => {
288 |               setIsFancy(e.target.checked)
289 |             }}
290 |           />
291 |           Use fancy styling
292 |         </label>
293 |       </div>
294 |     );
295 |   }
296 |   return (
297 |     <div>
298 |       <Counter isFancy={false} />
299 |       <label>
300 |         <input
301 |           type="checkbox"
302 |           checked={isFancy}
303 |           onChange={e => {
304 |             setIsFancy(e.target.checked)
305 |           }}
306 |         />
307 |         Use fancy styling
308 |       </label>
309 |     </div>
310 |   );
311 | }
312 | 
313 | function Counter({ isFancy }) {
314 |   const [score, setScore] = useState(0);
315 |   const [hover, setHover] = useState(false);
316 | 
317 |   let className = 'counter';
318 |   if (hover) {
319 |     className += ' hover';
320 |   }
321 |   if (isFancy) {
322 |     className += ' fancy';
323 |   }
324 | 
325 |   return (
326 |     <div
327 |       className={className}
328 |       onPointerEnter={() => setHover(true)}
329 |       onPointerLeave={() => setHover(false)}
330 |     >
331 |       <h1>{score}</h1>
332 |       <button onClick={() => setScore(score + 1)}>
333 |         Add one
334 |       </button>
335 |     </div>
336 |   );
337 | }
338 | ```
339 | 
340 | You might expect the state to reset when you tick checkbox, but it doesn’t! This is because **both of these `<Counter />` tags are rendered at the same position.** React doesn’t know where you place the conditions in your function. All it “sees” is the tree you return.
341 | 
342 | In both cases, the `App` component returns a `<div>` with `<Counter />` as a first child. To React, these two counters have the same “address”: the first child of the first child of the root. This is how React matches them up between the previous and next renders, regardless of how you structure your logic.
343 | 
344 | *source: https://react.dev/learn/preserving-and-resetting-state#same-component-at-the-same-position-preserves-state*
345 | 
346 | <br>
347 | 
348 | 
349 | ## 17 - don't nest component functions definitions
350 | 
351 | This is why you should not nest component function definitions.
352 | 
353 | Here, the `MyTextField` component function is defined _inside_ `MyComponent`:
354 | 
355 | ```javascript
356 | import { useState } from 'react';
357 | 
358 | export default function MyComponent() {
359 |   const [counter, setCounter] = useState(0);
360 | 
361 |   function MyTextField() {
362 |     const [text, setText] = useState('');
363 | 
364 |     return (
365 |       <input
366 |         value={text}
367 |         onChange={e => setText(e.target.value)}
368 |       />
369 |     );
370 |   }
371 | 
372 |   return (
373 |     <>
374 |       <MyTextField />
375 |       <button onClick={() => {
376 |         setCounter(counter + 1)
377 |       }}>Clicked {counter} times</button>
378 |     </>
379 |   );
380 | }
381 | ```
382 | 
383 | Every time you click the button, the input state disappears! This is because a _different_ `MyTextField` function is created for every render of `MyComponent`. You’re rendering a _different_ component in the same position, so React resets all state below. This leads to bugs and performance problems. To avoid this problem, **always declare component functions at the top level, and don’t nest their definitions.**
384 | 
385 | *source: https://react.dev/learn/preserving-and-resetting-state#different-components-at-the-same-position-reset-state*
386 | 
387 | <br>
388 | 
389 | ## Escape Hatches
390 | 
391 | <br>
392 | 
393 | ## 18 - careful with setting state in useEffect
394 | 
395 | By default, Effects run after _every_ render. This is why code like this will **produce an infinite loop:**
396 | 
397 | ```javascript
398 | const [count, setCount] = useState(0);useEffect(() => {  setCount(count + 1);});
399 | ```
400 | 
401 | Effects run as a _result_ of rendering. Setting state _triggers_ rendering. Setting state immediately in an Effect is like plugging a power outlet into itself. The Effect runs, it sets the state, which causes a re-render, which causes the Effect to run, it sets the state again, this causes another re-render, and so on.
402 | 
403 | Effects should usually synchronize your components with an _external_ system. If there’s no external system and you only want to adjust some state based on other state, [you might not need an Effect.](https://react.dev/learn/you-might-not-need-an-effect)
404 | 
405 | *source: https://react.dev/learn/synchronizing-with-effects#step-1-declare-an-effect*
406 | 
407 | <br>
408 | 
409 | ## 19 - dependency array and behaviour of useEffect
410 | 
411 | The behaviors without the dependency array and with an _empty_ `[]` dependency array are different:
412 | 
413 | ```javascript
414 | useEffect(() => {
415 | // This runs after every render
416 | });
417 | 
418 | useEffect(() => {
419 | // This runs only on mount (when the component appears)
420 | }, []);
421 | 
422 | useEffect(() => {
423 | // This runs on mount *  and also* if either a or b have changed since the last render
424 | }, [a, b]);
425 | ```
426 | 
427 | *source: https://react.dev/learn/synchronizing-with-effects#step-2-specify-the-effect-dependencies*
428 | 
429 | <br>
430 | 
431 | ## 20 - role of linter for useEffect dependency array
432 | 
433 | The linter is your friend, but its powers are limited. The linter only knows when the dependencies are _wrong_. It doesn’t know _the best_ way to solve each case. If the linter suggests a dependency, but adding it causes a loop, it doesn’t mean the linter should be ignored. You need to change the code inside (or outside) the Effect so that that value isn’t reactive and doesn’t _need_ to be a dependency.
434 | 
435 | If you have an existing codebase, you might have some Effects that suppress the linter like this:
436 | 
437 | ```
438 | useEffect(() => {  // ...  // 🔴 Avoid suppressing the linter like this:  // eslint-ignore-next-line react-hooks/exhaustive-deps}, []);
439 | ```
440 | 
441 | On the [next](https://react.dev/learn/separating-events-from-effects) [pages](https://react.dev/learn/removing-effect-dependencies), you’ll learn how to fix this code without breaking the rules. It’s always worth fixing!
442 | 
443 | *source: https://react.dev/learn/lifecycle-of-reactive-effects#what-to-do-when-you-dont-want-to-re-synchronize*
444 | 
445 | <br>
446 | 
447 | ## 21 - don't suppress the linter
448 | 
449 | If you have an existing codebase, you might have some Effects that suppress the linter like this:
450 | 
451 | ```
452 | useEffect(() => {  // ...  // 🔴 Avoid suppressing the linter like this:  // eslint-ignore-next-line react-hooks/exhaustive-deps}, []);
453 | ```
454 | 
455 | **When dependencies don’t match the code, there is a very high risk of introducing bugs.** By suppressing the linter, you “lie” to React about the values your Effect depends on.
456 | 
457 | Instead, use the techniques below.
458 | 
459 | *source: https://react.dev/learn/removing-effect-dependencies#to-change-the-dependencies-change-the-code*
460 | 
461 | <br>
462 | 
463 | 
464 | 


--------------------------------------------------------------------------------