#220816

1. FileReader (기존 이미지 방식 비효율적)
2. Promise.all (async / await for문 x, 모아서 전송)
3. LazyLoad / PreLoad (원할 때 이미지 불러오기)

---

지난번 이미지 업로드 방식

대표적인 문제점

1. 글 작성하고 글 등록한 상태(6번)에서 다른 페이지로 나감
2. 2번까지 했을 때 브라우저에는 파일이라는 객체가 있는데, 지금 같은 경우는 7번까지 와야지 미리보기 그림이 그려지고 있음(이미지 찌꺼기 (storage에 저장하고 이동하면 찌꺼기가남음)) → 미리보기가 너무 느림

2번까지만 하고 미리보기가 가능하게 개선

FileReader를 사용해서 업로드 이전에 미리보기 보여주기

• 다른 페이지로 이동하더라도 Storage에는 쌓이지 않음
• 미리보기 속도 빠름

5번 업로드하면 for문으로 5번 요청(async, await) 해야 하는 비효율적인 방식
→ Promise.all을 통해 1번을 효율적으로 만들기 (동시 실행, 1번 await)

엄청 긴 이미지 주소

2번 날라감

Promise All
확장자 webp
파일 드래그 앤 드롭 라이브러리

react-dropzone

LazyLoad
필요한 사진을 그때그때 다운로드

PreLoad
미리 다운로드

이거 설정하고 보면 일반 다운로드는 엄청 느림

220817

1. Memoization
2. @media

---

1. state(counter) 바뀌면 해당 컴포넌트가 리렌더링
2. 리렌더링 전의 변수가 초기화되는지 ⇒ 새로 만들어지는지
3. 함수도 초기화되는지 ⇒ 새로 만들어지는지
4. 자식도 리렌더링이 되는지

memo
자식이 리렌더링 되는걸 방지 (부모만 highlight)
useMemo로 나만의 useCallback 만들기

const onClickCountState = useMemo(
    () => () => {
      setCountState((prev) => prev + 1); // countState + 1 (x)
    },
    []
  );

memo를 쓰지 않을 때 안좋은 예시
React: render optimization for Material UI collapsible list using Hooks and Memo.

Wappalyzer
노션 스택

PWA : 다운로드 할 수 있게

적응형
width: 1024-1280 사이(작은 노트북에서도 보기 위함)

반응형
모바일 / 태블릿 / PC → css 3개 만들기

bootstrap 의 규격을 따라 작성
1. css를 3단계로 구분 → css 작업 3배
2. 기준이 바뀌었을 때 바꾸기 어려우니까 따로 변수를 만들고 breakPoints 만들어서 import 하기

모바일 : 가장 많이 사용되는 기종의 사이즈로 개발
늘리는건 문제가 없는데 줄이는건 문제가 있을 수 있으므로

1. 모든 모바일 기종에서 다 잘나와야 할 것인가?
   → Yes → 가장 작은 사이즈를 기반으로 개발
   → No → 가장 많이 사용되는 사이즈를 기반으로 개발

💡
rem ⇒ body사이즈의 영향을 받음 (body가 작아지면 폰트가 모두 일괄적으로 작아짐)
em ⇒부모사이즈의 영향을 받음(부모가 작아지면 폰가가 일괄적으로 작아짐)

https://nekocalc.com/px-to-rem-converter

CSS가 성능에 미치는 영향(Critical Rendering Path)

브라우저에 그림이 그려지는 순서

• 다운로드 → html, css 합치기 → 위치그리기 (Layout/Reflow) → 색칠하기 (Paint/Repaint)

결론
메모이제이션 : 성능최적화 (큰 프로젝트에 체감)
반응형 디자인: 하나의 서비스로 모바일/태블릿 시각화, 무조건 정답은 아님
반응형 모바일 : PWA : 모바일에 기능을 주는것. 이게 없으면 따로 app을 만들어야 함

220818

1. Optimistic UI
2. Open-Graph / SSR
3. SEO

---

Optimistic UI

요청이 서버에 도달하기도 전에 화면의 값을 바꿔버리는 것
성공확률이 99% 인 요청에 적용
실패하더라도, 큰영향이 없는 요청에 적용 ( 결제 같은 곳에는 적용 x)

• fetchPolicy: cache-first
  1. 쿼리를 사용할 때 캐시를 확인한다. (캐시 : 데이터나 값을 미리 복사해 놓는 임시 장소)
  2. 캐시 데이터가 있으면 이를 반환한다. 없으면 3단계로 넘어간다.
  3. 서버에 쿼리를 사용해서 데이터를 요청한다.
  4. 캐시 데이터를 업데이트한다.
  5. 받아온 데이터를 반환한다.

Scraping / Crawling
1번가지고오면 Scraping (라이브러리 : cheerio)
정기적으로가지고오면 Crawling (라이브러리 : puppeteer)

해당 API endpoint에 GET요청

💡 Q : 안되는 사이트들은 먼가요?

A : CORS 때문에 브라우저인 네이버에 접근 못함
→ 모바일이나 백엔드(proxy)에서 요청 시 가능 (openapi할 때 했음)

백엔드 과정 이해 ⇒ 서버 사이트 렌더링까지 연결