This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
export const useGetViewPort = () => { | |
const [width, setWidth] = useState(window.innerWidth); | |
useEffect(() => { | |
const handleWindowResize = () => setWidth(window.innerWidth); | |
window.addEventListener("resize", handleWindowResize); | |
return () => window.removeEventListener("resize", handleWindowResize); | |
}, []); |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
import { useState, useEffect, Dispatch, SetStateAction } from "react"; | |
type Response<T> = [ | |
T, //? What's inside the "state" Ex: string, boolean... | |
Dispatch<SetStateAction<T>> //? type of "setState" | |
] | |
//? "useLocalState<T>" accepts a type unknown | |
export function useLocalState<T>(key: string, initialState: T): Response<T> { |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## What? | |
Explain the changes you’ve made. It doesn’t need to be fancy and you don’t have to get to technical, yet. Just explicit prose on your net change will typically suffice. At a high level, this is where you let the reviewer know the overall effect of the PR. Reference a ticket in your issue tracker if appropriate, but by all means, don’t just reference the ticket. It’s important to explain what the change is and then and only then reference the ticket. It’s a much better experience for the reviewer if they’re able to spend more time reviewing code and less time studying specification that may not even be applicable on the code level. | |
## Why? | |
The “why” is sometimes more important than the “what” of a code change, but we tend to put it after the “what” since we aren’t evaluating theory, we’re evaluating tangible code changes. | |
The “why” tells us what business or engineering goal this change achieves. It’s the reason we get paid as developers. The “why” is a chance to explain both the engineering goal, bu |