Scribd
Upload
13 views

React Study Guide

Uploaded by

michelle.pineda.subs
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
13 views

React Study Guide

Uploaded by

michelle.pineda.subs
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Step 1: Break the UI and map it into a component hierarchy

Use the same techniques for deciding if you should create a new function or object. One
such technique is the single responsibility principle, that is, a component should ideally only
do one thing. Scan the components from the top of the hierarchy and if you find on the way
down, that a component repeats itself, or if it ends up growing, it should be decomposed into
smaller subcomponents. Si el contenido se debe generar dinámicamente, entonces vale
la pena convertirlo en un componente propio que takes in props?

Now that you’ve identified the components in the mockup, arrange them into a hierarchy.
Components that appear within another component in the mockup should appear as a child
in the hierarchy:

● FilterableProductTable
○ SearchBar
○ ProductTable
■ ProductCategoryRow
■ ProductRow

Step 2: Build a static version in React


To build a static version of your app that renders your data, you’ll want to build components
that reuse other components and pass data using props. Props are a way of passing data
from parent to child. (Don’t use state at all to build this static version yet). In simpler
examples, it’s usually easier to go top-down, and on larger projects, it’s easier to go
bottom-up. The component at the top of the hierarchy will take the data as a prop. This is
called one-way data flow because the data flows down from the top-level component to the
ones at the bottom of the tree. (Exceptions may arise here, like using context to avoid
prop-drilling)
Step 3: Find the minimal but complete representation of UI state

Think of all of the pieces of data in this example application:

● The original list of products


● The search text the user has entered
● The value of the checkbox
● The filtered list of products

Which of these are state? Identify the ones that are not:

Does it remain unchanged over time? If so, it isn’t state.


Is it passed in from a parent via props? If so, it isn’t state.
Can you compute it based on existing state or props in your component? If so, it definitely
isn’t state!
What’s left is probably state.

Tip: User interaction with the app is something we want to keep track of as it changes
over time and can't compute it from anywhere else so this will almost always be state.

Step 4: Identify where your state should live

For each piece of state in your application:

1. Identify every component that renders something based on that state.


2. Find their closest common parent component—a component above them all in the
hierarchy.
3. Decide where the state should live:
Often, you can put the state directly into that common parent. You can also put the
state into some component above their common parent. If you can’t find a
component where it makes sense to own the state, create a new component solely
for holding the state and add it somewhere in the hierarchy above the common
parent component.

Step 5: Add inverse data flow

To change the state according to user input if that state has been passed as props, you will
need to support data flowing the other way. We need to pass the setState functions to the
components that change state, into their event handlers.

useEffect and Lifecycle Hooks

useEffect() : after and for every render cycle


If you pass no dependency array at all, your Effect runs after every single render (and
re-render) of your component.

useEffect(() => { }); //without any argument acts as componentDidUpdate


useEffect(() => { }, []); //with empty array argument acts as componentDidMount
If your Effect truly doesn’t use any reactive values, it will only run after the initial render.

From the Redux Toolkit

Below are some of the most frequently used properties on the "mutation result" object. Refer
to useMutation for an extensive list of all returned properties.

data - The data returned from the latest trigger response, if present. If subsequent triggers
from the same hook instance are called, this will return undefined until the new data is
received. Consider component level caching if the previous response data is required for a
smooth transition to new data.
error - The error result if present.
isUninitialized - When true, indicates that the mutation has not been fired yet.
isLoading - When true, indicates that the mutation has been fired and is awaiting a response.
isSuccess - When true, indicates that the last mutation fired has data from a successful
request.
isError - When true, indicates that the last mutation fired resulted in an error state.
reset - A method to reset the hook back to it's original state and remove the current result
from the cache

FYI: Mutations also have a lifecycle (pattern from Redux?)


These helper options allow quick and easy side-effects at any stage during the mutation
lifecycle and come in handy for both invalidating and refetching queries after mutations and
even optimistic updates.

Open Bootcamp

https://campus.open-bootcamp.com/cursos/1/leccion/192
La cuestión de dónde almacenar la lógica en los contenedores.
El uso de clases para crear instancias de objetos. Esto en caso de no recibir data de una
API.

You might also like