With Typescript
Great news! You don't need to explicitly type this.
useCallback also uses type inference (noticing a pattern, yet?).
const [state, dispatch] = useReducer(reducer, initialArg, init?)
A function that takes state and action as arguments and returns the next state of the app.
That definition isn't super helpful.
A reducer in React is just a function that takes the current state and an action, then returns a new state. Here's an example:
function reducer(state, action) {
switch (action.type) {
case "increment":
return { count: state.count + 1 };
case "decrement":
return { count: state.count - 1 };
default:
return state;
}
}
If React sends this action:
{ type: "increment" }
The reducer function thinks
Okay, I'll increase the count by 1
useState?A good rule of thumb is simple state = useState, complex state = useReducer.
With useReducer, instead of directly changing state like this:
setCount(count + 1);
You dispatch "actions" to the reducer, and it decides what the new state should be, e.g.:
dispatch({ type: "increment" });
const [state, dispatch] = useReducer(reducer, initialArg, init?)
reducer: The reducer function that specifies how the state gets updated. It must be pure, should take the state and action as arguments, and should return the next state. State and action can be of any types.initialArg: The value from which the initial state is calculated. It can be a value of any type. How the initial state is calculated from it depends on the next init argument.init: The initializer function that should return the initial state. If it's not specified, the initial state is set to initialArg. Otherwise, the initial state is set to the result of calling init(initialArg).useReducer returns an array of two values:
A reducer must be a pure function. What is a pure function?, a pure function is a function that relies solely on its input parameters, and does not take into account any outside variables or state in returning a value.
A pure function must also not mutate its arguments.
This is pure:
function addNumbers(numberOne, numberTwo) {
return numberOne + numberTwo;
}
This is impure:
const numberToAdd = 3;
function addNumbers(numberOne) {
return numberOne + numberToAdd;
}
It is also worth remembering that a pure function must never mutate its arguments, e.g.:
const [questions, setQuestions] = useState([]);
function addQuestion(currentState, newQuestion) {
currentState.push(newQuestion);
return currentState;
}
addQuestion(questions, 'new question to add');
This is impure because it is directly mutating the questions state, by pushing to it.
Instead, do this:
const [questions, setQuestions] = useState([]);
function addQuestion(currentState, newQuestion) {
return [...currentState, newQuestion];
}
addQuestion(questions, 'new question to add');
Forms are a great place to make use of useReducer, as they often have complex state objects that need to be managed efficiently.
const initialFormState: FormStateType = {
name: '',
email: ''
}
interface FormStateType {
name: string;
email: string;
}
interface ActionType {
type: string;
field: string;
value: string;
}
function formDataReducer(state: FormStateType, action: ActionType) {
switch (action.type) {
case 'FIELD_CHANGED':
return {
...state,
[action.field]: action.value
}
case 'FORM_CLEARED':
return {
...initialFormState
}
default:
return {
...state
}
}
}
const [formData, dispatchFormData] = useReducer(formDataReducer, initialFormState);
This is a textbook example. Here, we're able to update form fields and clear the form (and add any other logic we want), in a single reducer function.
Here's an example of what the form component's code would look like:
<form action="">
<input
type="text"
name="name"
id="name"
value={formData.name}
onChange={e =>
dispatchFormData({
type: 'FIELD_CHANGED',
field: 'name',
value: e.target.value,
})
}
/>
<input
type="email"
name="email"
id="email"
value={formData.email}
onChange={e =>
dispatchFormData({
type: 'FIELD_CHANGED',
field: 'email',
value: e.target.value,
})
}
/>
</form>
]]>
useCallback(fn, dependencies)
Right. Let's do this.
React does too much. Every time your component re-renders, everything inside of it (including your functions) are re-created.
Even if your function hasn't changed, React sees a "new" version on every render.
Usually, this isn't an issue, but it becomes an issue when you're passing the function down to a child that's trying to maintain efficiency.
The problem: Without useCallback, a child component might re-render unnecessarily because it thinks it received a "brand new" function from the parent, even if nothing actually changed.
The solution: useCallback Ensures the function maintains the same "identity" across renders.
useMemo Memoises (remembers) the result or the value returned by a function.
function AdditionComponent(firstNumber, secondNumber) {
const additionResult = useMemo(() => {
return firstNumber + secondNumber;
}, [firstNumber, secondNumber]);
}
In this case, useMemo will cache the value returned by the additionResult function. So if firstNumber = 1 and secondNumber = 2, the cached result will be 3.
useCallback remembers (caches) the function itself.
function AdditionComponent(firstNumber, secondNumber) {
const handleAddition = useCallback(() => {
return firstNumber + secondNumber;
}, [firstNumber, secondNumber]);
}
In this case, useCallback caches the function itself, and will only re-create the function if either of its dependencies (firstNumber or secondNumber) change.
function AdditionComponent(firstNumber, secondNumber) {
const additionResult = useMemo(() => {
return firstNumber + secondNumber
}, [firstNumber, secondNumber]);
}
Note: useCallback is essentially just a specific implementation of useMemo, designed only to store functions. Caching a value? Use useMemo. Caching a function? Use useCallback
Great news! You don't need to explicitly type this.
useCallback also uses type inference (noticing a pattern, yet?).
useRef(initialValue)
Hopefully this should be a quick one.
useRef is used for storing a value across renders, without causing a re-render when it is changed.
useState causes the component to re-render when it is changed.
useRef doesn't cause the component to re-render. Simple, really.
useRef is mutable. Which means it can be changed.useRef returns an object with property current.useRef's value, update the current property, like below:const numberRef = useRef(0); numberRef.current = 5; numberRef.current += 1; // numberRef is now equal to 6
Let's say you want to create a React hook called useTimeout which invokes a callback after a specified delay. The hook should always invoke the latest callback it is given, without restarting the running timeout.
function useTimeout(delay, callback) {
const latestCallback = callback;
latestCallback.current = callback;
useEffect(() => {
const timeoutId = setTimeout(() => {
latestCallback.current();
}, delay);
return () => clearTimeout(timeoutId);
}, [delay]);
}
Here, we're persisting latestCallback across renders, and reassigning its current property if a new callback function is received, without causing the existing timeout to be restarted.
Most commonly however, you'll see useRef attached to components/elements using the special ref attribute, e.g.:
const inputElementRef = useRef(null);
...
<input type="text" ref={inputElementRef} />
This enables us to access and perform operations on the underlying component by accessing inputElementRef.current, e.g.:
inputElementRef.current.focus();
useMemo is your way of telling React to be lazy.
useMemo(calculateValue, dependencies)But what does that mean?
useMemo acts as a store of a value. It stores the result of a function so that React doesn't have to re-calculate it every time the component re-renders.
Here's an example. Say we have component that has to render a list of 100,000 items:
function SearchList({ items, query }) {
// This runs on EVERY single render, even if 'items' hasn't changed!
const filteredItems = items.filter(item => item.includes(query));
return <ul>{filteredItems.map(i => <li key={i}>{i}</li>)}</ul>;
}
Even if items doesn't change, the filter function will be called every time the component re-renders.
This is, obviously, shit.
The solution in this case is to use useMemo, to store the filtered items array between re-renders.
const filteredItems = useMemo(() => {
return items.filter(item => item.includes(query));
}, [items, query]); // Only re-run if 'items' or 'query' change
calculateValue argumentcalculateValue is?const addedNumbers = useMemo(() => {
return numberA + numberB;
},[numberA, numberB])
In this scenario, if either numberA or numberB change, the function that adds them together will be re-called.Simple, right?
dependency array argumentThis is just the same as the useEffect dependency array. If any of the values in the array change, the calculateValue function will be called.
If you don't pass a dependency array to useMemo, it essentially becomes useless.
No dependency array? Then the calculateValue function is called every render. And that's very silly isn't it, because that's what we're trying to avoid here.
Another good question,
If you pass an empty dependency array to useEffect, you're telling React:
"Run this code exactly once, and then never touch it again."
Great news! You don't need to explicitly type this.
useMemo also uses type inference (noticing a pattern, yet?).
const addedNumbers = useMemo(() => {
return numberA + numberB;
},[numberA, numberB])
This calculateValue function returns a number, so Typescript will infer that it should always return a number.interface UserData {
id: number;
name: string;
}
const formattedData = useMemo<UserData>(() => {
return {
id: 69,
name: "Dan"
}
},[numberA, numberB])
I'll start by saying I think useEffect is a stupid name.
Long story short, useEffect is a way to tell React "After you've finished updating the DOM, run this extra bit of code."
Here's how it should be called:
useEffect(setup, dependencies?)But what does that even mean?
setup argument
setup is the logic function of the "effect".const [count, setCount] = useState(0);
useEffect(() => {
document.title = `You clicked ${count} times`;
}, [count]);
The dependency array argumentIn the example above, we called useEffect with [count] as the dependencies argument. This means that our useEffect function is "listening" for the count state variable to change. It will call the setup function whenever count changes.
Also, as a bonus, it will also run whenever the component mounts.
Go ahead, try it, I dare you. Reload the page. Notice how the page title is already Count: 0 before you've even pressed the button?
Good question. And here's a good answer.
If you don't pass a dependency array to useEffect, the setup function will be called on every single re-render.
...so (except in rare circumstances), it's probably best to pass a dependency array. Or not. I don't care really.
Another good question.
If you pass an empty dependency array to useEffect, you're telling React:
"Run this code exactly once, and then never touch it again.".
This is useful for things like API calls, when you only want to fetch data from the server once when the page loads.
This is actually quite easy to explain. If you return a function from the setup function, congratulations, that's a cleanup function.
useEffect(() => {
document.title = `Count: ${count}`;
// Here's your cleanup function
return () => {
document.title = "Count cleared";
}
}, [count]);
When is the cleanup function called? Whenever the component unmounts.
Think of it as turning the TV off and locking the doors before you go out. The cleanup function is used to tidy up your mess before the component unmounts. It's useful for things like:
A common use-case is for tearing-down things like event listeners:
useEffect(() => {
const handler = () => {
...
};
window.addEventListener("click", handler);
return () => window.removeEventListener("click", handler);
}, []);
That way, we clean up event listeners each time the dependencies change.
Great news! You don't need to explicitly type this, useEffect also uses type inference.
Here's an example:
useEffect(() => {
document.title = `Count: ${count}`;
}, [count]);
In this case, typescript will infer that the dependency array will be an array which matches the type of count, which is a number.The setup function, should be exactly that... a function. Not an async function. Just a regular old function.
If you need to do async stuff inside the useEffect setup function, it should be wrapped inside a regular, synchronous function, like this:
useEffect(() => {
const performAsyncTask = async () => {
// async logic here
};
performAsyncTask();
}, []);
Not like this:
useEffect(async () => {
const data = await fetchData();
}, []);
Because you'll get the following error:
Argument of type '() => Promise<void>' is not assignable to parameter of type 'EffectCallback'.
Type 'Promise<void>' is not assignable to type 'void | Destructor'.
It's simple. React's useState hook stores state.
const [count, setCount] = useState(0);
count is the state variable, and setCount is the updater or "set" function, which is called to update the state.setCount like this:setCount(newValue);
Each time the state is changed, the entire component will be re-rendered.
Great news! You don't need to explicitly type this.
Ready for some real developer jargon? useState is designed with type inference.
What does that mean? No one knows what it means, but it's provocative.
No, actually, we do know what it means. It means that Typescript is clever enough to look at what type you set the state variable to initially, and just use that, forever.
const [count, setCount] = useState(0);In this case, typescript will infer that
count should be a number, forever.setCount with a string, you'll find out, and Typescript will moan at you.
onClick={() => setCount("test") //attempting to set count to string
Argument of type 'string' is not assignable to parameter of type 'SetStateAction<number>'.
const [count, setCount] = useState(0);Do this:
const [count, setCount] = useState<string | number>(0);Now
count can be either a string or a number.useId is pretty much all basics. It doesn't take any arguments.
const id = useId();
It's just an easy way of generating a random, unique ID for an element.
Why? Well, there's a few benefits:
useId avoids collisions by default. Even if a component is rendered multiple times on the same page, useId ensures that all of the components have unique ID attributes.useId creates an ID on the server. Then during client hydration, it will use the same ID, preventing hydration errors.Here, we generate IDs for each input, and the form itself, using useId.
Then we can use the generated IDs for both the inputs and the input labels, to ensure they are always consistent with one another.
const FormComponent = () => {
const formID = useId();
const nameInputID = useId();
const emailInputID = useId();
return (
<form action="" id={formID}>
<label htmlFor={nameInputID}>Name:</label>
<input type="text" name="name" id={nameInputID} />
<label htmlFor={emailInputID}>Email:</label>
<input type="email" name="" id={emailInputID} />
</form>
)
};
Here's the benefit, if we render that component multiple times, each instance will have its own set of unique IDs, which avoids having invalid HTML due to repeated element IDs:
<form action="" id="_S_1_">
<label for="_S_2_">Name:</label>
<input id="_S_2_" type="text" name="name">
<label for="_S_3_">Email:</label>
<input id="_S_3_" type="email" name="">
</form>
<form action="" id="_S_4_">
<label for="_S_5_">Name:</label>
<input id="_S_5_" type="text" name="name">
<label for="_S_6_">Email:</label>
<input id="_S_6_" type="email" name="">
</form>
If we used hard-coded idattributes on the component, if we were to re-use the same component multiple times on the page, we'd have repeated element IDs.