we use built-in fetch to get data from a url say…https://api.example.com/items:

Once we have retrieved it, we execute json() on the response ‘res’, which is a JSON BODY mixin.

It returns a promise that resolves with the result of parsing the body text as JSON:

We then set our state object property employees to that result. When we use setState, React sees that a state property was updated, and goes to diff the virtual DOMs. Thus, the render gets triggered again so that we re-draw the subtree that changed.

Notice we put the fetch inside of componentDidMount. The reason why is because the component needs to execute constructor, componentWillMount, then start building up its DOM, and finally when done, call componentDidMount first in order to have the states and nodes in place. Only when our DOM nodes and states are ready, can we then insert data. Thus, that is why we fetch in componentDidMount.

full code

It is recommended to avoid hard coding style values in components. Any values that are likely to be used across different UI components should be extracted into their own modules.

For example, these styles could be extracted into a separate component:

And then imported individually in other components:

import { space, colors } from ‘./styles’

You could use the ref prop to acquire a reference to the underlying HTMLInputElement object through a callback, store the reference as a class property, then use that reference to later trigger a click from your event handlers using the HTMLElement.click method.

This can be done in two steps:

Create ref in render method:

Apply click event in your event handler:

ref – https://reactjs.org/docs/render-props.html
https://flaviocopes.com/react-render-props/

A common pattern used to share state between components is to use the children prop.

For example, a component’s (this.props.children) references the JSX that you pass into this particular component.

In our case, component Parent’s this.props.children references an array which contains Children1 and Children2 components.

However, there is a problem here: the state of the parent component cannot be accessed from the children.

so we share state like this:

In the Parent, we have a state object with property ‘name’. We pass this into this.props.children
Thus, whatever we pass into JSX Parent component will be able to receive Parent’s state via prop:

However, using the children property on the prop object is very specific. You may not want this.

Render Prop

You have the option to use any prop. We can use someProp1, someProp2 as props in component Parent. It takes in data which we then pass to components Children1 and Children2.

So in component Parent, this.props.someprop1 references function

Then, this.state.name is passed into into this.props.someprop1 in the render function.

This name then goes into the function above and gets passed into component Children1.

Thus, the name ‘Flavio’ is passed into component Children1.

This is called render prop, which refers to a technique for sharing code between React components using a prop whose value is a function.

In other words, a component (Parent) with a render prop (someprop1) references a function:

In our case the function is:

that returns component Children and is called in Parent’s render function:

More concretely, a render prop is a function prop that a component uses to know what to render.

ref – https://alligator.io/react/get-derived-state/
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html

For a long time, the lifecycle componentWillReceiveProps was the only way to update state in response to a change in props without an additional render. In version 16.3, we introduced a replacement lifecycle, getDerivedStateFromProps to solve the same use cases in a safer way.

getDerivedStateFromProps improves on the older method by providing a function whose only purpose is to update the state based on prop changes, without any side effects.

getDerivedStateFromProps simply returns an object containing the updated state. Notice that the function has no side-effects; this is intentional. Depending on how you want to update the state based on prop, you return an object literal.

getDerivedStateFromProps may be called multiple times for a single update, so it’s important to avoid any side-effects. Instead, you should use componentDidUpdate, which executes only once after the component updates.

However, you probably don’t need Derived State

When to Use Derived State

getDerivedStateFromProps exists for only one purpose: It enables a component to update its internal state as the result of changes in props.

All problems with derived state that we have seen can be ultimately reduced to either:

(1) unconditionally updating state from props or
(2) updating state whenever props and state don’t match.

YOU DON”T NEED DERIVED STATE

– If you’re using derived state to memoize some computation based only on the current props
– If you’re updating derived state unconditionally or updating it whenever props and state don’t match, your component likely resets its state too frequently.

The terms controlled and uncontrolled usually refer to form inputs, but they can also describe where any component’s data lives.

Data passed in as props can be thought of as controlled (because the parent component controls that data). Data that exists only in internal state can be thought of as uncontrolled (because the parent can’t directly change it).

The most common mistake with derived state is mixing these two. For example:

State value can be updated by setState calls, as well as derived from prop. This means there isn’t a single source of truth for the data.

