왜 나왔을까?

페이지 전환없이 앱같은 느낌을 원함

• SPA - 한 페이지에서 내부데이터만 갈아끼우기에 데이터 유지에 좋다.(사용자 피로감 또한 적어짐)

프론트의 비중이 점점 높아짐(데이터를 많이 다룸)

• MVC 패턴 등의 개발 방식은 대규모 개발에 적합치 않음 -> Flux 패턴
  

• Flux 패턴은 단방향이기 때문에 에러 추적이 훨씬 쉽기에 대규모에 더 적합하다.(Redux도 Flux였죠..?)

한페이지에 HTML,CSS,JS 모두 존재

• 관리가 힘듦 -> JSX 문법의 등장
• 컴포넌트로써 관리하기 편해짐
• jsx는 브라우저가 알아듣지 못하기에 웹팩,바벨,swc(한국인이 만듦 ㄷㄷ) 등 툴로 js로 변환해주어야함

언제 state를 써야 하는가 & JSX 특징

• state를 추가할 땐 불변성을 지켜줘야 한다.
  참조하는 객체를 다르게 만들어주기 위해 깊은 복사로 새로운 메모리 주소를 참조하는 객체를 만들어서 이를 todo에 넣어주는거겠지?(내 생각엔 이렇게 이해가 됨)

const nextTodo = [...todo, {title : newTodo, completed : false, id : Math.random()}]
setTodo(nextTodo)

props와 부모자식간 데이터 흐름

• 부모 -> 자식 props 바꿀 수 있음, 자식 -> 부모 state 못바꿈 but, set함수 등 바꿀 수있는 함수를 받는다면 ok
• 고차함수로 자식에 있는 state를 활용할 수 있음

// 부모
const onSubmit = (newTodo) => (e) => {
 const nextTodo = [...todo, {title : newTodo, completed : false, id : Math.random()}]

 //자식
 const [newTodo, setNewTodo] = useState('')
 
 const onSubmit = (e) => {
   e.preventDefault()
   onParentSubmit(newTodo)
}

• 부모로부터 state를 안받아온다면 아래와같이 쓸 수 있다.(state에서 이전 상태를 제공해주니까)
  하지만 set함수를 전달해주면 자식이 setter함수를 오남용할 수 있기 때문에 위보다 덜 안전한 방식이다

const onChange = (e) => {
 setTodo((prevT) => {
  const nextTodo = [...prevTodo];
  nextTodo[index] = {...nextTodo[index]};
  nextTodo[index].completed = e.target.check;
  return nextTodo
 })
}

React의 라이프 사이클(useEffect)

• useEffect의 deps에 객체를 넣을 땐 주의하자

const a = {} 
useEffect(() => {
  
},[a])
a.hi = n // effect가 감지 x
a = {} // effect가 감지 o

• useEffect 실행 순서

useEffect(() => {
  // 컴포넌트가 마운트될 때 실행
  return () => {
   // 컴포넌트가 언마운트될 때 실행 
  }
},[])
useEffect(() => {
  a() // todo가 바뀔 때마다 실행
  return () => {
    b()
    // todo가 바뀌기 직전에 실행
  }
},[todo])
// useEffect들이 마운트될 때 순차적으로 실행 후 deps배열에 따라 실행
// todo가 a -> b로 변하게 되면 a -> a cleanup -> b 순서로 실행된다.
// 즉 cleanup이 실행된 후 새로 useEffect가 실행되는 순서를 지키고있음.

자료 및 강의 출처 : ZeroCho TV