└── README.md


/README.md:
--------------------------------------------------------------------------------
  1 | # React recaps v18.2.0
  2 | Recaps from react documentation https://react.dev/
  3 | ---
  4 | 
  5 | <br>
  6 | 
  7 | ## Describing the UI
  8 | 
  9 | ### Your First Component
 10 | 
 11 | You’ve just gotten your first taste of React! Let’s recap some key points.
 12 | - React lets you create components, **reusable UI elements for your app.**
 13 |     
 14 | - In a React app, every piece of UI is a component.
 15 |     
 16 | - React components are regular JavaScript functions except:
 17 |     
 18 |     1. Their names always begin with a capital letter.
 19 |     2. They return JSX markup.
 20 | 
 21 | *link: https://react.dev/learn/your-first-component*
 22 | 
 23 | <br>
 24 | 
 25 | ### Importing and Exporting Components
 26 | 
 27 | On this page you learned:
 28 | 
 29 | - What a root component file is
 30 | - How to import and export a component
 31 | - When and how to use default and named imports and exports
 32 | - How to export multiple components from the same file
 33 | 
 34 | *link: https://react.dev/learn/importing-and-exporting-components*
 35 | 
 36 | <br>
 37 | 
 38 | 
 39 | ### Writing Markup with JSX
 40 | 
 41 | Now you know why JSX exists and how to use it in components:
 42 | 
 43 | - React components group rendering logic together with markup because they are related.
 44 | - JSX is similar to HTML, with a few differences. You can use a [converter](https://transform.tools/html-to-jsx) if you need to.
 45 | - Error messages will often point you in the right direction to fixing your markup.
 46 | 
 47 | *link: https://react.dev/learn/writing-markup-with-jsx*
 48 | 
 49 | <br>
 50 | 
 51 | 
 52 | ### JavaScript in JSX with Curly Braces
 53 | 
 54 | Now you know almost everything about JSX:
 55 | 
 56 | - JSX attributes inside quotes are passed as strings.
 57 | - Curly braces let you bring JavaScript logic and variables into your markup.
 58 | - They work inside the JSX tag content or immediately after `=` in attributes.
 59 | - `{{` and `}}` is not special syntax: it’s a JavaScript object tucked inside JSX curly braces.
 60 | 
 61 | *link: https://react.dev/learn/javascript-in-jsx-with-curly-braces*
 62 | 
 63 | <br>
 64 | 
 65 | 
 66 | ### Passing Props to a Component
 67 | 
 68 | - To pass props, add them to the JSX, just like you would with HTML attributes.
 69 | - To read props, use the `function Avatar({ person, size })` destructuring syntax.
 70 | - You can specify a default value like `size = 100`, which is used for missing and `undefined` props.
 71 | - You can forward all props with `<Avatar {...props} />` JSX spread syntax, but don’t overuse it!
 72 | - Nested JSX like `<Card><Avatar /></Card>` will appear as `Card` component’s `children` prop.
 73 | - Props are read-only snapshots in time: every render receives a new version of props.
 74 | - You can’t change props. When you need interactivity, you’ll need to set state.
 75 | 
 76 | *link: https://react.dev/learn/passing-props-to-a-component*
 77 | 
 78 | <br>
 79 | 
 80 | 
 81 | ### Conditional Rendering
 82 | 
 83 | - In React, you control branching logic with JavaScript.
 84 | - You can return a JSX expression conditionally with an `if` statement.
 85 | - You can conditionally save some JSX to a variable and then include it inside other JSX by using the curly braces.
 86 | - In JSX, `{cond ? <A /> : <B />}` means _“if `cond`, render `<A />`, otherwise `<B />`”_.
 87 | - In JSX, `{cond && <A />}` means _“if `cond`, render `<A />`, otherwise nothing”_.
 88 | - The shortcuts are common, but you don’t have to use them if you prefer plain `if`.
 89 | 
 90 | *link: https://react.dev/learn/conditional-rendering*
 91 | 
 92 | <br>
 93 | 
 94 | 
 95 | ### Rendering Lists
 96 | 
 97 | On this page you learned:
 98 | 
 99 | - How to move data out of components and into data structures like arrays and objects.
100 | - How to generate sets of similar components with JavaScript’s `map()`.
101 | - How to create arrays of filtered items with JavaScript’s `filter()`.
102 | - Why and how to set `key` on each component in a collection so React can keep track of each of them even if their position or data changes.
103 | 
104 | *link: https://react.dev/learn/rendering-lists*
105 | 
106 | <br>
107 | 
108 | 
109 | ### Keeping Components Pure
110 | 
111 | - A component must be pure, meaning:
112 |     - **It minds its own business.** It should not change any objects or variables that existed before rendering.
113 |     - **Same inputs, same output.** Given the same inputs, a component should always return the same JSX.
114 | - Rendering can happen at any time, so components should not depend on each others’ rendering sequence.
115 | - You should not mutate any of the inputs that your components use for rendering. That includes props, state, and context. To update the screen, [“set” state](https://react.dev/learn/state-a-components-memory) instead of mutating preexisting objects.
116 | - Strive to express your component’s logic in the JSX you return. When you need to “change things”, you’ll usually want to do it in an event handler. As a last resort, you can `useEffect`.
117 | - Writing pure functions takes a bit of practice, but it unlocks the power of React’s paradigm.
118 | 
119 | *link: https://react.dev/learn/keeping-components-pure*
120 | 
121 | ---
122 | 
123 | <br>
124 | 
125 | ## Adding Interactivity
126 | 
127 | 
128 | ### Responding to Events
129 | 
130 | - You can handle events by passing a function as a prop to an element like `<button>`.
131 | - Event handlers must be passed, **not called!** `onClick={handleClick}`, not `onClick={handleClick()}`.
132 | - You can define an event handler function separately or inline.
133 | - Event handlers are defined inside a component, so they can access props.
134 | - You can declare an event handler in a parent and pass it as a prop to a child.
135 | - You can define your own event handler props with application-specific names.
136 | - Events propagate upwards. Call `e.stopPropagation()` on the first argument to prevent that.
137 | - Events may have unwanted default browser behavior. Call `e.preventDefault()` to prevent that.
138 | - Explicitly calling an event handler prop from a child handler is a good alternative to propagation.
139 | 
140 | *link: https://react.dev/learn/responding-to-events*
141 | 
142 | <br>
143 | 
144 | 
145 | ### State: A Component's Memory
146 | 
147 | - Use a state variable when a component needs to “remember” some information between renders.
148 | - State variables are declared by calling the `useState` Hook.
149 | - Hooks are special functions that start with `use`. They let you “hook into” React features like state.
150 | - Hooks might remind you of imports: they need to be called unconditionally. Calling Hooks, including `useState`, is only valid at the top level of a component or another Hook.
151 | - The `useState` Hook returns a pair of values: the current state and the function to update it.
152 | - You can have more than one state variable. Internally, React matches them up by their order.
153 | - State is private to the component. If you render it in two places, each copy gets its own state.
154 | 
155 | *link: https://react.dev/learn/state-a-components-memory*
156 | 
157 | <br>
158 | 
159 | ### Render and Commit
160 | 
161 | - Any screen update in a React app happens in three steps:
162 |     1. Trigger
163 |     2. Render
164 |     3. Commit
165 | - You can use Strict Mode to find mistakes in your components
166 | - React does not touch the DOM if the rendering result is the same as last time
167 | 
168 | *link: https://react.dev/learn/render-and-commit*
169 | 
170 | <br>
171 | 
172 | 
173 | ### State as a Snapshot
174 | 
175 | - Setting state requests a new render.
176 | - React stores state outside of your component, as if on a shelf.
177 | - When you call `useState`, React gives you a snapshot of the state _for that render_.
178 | - Variables and event handlers don’t “survive” re-renders. Every render has its own event handlers.
179 | - Every render (and functions inside it) will always “see” the snapshot of the state that React gave to _that_ render.
180 | - You can mentally substitute state in event handlers, similarly to how you think about the rendered JSX.
181 | - Event handlers created in the past have the state values from the render in which they were created.
182 | 
183 | *link: https://react.dev/learn/state-as-a-snapshot*
184 | 
185 | <br>
186 | 
187 | ### Queueing a Series of State Updates
188 | 
189 | - Setting state does not change the variable in the existing render, but it requests a new render.
190 | - React processes state updates after event handlers have finished running. This is called batching.
191 | - To update some state multiple times in one event, you can use `setNumber(n => n + 1)` updater function.
192 | 
193 | *link: https://react.dev/learn/queueing-a-series-of-state-updates*
194 | 
195 | <br>
196 | 
197 | ### Updating Objects in State
198 | 
199 | - Treat all state in React as immutable.
200 | - When you store objects in state, mutating them will not trigger renders and will change the state in previous render “snapshots”.
201 | - Instead of mutating an object, create a _new_ version of it, and trigger a re-render by setting state to it.
202 | - You can use the `{...obj, something: 'newValue'}` object spread syntax to create copies of objects.
203 | - Spread syntax is shallow: it only copies one level deep.
204 | - To update a nested object, you need to create copies all the way up from the place you’re updating.
205 | - To reduce repetitive copying code, use Immer.
206 | 
207 | *link: https://react.dev/learn/updating-objects-in-state*
208 | 
209 | <br>
210 | 
211 | 
212 | ### Updating Arrays in State
213 | 
214 | - You can put arrays into state, but you can’t change them.
215 | - Instead of mutating an array, create a _new_ version of it, and update the state to it.
216 | - You can use the `[...arr, newItem]` array spread syntax to create arrays with new items.
217 | - You can use `filter()` and `map()` to create new arrays with filtered or transformed items.
218 | - You can use Immer to keep your code concise.
219 | 
220 | *link: https://react.dev/learn/updating-arrays-in-state*
221 | 
222 | ---
223 | 
224 | <br>
225 | 
226 | ## Managing State
227 | 
228 | ### Reacting to Input with State
229 | 
230 | - Declarative programming means describing the UI for each visual state rather than micromanaging the UI (imperative).
231 | - When developing a component:
232 |     1. Identify all its visual states.
233 |     2. Determine the human and computer triggers for state changes.
234 |     3. Model the state with `useState`.
235 |     4. Remove non-essential state to avoid bugs and paradoxes.
236 |     5. Connect the event handlers to set state.
237 | 
238 | *link: https://react.dev/learn/reacting-to-input-with-state*
239 | 
240 | <br>
241 | 
242 | ### Choosing the State Structure
243 | 
244 | - If two state variables always update together, consider merging them into one.
245 | - Choose your state variables carefully to avoid creating “impossible” states.
246 | - Structure your state in a way that reduces the chances that you’ll make a mistake updating it.
247 | - Avoid redundant and duplicate state so that you don’t need to keep it in sync.
248 | - Don’t put props _into_ state unless you specifically want to prevent updates.
249 | - For UI patterns like selection, keep ID or index in state instead of the object itself.
250 | - If updating deeply nested state is complicated, try flattening it.
251 | 
252 | *link: https://react.dev/learn/choosing-the-state-structure*
253 | 
254 | <br>
255 | 
256 | 
257 | ### Sharing State Between Components
258 | 
259 | - When you want to coordinate two components, move their state to their common parent.
260 | - Then pass the information down through props from their common parent.
261 | - Finally, pass the event handlers down so that the children can change the parent’s state.
262 | - It’s useful to consider components as “controlled” (driven by props) or “uncontrolled” (driven by state).
263 | 
264 | *link: https://react.dev/learn/sharing-state-between-components*
265 | 
266 | <br>
267 | 
268 | 
269 | ### Preserving and Resetting State
270 | 
271 | - React keeps state for as long as the same component is rendered at the same position.
272 | - State is not kept in JSX tags. It’s associated with the tree position in which you put that JSX.
273 | - You can force a subtree to reset its state by giving it a different key.
274 | - Don’t nest component definitions, or you’ll reset state by accident.
275 | 
276 | *link: https://react.dev/learn/preserving-and-resetting-state*
277 | 
278 | <br>
279 | 
280 | 
281 | ### Extracting State Logic into a Reducer
282 | 
283 | - To convert from `useState` to `useReducer`:
284 |     1. Dispatch actions from event handlers.
285 |     2. Write a reducer function that returns the next state for a given state and action.
286 |     3. Replace `useState` with `useReducer`.
287 | - Reducers require you to write a bit more code, but they help with debugging and testing.
288 | - Reducers must be pure.
289 | - Each action describes a single user interaction.
290 | - Use Immer if you want to write reducers in a mutating style.
291 | 
292 | *link: https://react.dev/learn/extracting-state-logic-into-a-reducer*
293 | 
294 | <br>
295 | 
296 | 
297 | ### Passing Data Deeply with Context
298 | 
299 | - Context lets a component provide some information to the entire tree below it.
300 | - To pass context:
301 |     1. Create and export it with `export const MyContext = createContext(defaultValue)`.
302 |     2. Pass it to the `useContext(MyContext)` Hook to read it in any child component, no matter how deep.
303 |     3. Wrap children into `<MyContext.Provider value={...}>` to provide it from a parent.
304 | - Context passes through any components in the middle.
305 | - Context lets you write components that “adapt to their surroundings”.
306 | - Before you use context, try passing props or passing JSX as `children`.
307 | 
308 | *link: https://react.dev/learn/passing-data-deeply-with-context*
309 | 
310 | <br>
311 | 
312 | 
313 | ### Scaling Up with Reducer and Context
314 | 
315 | - You can combine reducer with context to let any component read and update state above it.
316 | - To provide state and the dispatch function to components below:
317 |     1. Create two contexts (for state and for dispatch functions).
318 |     2. Provide both contexts from the component that uses the reducer.
319 |     3. Use either context from components that need to read them.
320 | - You can further declutter the components by moving all wiring into one file.
321 |     - You can export a component like `TasksProvider` that provides context.
322 |     - You can also export custom Hooks like `useTasks` and `useTasksDispatch` to read it.
323 | - You can have many context-reducer pairs like this in your app.
324 | 
325 | *link: https://react.dev/learn/scaling-up-with-reducer-and-context*
326 | 
327 | <br>
328 | 
329 | 
330 | 
331 | ## Escape Hatches
332 | 
333 | ### Referencing Values with Refs
334 | 
335 | - Refs are an escape hatch to hold onto values that aren’t used for rendering. You won’t need them often.
336 | - A ref is a plain JavaScript object with a single property called `current`, which you can read or set.
337 | - You can ask React to give you a ref by calling the `useRef` Hook.
338 | - Like state, refs let you retain information between re-renders of a component.
339 | - Unlike state, setting the ref’s `current` value does not trigger a re-render.
340 | - Don’t read or write `ref.current` during rendering. This makes your component hard to predict.
341 | 
342 | *link: https://react.dev/learn/referencing-values-with-refs*
343 | 
344 | <br>
345 | 
346 | 
347 | ### Manipulating the DOM with Refs
348 | 
349 | - Refs are a generic concept, but most often you’ll use them to hold DOM elements.
350 | - You instruct React to put a DOM node into `myRef.current` by passing `<div ref={myRef}>`.
351 | - Usually, you will use refs for non-destructive actions like focusing, scrolling, or measuring DOM elements.
352 | - A component doesn’t expose its DOM nodes by default. You can opt into exposing a DOM node by using `forwardRef` and passing the second `ref` argument down to a specific node.
353 | - Avoid changing DOM nodes managed by React.
354 | - If you do modify DOM nodes managed by React, modify parts that React has no reason to update.
355 | 
356 | *link: https://react.dev/learn/manipulating-the-dom-with-refs*
357 | 
358 | <br>
359 | 
360 | 
361 | ### Synchronizing with Effects
362 | 
363 | - Unlike events, Effects are caused by rendering itself rather than a particular interaction.
364 | - Effects let you synchronize a component with some external system (third-party API, network, etc).
365 | - By default, Effects run after every render (including the initial one).
366 | - React will skip the Effect if all of its dependencies have the same values as during the last render.
367 | - You can’t “choose” your dependencies. They are determined by the code inside the Effect.
368 | - Empty dependency array (`[]`) corresponds to the component “mounting”, i.e. being added to the screen.
369 | - In Strict Mode, React mounts components twice (in development only!) to stress-test your Effects.
370 | - If your Effect breaks because of remounting, you need to implement a cleanup function.
371 | - React will call your cleanup function before the Effect runs next time, and during the unmount.
372 | 
373 | *link: https://react.dev/learn/synchronizing-with-effects*
374 | 
375 | <br>
376 | 
377 | 
378 | ### You Might Not Need an Effect
379 | 
380 | - If you can calculate something during render, you don’t need an Effect.
381 | - To cache expensive calculations, add `useMemo` instead of `useEffect`.
382 | - To reset the state of an entire component tree, pass a different `key` to it.
383 | - To reset a particular bit of state in response to a prop change, set it during rendering.
384 | - Code that runs because a component was _displayed_ should be in Effects, the rest should be in events.
385 | - If you need to update the state of several components, it’s better to do it during a single event.
386 | - Whenever you try to synchronize state variables in different components, consider lifting state up.
387 | - You can fetch data with Effects, but you need to implement cleanup to avoid race conditions.
388 | 
389 | *link: https://react.dev/learn/you-might-not-need-an-effect*
390 | 
391 | <br>
392 | 
393 | 
394 | ### Lifecycle of Reactive Effects
395 | 
396 | - Components can mount, update, and unmount.
397 | - Each Effect has a separate lifecycle from the surrounding component.
398 | - Each Effect describes a separate synchronization process that can _start_ and _stop_.
399 | - When you write and read Effects, think from each individual Effect’s perspective (how to start and stop synchronization) rather than from the component’s perspective (how it mounts, updates, or unmounts).
400 | - Values declared inside the component body are “reactive”.
401 | - Reactive values should re-synchronize the Effect because they can change over time.
402 | - The linter verifies that all reactive values used inside the Effect are specified as dependencies.
403 | - All errors flagged by the linter are legitimate. There’s always a way to fix the code to not break the rules.
404 | 
405 | *link: https://react.dev/learn/lifecycle-of-reactive-effects*
406 | 
407 | <br>
408 | 
409 | 
410 | ### Separating Events from Effects
411 | 
412 | - Event handlers run in response to specific interactions.
413 | - Effects run whenever synchronization is needed.
414 | - Logic inside event handlers is not reactive.
415 | - Logic inside Effects is reactive.
416 | - You can move non-reactive logic from Effects into Effect Events.
417 | - Only call Effect Events from inside Effects.
418 | - Don’t pass Effect Events to other components or Hooks.
419 | 
420 |   *link: https://react.dev/learn/separating-events-from-effects*
421 | 
422 |   <br>
423 | 
424 | 
425 | ### Removing Effect Dependencies
426 | 
427 | - Dependencies should always match the code.
428 | - When you’re not happy with your dependencies, what you need to edit is the code.
429 | - Suppressing the linter leads to very confusing bugs, and you should always avoid it.
430 | - To remove a dependency, you need to “prove” to the linter that it’s not necessary.
431 | - If some code should run in response to a specific interaction, move that code to an event handler.
432 | - If different parts of your Effect should re-run for different reasons, split it into several Effects.
433 | - If you want to update some state based on the previous state, pass an updater function.
434 | - If you want to read the latest value without “reacting” it, extract an Effect Event from your Effect.
435 | - In JavaScript, objects and functions are considered different if they were created at different times.
436 | - Try to avoid object and function dependencies. Move them outside the component or inside the Effect.
437 | 
438 | *link: https://react.dev/learn/removing-effect-dependencies*
439 | 
440 | <br>
441 | 
442 | 
443 | ### Reusing Logic with Custom Hooks
444 | 
445 | - Custom Hooks let you share logic between components.
446 | - Custom Hooks must be named starting with `use` followed by a capital letter.
447 | - Custom Hooks only share stateful logic, not state itself.
448 | - You can pass reactive values from one Hook to another, and they stay up-to-date.
449 | - All Hooks re-run every time your component re-renders.
450 | - The code of your custom Hooks should be pure, like your component’s code.
451 | - Wrap event handlers received by custom Hooks into Effect Events.
452 | - Don’t create custom Hooks like `useMount`. Keep their purpose specific.
453 | - It’s up to you how and where to choose the boundaries of your code.
454 | 
455 | *link: https://react.dev/learn/reusing-logic-with-custom-hooks*
456 | 
457 |   
458 | 
459 | 
460 | 
461 | 


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