Unconditionally copying props to state

State is initialized to the value specified by props and updated when we type into the input. But if our component’s parent re-renders, anything we’ve typed into the input will be lost! Components usually accept multiple props; another prop changing would ALSO cause a re-render and improper reset.

Therefore, it is a bad idea to unconditionally copy props to state.

Erasing state when props change

We’ve just made a big improvement. Now our component will erase what we’ve typed only when the props actually change.

However, because our prop uses ’email’ property compare, if two accounts had the same exactly email, this situation would happen.

1) Say you’re updating the first email account, then you click on another account type.
2) The parent component’s prop makes the update, but because your email is the same “fake.email@example.com” for id 1 and id 2, our componentWillReceiveProps will just skip. When users switch from id 1 to id 2, they still see what you updated in the input text. Whereas it should have cleared, or defaulted by to the string “fake.email@example.com”.

The key is that for any piece of data, you need to pick a single component that owns it as the source of truth, and avoid duplicating it in other components. Let’s take a look at each of the alternatives.

Solutions

Fully controlled component – One way to avoid the problems mentioned above is to remove state from our component entirely. If the email address only exists as a prop, then we don’t have to worry about conflicts with state.

This approach simplifies the implementation of our component, but if we still want to store a draft value, the parent form component will now need to do that manually.

Fully uncontrolled component with a key

In order to reset the value when moving to a different item, we can use the special React attribute called key. When a key changes, React will create a new component instance rather than update the current one. Keys are usually used for dynamic lists but are also useful here. In our case, we could use the user ID to recreate the email input any time a new user is selected:

Each time the user id changes, the EmailInput will be recreated and its state will be reset to the latest defaultEmail value.

But let’s say the component is very expensive to initialize, and we can’t create it often…

A workable but cumbersome solution would be to watch for changes to “userID” on property “prevPropsUserID” in getDerivedStateFromProps:

ref – https://dev.to/dinhhuyams/introduction-to-react-memo-usememo-and-usecallback-5ei3
https://medium.com/javascript-in-plain-english/react-usememo-and-when-you-should-use-it-e69a106bbb02
https://dmitripavlutin.com/dont-overuse-react-usecallback/

React.memo IS NOT A HOOK. React.memo is a higher order component.
It’s the same to React.PureComponent , but for function components instead of classes.

Where as React.useMemo is a hook.

If your function component renders the same result given the same props,
you can wrap it in a call to React.memo for a performance boost in some cases
by memoizing the result. This means that React will skip rendering the component,
and reuse the last rendered result.

React.memo only checks for prop changes. If your function component wrapped
in React.memo has a useState or useContext Hook in its implementation,
it will still re-render when state or context change.

We have an App with two different states, count1 and count2.

We then return a React Element with two components that uses these counts as props

As you can see, even though we click on the button to increase Counter Won’s state property count1, Counter Too gets re-rendered as well. This is because React sees that state has changed, it will re-render the whole whole element.

The heuristic algorithm says that as long as the node types are the same, then recursively update.

Hence, our main div stays the same.
The header stays the same.
Button stays the same because it’s just a click handler.
Counter Won’s state changed from 0 to 1, so we update it.
Counter Too’s state stayed the same, update also.

So the problem is here.
“Counter Too” re-renders simply because a state from Counter Won has changed which makes App re-render.

In order to separate this, we can use React.memo to control our re-rendering scheme. So instead of all instances of Counter components under a React Element being re-rendered simply due to one state change, we can have it where by default.

If your component renders the same result given the same props, you can wrap it in a call to React.memo for a performance boost in some cases by memoizing the result. This means that React will skip rendering the component, and reuse the last rendered result.

React.memo only checks for prop changes. If your function component wrapped in React.memo has a useState or useContext Hook in its implementation, it will still rerender when state or context change.

If these props are unchanged, React.memo will reuse the last rendered result, therefore, it prevents the component from being re-rendered. In our example, React.memo will check if there are any changes with the value and children props since the last render. Since our button only changes the value of the counter1, React.memo will prevent the counter2 from being re-rendered.

In Counter.js

If you want to use your own logic for the re-rendering

There is an example at the end here

React.useMemo

