220915 TIL

Facts(사실/ 객관)

[업무]

1. 리다이렉트 버그
2. 회원가입 social_code 버그 

3. 모바일 담화마켓 상세페이지 -> 상세페이지 뒤로가기시 느린 문제 원인 파악 

 

[공부]

1. On Demand ISR에 대해 더 알아봤다.

2. useState의 비동기, 동기 작업에 대해 알아봤다. 

 

[일상]

1. 재택이지만 아침점심저녁 모두 카페에 갔다. 

2. 어깨 운동을 했고 잠깐의 산책도 했다. 

 

---

Feelings(느낌,주관)

1. 크악 next 회고 전에 On Demand ISR 적용을 꼭 해보고 싶은데 감히 안잡힌다 ㅠㅠ
   
   
2. 화목에 재택이지만 아침 점심 저녁 모두 카페를 가는 신기록을 달성한 한 주가 됐다. 아침 점심은 그렇다고 하더라고 저녁먹고 
   배불러서 누워서 재밋는 영상보며 허비했던 저녁의 시간을 생산적으로 보낼 수 있어 뿌듯하다. 
   저녁먹고 카페 가서 2시간 공부 후 운동갔다가 씻고 집에서 못다한 공부 정리 및 TIL을 적으며 하루를 마무리 한다. 
   
   
3. 기존에는 운동을 50미만으로 설렁 설령 했다면 이번 주에는 1시간으로 늘리고 강도도 더 늘려봤다. 웨이트임에도 땀을 흘릴 정도로 더 열심히 하니 문득 딱 그 10분의 차이, 이왕 하는거 한 개라도 더 할려는 집념 그 작은 차이가 다른 결과를 만들겠다는 생각이 들었다.
   인생, 개발 실력도 마찬가지가 아닐까 싶다. 
   
   
4. useState을 맨날 쓰면서 비동기적 특징을 가진다는 사실도 모르고 있었다... 빠가야로 

---

Findings(배운점)

1. useState의 비동기 동작에 대해 배웠다. 

const [number,setNumbers]= useState(0);

const plusNumber = () => {
    setNumbers(numbers + 1);
    setNumbers(numbers + 1);
    setNumbers(numbers + 1);
}

<button onClick={plusNumber}>+3</button>

위 코드를 보면 onClick시 3이 증가할 것으로 보이지만 1씩 증가한다. 

그렇다면 useState은 왜 비동기로 동작할까? 

컴포넌트에는 수많은 상태값이 존재하는데 모든 상태가 바뀔 때마다 매번 렌더싱되다면 성능에 심각한 저해를 일으킴.
그렇기 때문에 리액트는 성능 향상을 위해 배치(batch)처리를 하여 여러개의 state 업데이트를 하나의 렌더링으로 묶는다고 한다. 

 

그렇다면 useState을 동기적으로 동작하게 하려면 ? 

1) 함수형 업데이트 

  const handlePlus = () => {
    setNum((num) => num + 1);
    setNum((num) => num + 1);
    setNum((num) => num + 1);
  };

2) useEffect 의존성 배열 

  useEffect(() => {
    console.log(num); // 항상 최신의 num을 볼 수 있다. 
  }, [num]);
  const handlePlus = () => {
    setNum((num) => num + 1);
  };

 

 

2. HeadLessCMS를 알게됐다

직역하자면 머리가 없다는 뜻인데, 여기서 머리란 컨텐츠를 보여줄 수단(웹사잍, ios, 안드로이드)를 의미하고 몸통은 컨텐츠를 의미한다. 

즉 머리(표현수단)을 언제든 바꿔 끼울 수 있다는 뜻이다.

컨텐츠와 view를 분리하는 것이 핵심이다

헤드리스 CMS는 콘텐츠를 생성/저장/관리하는 콘텐츠 관리 시스템만 제공하고 사용자들에게 콘텐츠가 보이는 부분은 API로 제공하는 시스템을 말한다. 이때 보여지는 것(view)은 단순히 테마나 스킨을 말한다기 보다 디바이스나 다양한 환경에 대응하는 보다 확장되는 개념인 것 같다. 이렇게 컨텐츠 관리 도구와 보여주는 시스템 분리시킨 이유는 컨텐츠를 여러 상황에 맞게 재사용하기 쉽고 새롭게 되입되는 기술을 접목하기 쉽게하기 위해서이다.

3. 웹훅에 대해 알게됐다. 

일반적은 API(Polling)는 클라이언트가 서버를 호출하는 방식인데 반해, 웹훅의 경우 서버에서 특정 이벤트 발생 시 

클라이언트를 호출하는 방식이다. 그래서 역방향 API라고도 부른다.