useMemo is a hook that (given a function, and an array of values) returns a memoized value. It takes a function that does some calculations. When said properties have been changed, then it recalculates the function. If they stay the same, then we don’t recalculate and simply return what was memoized from before.

The hook will return a new value only when one of the dependencies value changes (referential equality).

React.useMemo Example

We have two functional component: FibDisplay and NameDisplay.
FibDisplay has prop property length. It is connected to state length.
NameDisplay has prop property name, it is connected to state name.

Run the app. Say we update name. We set_name a new value from input. This update will trigger a re-render for all components in our App’s render, including the FibDisplay component.

However, FibDisplay component re-render is very expensive because it does a lot of calculations.

Can we somehow improve this performance?

In order to do so, we can have React memo-ize the calculations of our fib:

It will remember the value we have calculated as the result if our previous prop and current prop match.

Then when we re-run the app, you’ll notice that we still re-render FibDisplay, however, const numbers will not be re-calculated again.

All you’ll see is the React components being re-rendered. But no expensive Fib computations.

– The hook itself introduces new complex logic, and it might introduce more performance issues than it solves. Do not apply useMemo unless this is a really expensive computation, or, if you are not sure, you can benchmark both ways and make an informed descision.

– As per the React docs, you may never depend on the internal mechanisms on useMemo. In other words, while useMemo is supposed to be called only on dependencies change, this is not guaranteed. Your app must still work perfectly well (maybe a bit slow though) if useMemo calls your callback on every render.

Differences between useMemo and useEffect

• useState is causing a re-render on the call of the setState method (second element in the array returned). It does not have any dependencies like useMemo or useEffect.
• useMemo only recalculates a value if the elements in its dependency array change (if there are no dependencies – i.e. the array is empty, it will recalculate only once). If the array is left out, it will recalculate on every render. Calling the function does not cause a re-render. Also it runs during the render of the component and not before.
• useEffect is called after each render, if elements in its dependency array have changed or the array is left out. If the array is empty, it will only be run once on the initial mount (and unmount if you return a cleanup function).

useCallback

Different function instances sharing the same code are often created inside React components.

When inside a React component body a function is defined (e.g. a callback or event handler), this function is re-created on every rendering:

In other words…

handleClick is a different function object on every rendering of MyComponent.

When we pass button handler functions to props of child components:

Because inline functions are cheap, the re-creation of functions on each rendering is not a problem. A few inline functions per component are acceptable.

However, there are cases when you need to keep one instance of a function:

– A component wrapped inside React.memo() (or shouldComponentUpdate) accepts a callback prop
– When the function is used as a dependency to other hooks, e.g. useEffect(…, [callback])

That’s the case when useCallback(callbackFun, depends) helps you: giving the same dependency values depends, the hook returns the same function instance between renderings:

Imagine you have a component that renders a big list of items:

MyBigList renders a list of items. Knowing the list could be big, probably a few hundreds of items. To preserve the list re-rendering, you wrap it into React.memo.

The parent component of MyBigList needs provides a handler function when an item is clicked.

handleClick callback is memoizied by useCallback(). As long as term variable stays the same, useCallback() returns the same function instance.

Even if for some reason MyParent component re-renders, handleClick stays the same and doesn’t break the memoization of MyBigList.

A bad use case would be if a components simply returns very little JSX.

Another example

where Counter component is:

Now, when App is rerendered, a new increaseCounter1 function object is passed into onClick.
ref – https://stackoverflow.com/questions/39260595/event-handlers-in-react-stateless-components

const references are popped off the local stack when the function component have been used. Thus, when we re-render this function component again, it needs to re-create the const references and the objects that they point to.

By default, React.memo does does a shallow comparison of props and objects of props. Even so, because the onClick handlers are being recreated, our child component Counter will always see that the previous and current prop’s onClick handlers are referencing different objects. Thus, it will always re-render Counter2, even if we only update Counter1’s state.

The easy way to avoid this issue is to prevent the increaseCounter2 function from being recreated when the App is re-rendered.

We make use of React.useCallback to do this:

Now, when you run it, there will only be one handler function. That way, functional component Counter will get the same previous and current function object. Thus changing Counter 1’s state will only re-render Counter1. Counter2 will be untouched.

ref – https://reactjs.org/docs/hooks-state.html

Initially, there was function components, and class components:
– Functional components does not have state. Nor does it have lifecycle functions.
– Class components have state, and has lifecycle functions.

However, with the introduction of Hooks, in functional components, we now can have state and lifecycle functionality.

Hooks – JS functions that lets you ‘hook into’ React State and LifeCycle features within your functional component.

– DOES NOT work inside class components.
– ONLY call top level. Don’t call hooks inside loops, conditions, standard functions, or nested functions.
– ONLY call from Functional Components.

Many hooks exists. You can even write your own. Let’s take a look at an very basic hook, useState

When would I use a Hook?

If you write a function component and realize you need to add some state to it, previously you had to convert it to a class. Now you can use a Hook inside the existing function component. We’re going to do that right now!

Hook useState returns a pair of state. A state value, and a setState value.

Whatever name you get first is to get the state property. The second parameter you simply add a set to it to say you want to set this state property.
The 0 is the default value we want to give for our state property.

We use it like so. We declare count value, set its default to 0, and then declare its set functionality setCount.
We then can set it in our JSX.
In order to set new count, we simply use setCount.
In order to use it, we simply use the variable count.

UseEffect

The Effect Hook lets you perform side effects in function components

– Data fetching
– subscribing
– manually changing the DOM

are all examples of side effects. We call these operations “side effects” (or “effects” for short) because they can affect other components and can’t be done during rendering.

The Effect Hook, useEffect, adds the ability to perform side effects from a function component. It serves the same purpose as componentDidMount, componentDidUpdate, and componentWillUnmount in React classes, but unified into a single API. (We’ll show examples comparing useEffect to these methods in Using the Effect Hook.)

When you call useEffect, you’re telling React to run your “effect” function after flushing changes to the DOM.

Effects are declared inside the component so they have access to its props and state. By default, React runs the effects after every render — including the first render.

What does useEffect do? By using this Hook, you tell React that your component needs to do something after render. React will remember the function you passed (we’ll refer to it as our “effect”), and call it later after performing the DOM updates. In this effect, we set the document title, but we could also perform data fetching or call some other imperative API.

Why is useEffect called inside a component? Placing useEffect inside the component lets us access the count state variable (or any props) right from the effect. We don’t need a special API to read it — it’s already in the function scope. Hooks embrace JavaScript closures and avoid introducing React-specific APIs where JavaScript already provides a solution.

Does useEffect run after every render? Yes!

By default, it runs both after the first render and after every update. Instead of thinking in terms of “mounting” and “updating”, you might find it easier to think that effects happen “after render”. React guarantees the DOM has been updated by the time it runs the effects.

Example

We declare the count state variable, and then we tell React we need to use an effect. We pass a function to the useEffect Hook. This function we pass is our effect. Inside our effect, we set the document title using the document.title browser API. We can read the latest count inside the effect because it’s in the scope of our function. When React renders our component, it will remember the effect we used, and then run our effect after updating the DOM. This happens for every render, including the first one.

Experienced JavaScript developers might notice that the function passed to useEffect is going to be different on every render. This is intentional. In fact, this is what lets us read the count value from inside the effect without worrying about it getting stale. Every time we re-render, we schedule a different effect, replacing the previous one. In a way, this makes the effects behave more like a part of the render result — each effect “belongs” to a particular render.

When exactly does React clean up an effect? React performs the cleanup when the component unmounts. However, as we learned earlier, effects run for every render and not just once.

This is why React also cleans up effects from the previous render before running the effects next time.

We’ll discuss why this helps avoid bugs and how to opt out of this behavior in case it creates performance issues later below.

ref – https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects

Explanation: Why Effects Run on Each Update

Note – Update in this case means that the useState’s previous and current state are DIFFERENT
If the previous and current state are the same, then React will bail out, and none of the children of the component will be rendered.

If you’re used to classes, you might be wondering why the effect cleanup phase happens after every re-render, and not just once during unmounting. Let’s look at a practical example to see why this design helps us create components with fewer bugs.

Earlier on this page, we introduced an example FriendStatus component that displays whether a friend is online or not. Our class reads friend.id from this.props, subscribes to the friend status after the component mounts, and unsubscribes during unmounting:

But what happens if the friend prop changes while the component is on the screen? Our component would continue displaying the online status of a different friend. This is a bug. We would also cause a memory leak or crash when unmounting since the unsubscribe call would use the wrong friend ID.

In a class component, we would need to add componentDidUpdate to handle this case:

Forgetting to handle componentDidUpdate properly is a common source of bugs in React applications.

Now consider the version of this component that uses Hooks:

This behavior ensures consistency by default and prevents bugs that are common in class components due to missing update logic.

Mount with { friend: { id: 100 } } props
DOM gets updated. Causes previous clean up effect to be called.
There is none, so our to be called after the render.

Update with { friend: { id: 200 } } props
DOM gets updated. Causes returned effect clean up effect to be called.

Render complete, call current effect

Update with { friend: { id: 300 } } props
DOM gets updated. Causes returned cleanup effect function to be called.

Render complete. calls current effect

As times goes by…or when app quits, it will call update one last time.
The previous clean up effect function executes.
Causes returned cleanup effect function to be called.

Optimizing Performance by Skipping Effects

As shown, cleaning up and/or applying the effect after every render might create a performance problem in some cases.

In class components, we can solve this by writing an extra comparison with prevProps or prevState inside componentDidUpdate:

This requirement is common enough that it is built into the useEffect Hook API. You can tell React to skip applying an effect if certain values haven’t changed between re-renders. To do so, pass an array as an optional second argument to useEffect:

In the example above, we pass [count] as the second argument. What does this mean? If the count is 5, and then our component re-renders with count still equal to 5, React will compare [5] from the previous render and [5] from the next render. Because all items in the array are the same (5 === 5), React would skip the effect. That’s our optimization.

When we render with count updated to 6, React will compare the items in the [5] array from the previous render to items in the [6] array from the next render. This time, React will re-apply the effect because 5 !== 6. If there are multiple items in the array, React will re-run the effect even if just one of them is different.

This also works for effects that have a cleanup phase:

Creating basic custom Hook

We create a get and set for our property.
get property is pretty standard so we just leave it.

We can over the set property by declaring another function name and using the default set property function from useState.

After we’re done, we simply create a literal object, insert those properties, and return it

userOrderCount.js

We import it into main. Then simply use those properties as see fit. Put the get into the view.
Put the set as callback of the interactive controls.

App.js

ref –

• https://medium.com/@rossbulat/how-to-memoize-in-react-3d20cbcd2b6e
• https://dmitripavlutin.com/use-react-memo-wisely/
https://medium.com/@trekinbami/using-react-memo-and-memoization-1970eb1ed128
• https://medium.com/@reallygordon/implementing-memoization-in-javascript-5d140bb04166
• https://blog.bitsrc.io/improve-react-app-performance-through-memoization-cd651f561f66
• https://reactgo.com/react-usememo-example/

memoization source code

Memoization is the process of caching a result of inputs linearly related to its output, so when the input is requested the output is returned from the cache instantaneously.

Memoization is an optimization technique used to primarily speed up programs by storing the results of expensive function calls and returning the cached results when the same inputs occur again.

Say we have a simple function that calculates the Fibonacci number like so:

Say we put in a parameter of 5. We’d draw out a three of how our recursive calls would go. Where as we drill down to where parameter n is 0 or 1. That is the base case
where we return their respective numbers

recursiveFib(5)

recursiveFib(4) + recursiveFib(3)

recursiveFib(3) + recursiveFib(2) recursiveFib(2) + recursiveFib(1)

recursiveFib(2) + recursiveFib(1) recursiveFib(1) + recursiveFib(0) recursiveFib(1) + recursive(0) recursiveFib(1) + recursiveFib(0)

As you can see, we make calls to recursiveFib(2) three times. recursiveFib(1) five times. And recursiveFib(3) two times.

This is a lot of recalculations. The concept of memoization is to store them in a cache so that we only calculate each parameter once. Any future calls would simply take O(1) time and we can access the results immediately.

Here, we create a function that contains a key/value cache with a simple JS literal object called memo. Then we return our fib function from above. We put it just below memo. Since we return this function to elsewhere, our fib function can access memo via closure.

Before ANY kind of recursive calculation is done, we first comb through our memo to see if the n exists. If it exists, it means we have already processed it. We just access. If it’s not found, we move on to calculate the fib number for n. The recursion is exactly the same. Except that we make sure to put the result into our memo cache when done.

Going through the details

We start off by processing fib(5), which is fib(4) + fib(3)

By order, we then recurse fib(4), which is fib(3) + fib(2)

By order, we then recurse fib(3), which is fib(2) + fib(1)

By order, we then recurse fib(2), which is fib(1) + fib(0)

By order, we then recurse fib(1), which is the end case.
log “stored 1 to 1”
So we create new cache value 1 for key 1

Moving on to fib(0), its an end case. So we create new cache value 0 for key 0
log “stored 0 to 0”

The addition of both gives fib(2) = 1 + 0.
We create new cache value 1 for key 2.

On fib(3) = fib(2) + fib(1), we move on to fib(1)
Notice that we have a key/value in our cache for key 1. Hence we simply access it. This saves us calculation and processing time.

We then have fib(3) = 1 + 1 = 2.
We create cache value 2 for key 3.

On fib(4) = fib(3) + fib(2), we move on to fib(2). Notice again that key 2 already exists. We can save time again and just get the cache.

Finally, fib(4) = 2 + 1 = 3. We insert cache value 3 for key 4.

– Fibonacci recursive functions are a “pure” functions — that is, the same input value will always return the same output. This is a necessary condition for using memoization, as our cache needs to remember ONE SINGLE return values for the inputs.

– Memoization trades time for space — we must create a space in our cache for every input needed to calculate our result.

Memoization Components

We first create a state with input 0.
We then create a button that handles an input.
In the input, we put the # of times we want to repeat the input being changed to 8.

you’ll notice as we use setTimeout to change it the state 3 times to the value 8. The render function gets called 3 times, even though the state.input is always 8.

output:

input to 3
called setState
— render —
input 8
called setState
— render —
input 8
called setState
— render —
input 8

Improve with PureComponent

If we were to extend PureComponent, it actually shallow checks to see if the previous prop/state is the same as the current prop/state.
If its the same, we won’t re-render.

Simply change this line of code:

to

result:

Therefore PureComponent improves your performance.

Improving Performance with Memoization

Let’s write a simple function where we wait for some seconds.

In your fib function, right before you return a value, let’s simulate that the calculation takes 1 second.

So we put wait(1000) in front of all returns in our recursiveFib.

Let’s put recursiveFib in our render. Whenever we input a number, it calls setState in the input, and thus will call our render.

When we run all the code together, you’ll notice that it it gets stuck processing all the simulated processing time (of 1 sec) before the render.
So this is to simply show that if we have some calculations that take up a lot of time, and its hurting our render time, how do we further improve performance with memoization?

Because every single node must be calculated from scratch, we must calculate for a total of 9 nodes. If each node takes 1 second, then it takes 9 seconds.

output:
changed input to: 4
— render —
rendering fibonacii input of 4
waiting 1 seconds
waiting 1 seconds
waiting 1 seconds
waiting 1 seconds
waiting 1 seconds
waiting 1 seconds
waiting 1 seconds
waiting 1 seconds
waiting 1 seconds

So total processing time for standard fib is 9 seconds.

Let’s change by using our memoizationFib.

Now instead of 9 seconds, we simply wait 7 seconds.

output:

f(4)
App.js:106 f(3)
App.js:106 f(2)
App.js:106 f(1)
App.js:65 waiting 1 seconds
App.js:106 f(0)
App.js:65 waiting 1 seconds
App.js:65 waiting 1 seconds
App.js:106 f(1)
App.js:65 waiting 1 seconds
App.js:65 waiting 1 seconds
App.js:106 f(2)
App.js:65 waiting 1 seconds
App.js:65 waiting 1 seconds

The differences get bigger as the recursion increases.

For standard Fib(9) when you calculate everything, its 109 seconds.
Whereas if you use memoization, and save calculations, it only takes 17 seconds. This is because you avoid re-calculating subtrees.