리액트 프레임워크

SEO(Search Engine Optimization)을 위한 SSR(Server-Side Rendering) 때문에 많이 쓴다고 알고 있다.

넥스트에서 제공하는 튜토리얼을 해석하면서 왜 쓰는지 알아봐야겠다

Create a Next.js App

완전한 리액트 웹 어플리케이션을 빌드하라면 고려해야할 중요한 사항들이 있음

• 코드는 웹팩같은 번들러에 의해 번들링되어야하고, 바벨같은 컴파일러에 의해 변환(transform)되어야함.
• 코드스플리팅같은 프로덕션 최적화를 해야함.
• SEO와 성능을 위해 어떤 페이지를 정적으로 프리렌더를 원하고 싶을 수 있음. SSR, CSR을 사용하고 싶을 수도 있음
• 리액트 앱을 데이터 저장소에 연결하기 위해 서버쪽 코드를 작성해야할 수도 있음

💡 참고 )

• 번들링? 모듈화했던 파일들을 하나로 묶어주는 작업 https://kangdanne.tistory.com/190
• 바벨? 구식 브라우저 환경에서 호환가능한 코드로 변환하는 데에 사용되는 트랜스파일러
• 컴파일 vs 트랜스파일 컴파일은 다른 언어로 변환, 트랜스파일은 비슷한 수준의 추상화를가진 다른 언어로 변환(ex. es6 → es5) https://ideveloper2.tistory.com/166
• 코드스플리팅? 당장 필요없는 코드는 나중에 필요할 때 불러오는 방식 https://velog.io/@velopert/react-code-splitting

프레임워크는 이런 문제들을 해결할 수 있다. 사용하기 좋게 올바른 수준의 추상화를 가지고 있어야하고, DX도 좋아야 함.

Next.js: The React Framework

넥스트가 개발자 경험을 위해 겨냥하고 있는 것들

• 직관적인 페이지 기반 라우팅 시스템 (동적 라우트 지원)
• 페이지단위로 지원 하는 프리렌더링, SSG, SSR
• 빠른 페이지 로딩을 위한 자동 코드 스플리팅
• 최적화된 prefetch를 통한 클라이언트 사이드 라우팅
• Fast Refresh 개발 환경
• 확장 어쩌고..

자세한 예시

동적 라우트

• pages/blog/[slug].js → /blog/:slug (/blog/hello-world)
• pages/[username]/settings.js → /:username/settings (/foo/settings)
• pages/post/[...all].js → /post/* (/post/2020/id/title)

클라이언트 사이드 라우팅(Client-side routing)

<Link /> 컴포넌트 제공

뷰포트 안의 링크 컴포넌트는 SSG를 사용하는 페이지에 대해 기본적으로 프리페치(prefetch)됨. 서버에서 렌더된 라우트에 의한 데이터는 프리페치 되지 않음.

→ 이게 뭔 소리냐면 링크 컴포넌트가 화면에 보이면 링크 클릭 안해도 넥스트에서 링크랑 연결된 페이지 코드를 미리 로드함. 그래서 페이지 전환이 부드러움

새로고침도 안함. 이전에 받아온 데이터는 서버에 요청도 다시 안함.

참고로 Link 컴포넌트를 쓸 때, 칠드런으로 <a> 를 왜 넣어야할까? 안 넣어주면 next에서 if문으로 알아서 넣어주는 부분이 있긴함

공식 문서 설명을 좀 더 찾아보니, <a> 태그로 href 어트리뷰트를 넣어서 SEO에 손상이 가지 않게 하려고.

프리렌더링

기본적으로 넥스트는 모든 페이지에 프리렌더가 적용됨. 이게 무슨말이냐면 넥스트가 매 페이지를 미리 html로 생성(generate)한다는 거임.

생성된 html은 그 페이지에 필요한 최소한의 자스 코드랑 연결됨. 브라우저에 의해 페이지가 로드되면, 자스 코드가 실행되고 페이지를 완전 interactive하게 만들어줌. (이 과정을 hydration이라고 부름)

프리렌더링에는 두 가지 형태가 있음. HTML을 생성하는 방식에 차이가 있음.

• Static Generation(추천됨): HTML을 빌드 타임에 각 페이지별로 생성하고 해당 페이지로 요청이 올 경우 이미 생성된 HTML 문서를 반환
• Sever-side Rendering: HTML은 매 요청마다 생성될 것임.

넥스트에서는 위 방식을 매 페이지마다 고를 수 있긴함.

넥스트에서는 성능상의 이유로 SSR 보다는 SSG를 사용하길 추천함. 정적으로 생성된 페이지는 성능 향상을 위한 추가 구성 없이 CDN에서 캐싱될 수 있음.

클라이언트 측 데이터 페칭으로, 페이지의 일부는 클라이언트 측 자스로 완전히 로딩될 수도 있음.

다음 편에는 SSG, SSR, Hydration에 대해 알아보겠음.

에러바운더리란?

https://ko.reactjs.org/docs/error-boundaries.html#gatsby-focus-wrapper 명령형 대신 선언형으로 에러를 처리하기 위해 회사에서 쓰고 있다.

에러바운더리에서 에러를 캐치하지 못하는 경우

에러바운더리로 컴포넌트를 감쌌으나, 이 에러바운더리도 캐치하지 못하는 에러들이 있다. 공식문서에서도 알려준다.

Note

에러 경계는 다음과 같은 에러는 포착하지 않습니다.

이벤트 핸들러 (더 알아보기)
비동기적 코드 (예: setTimeout 혹은 requestAnimationFrame 콜백)
서버 사이드 렌더링
자식에서가 아닌 에러 경계 자체에서 발생하는 에러

그래서 내가 겪은 문제

비동기 처리를 할 때, 에러가 나니까 에러바운더리에서 걸러내지 못하고 Uncaught Error가 떴다. 찾아보니 에러바운더리도 캐치하지 못하는 에러가 있었다. https://www.smashingmagazine.com/2020/06/react-error-handling-reporting-error-boundary-sentry/ 그럼 이것을 어떻게 에러바운더리나 선언형으로 걸러내지? 명령적 해결 - https://wani.kr/posts/2015/03/09/js-something-2-catchable-settimeout-exception/

선언적 해결 - https://jbee.io/react/error-declarative-handling-3/ unhandledrejection event를 사용한다. 참고로 catch하고 버블링되는 걸 막지 않았더니 uncaught에러가 났다. 멍청이..

상태란?

주어진 시간에 대해 시스템을 나타내는 것으로 언제든지 변경될 수 있음.

문자열, 배열, 객체 등의 형태로 응용 프로그램에 저장된 데이터!

→ 개발자 입장에선 관리해야하는 데이터들

모던 웹 프론트엔드는 프로덕트가 커져서 관리해야할 상태도 많아졌음.

React Query와 상태관리 주제를 가지고 온 이유

주문 FE 프로덕트를 보며 가진 고민

너무 많은 레포.

반복되는 컴포넌트, 로직..

Redux로 구성한 Store 코드인데, 상태관리보단 API 통신 코드같다.

• API 관련 코드가 Store에?
• 반복되는 isFetching, isError 등 API 관련 상태
• 반복되는 비슷한 구조의 API 통신 코드

(이때는 rtk 같은 게 없었다고 함)

소유주가 Client냐 Server냐에 따라 상태를 두 가지로 나누어 보자.

Client State. Server State.

소유주가 Client냐 Server냐에 따라.

배민 주문팀에서는 React Query 기술을 채택했다.

React Query

fetching, caching, synchronizing and updating server state.

zero-config, can be customized.

로 감싸고 있음.

컨텍스트와 비슷한데?

사용은 useQuery

세가지 core 컨셉

Queries. Mutations. Query Invalidation.

Queries

데이터 Fetching 용!

userQuery(’todos’, fetchTodoList, option) // query key, query function, option

qeury keyDP 따라 query caching을 관리.

string과 array형태로 사용할 수 있음.

queries 파일 분리 추천!

redux에서 언제 server state를 받을까? → onSuccess단계가 좋다고 생각한다.

Mutations

데이터 생성/수정/삭제용!

useMutation(mutationFn,

onMutate는 Optimistic update를 적용할 때 유용

api 요청을 성공할 것이라고 보고 UI 업데이트. 롤백 가능.

Query Invalidation

queryClient.invaldateQueries()

query가 stale 취급 된다.

Caching하고 Synchronization은 리액트 쿼리가 어떻게 알아서 하나?

RFC 5861

stale-while-revalidate

→ 백그라운드에서 stale response를 revalidate 하는 동안 캐시가 가진 stale response를 반환

Cache-Control: max-age=600, stale-while-revalidate=30

600초 동안은 유효한 값이라고 생각한다.

latency가 숨겨짐.

새 물건이 올 때까지 옛날 물건을 보여준다.

( 이 부분은 조금 더 공부 후에 채워 놔야겠다. )

이 컨셉을 메모리 캐시에도 적용해보자!

cacheTime: 메모리에 얼마만큼 있을건지

staleTime: 얼마의 시간이 흐른 후에 데이터를 stale 취급할 건지.

Query 상태흐름

fetching → fresh → stale → inactive → deleted

스크린에서 빠져나갈때 stale→inactive

다시 mount되어도 fresh한 값이면 refetch가 일어나지 않음.

그럼 React Query는 어디에서 값을 관리할까요?

전역으로 관리될까?

중복호출 될까?

답은 Context API에 있다.

내부적으로 컨텍스트를 이용함!

주문 팀에서는 어떻게 바뀌었나?

Store는 Client State만 남았다!

Server State는 React Query와 함꼐 좋아졌다!

Component는 쬐끔 길어졌지만 수용가능한 범위.

사용하면서...

다른 상태관리라이브러리들보다 직관적이다!

고민해야할 문제

Component가 상대적으로 비대해지는 문제

좀 더 난이도가 높아진 프로젝트 설계

단순 API 통신 이상으로 장점을 잘 활용할 방법

나도 써야하나?

역시 중요한건 트렌드보단 Why!

추가 질문

swr과 다른점?

리액트 쿼리가 더 많은 인터페이스를 제공함.

Client 스토어?

Mobx

query 키?

함수명으로 자주 씀

디폴트 옵션?

안씀

에러바운더리?

안씀! Suspense는 실험단계라서 안씀!

시간 날 때 내용 수정 및 추가 해야겠다...

찾아보니 CreateAsyncThunk에서 getState 옵션으로 바로 store에 접근할 수 있었다! https://redux-toolkit.js.org/api/createAsyncThunk

async (_, { getState }) => {} 이런 식으로 처리하면 된다.

근데 이렇게 처리해도 괜찮을까? redux의 데이터 흐름을 막 쓰게 되는 거 아닐까?

이것에 대한 답변을 이 글에서 찾아보려고 한다.

2022-03-05 추가 글

TL;DR redux제작자 Dan Abramov 는 주의해서 사용해야한다고 했음. 현재 Redux 유지 관리자 Mark Erikson은 괜찮다고함.

Dan Abramov - "thunks에서 getState 쓰지 마세요! Dan Abramov가 2월 스택오버플로에 답했는데, 아래처럼 쓰여있었습니다.

액션 크리에이터에서 상태에 접근하는 것은 anti-pattern이고, 가능하다면 피해야합니다. 접근해도 괜찮다고 생각되는 몇가지 사례는 요청을 보내기 전에 캐시된 데이터를 확인할 때, 권한이 있는지 체크할 때입니다.state.something.items와 같은 데이터를 액션 크리에이터에서 전달하는 것은 명백한 anti-pattern이고 이해하기 힘든 변경 이력을 가지기 때문에 장려되지 않습니다. 만약 버그가 있고 items가 부정확하다면, 이미 액션의 일부이기 때문에 어디서 잘못된 값이 왔는지 추적하기 힘듭니다. 그러니까 주의를 가지고 사용해야합니다.

그 후로 저 코멘트에 몇몇 사람이 혼란스러워 하는 걸 봤습니다. "thunk에서 getState는 가능하지만 사실상 못쓴다면, 어떻게 해야하나요?". 지금은 "가능하다면 피해라"를 사람들이 "절대 쓰지마"로 해석하고 있지만, Dan이 스택오버플로에서 말한 사실은 사람들이 그것을 복음처럼 받아들이도록 만든다.

MarkEricson의 후반부 글.

물론, 정말 복잡한 응답 처리 로직을 가지고 있다면 중앙집중화되어야할지도 모릅니다. 하지만, 대다수의 어플리케이션은 요청하고, 액션을 디스패치하고, 완료하는 것이 간단할 것이라고 생각합니다. 중앙집중화할 것이 별로 없죠.

"단방향 데이터 흐름을 깨는 상태에 액세스"에 저는 전혀 동의하지 않습니다. 단방향 데이터 흐름의 개념은 데이터 업데이트가 한 곳에서 적용되어 시스템을 통해 전파된다는 것입니다. 일반 React 애플리케이션에서 이는 컴포넌트 트리에서 조상으로 전달하고, setState()를 부르고 새로운 데이터를 props로 내려주는 콜백을 의미합니다. Redux 앱에서 이는 모든 "쓰기" 로직이 루트 리듀서 함수에 캡슐화 되어있고 리듀서가 디스패치된 액션에 대한 응답하고 연결된 모든 컴포넌트는 이후에 저장소에서 업데이트된 상태를 읽는다는 것을 의미합니다. 이것은 모델을 직접 수정하기 위해 양방향 입력 바인딩을 사용하는 전형적인 앵귤러 앱이나 모든 뷰가 언제든지 this.model.set("someField", someValue")를 호출할 수 있는 Backbone 앱과 대조됩니다.

이는 양방향 입력 바인딩을 사용하여 모델을 직접 수정하는 일반적인 Angular 앱 또는 모든 보기가 this.model.set("someField", someValue)언제든지 호출할 수 있는 Backbone 앱과 대조됩니다.

내가 알기로, 썽크나 사가에서 상태를 읽어도 단방향 데이터 흐름이 중단되지 않습니다 . 액션은 여전히 디스패치되고 리듀서는 여전히 실행되며 컴포넌트는 여전히 업데이트된 상태를 읽습니다. 썽크가 상태 자체를 직접 수정하는 것과는 다릅니다. 모든 데이터 조각이 뷰에서 뷰로 명시적으로 전달되는 Elm만큼 엄격하지 않다는 점을 인정하지만 여기서는 문제가 발생하지 않습니다.

내가 겪은 문제

• 이벤트가 일어난 후에 이벤트를 걸어준 타겟이 바뀌어서 이벤트가 사라졌던 문제
• 드래그드롭 이벤트를 위임했으나, drop 이벤트가 먹지 않았던 문제

문제설명 드롭 이벤트에 DOM이 바뀌는 이벤트를 걸어주어서, DOM이 바뀌니까 내가 걸어줬던 이벤트가 없어졌다. 바뀔때마다 새로 걸어주는 것 보다 좋은 방법이 없을까?

해결방안

이벤트 위임으로 해결 하면 된다! 이벤트 위임을 알기 전에, 버블링과 캡쳐링 개념에 대해 알아보자. 이벤트 흐름은 3단계가 있는데, 캡쳐링 -> 타깃 -> 버블링 단계로 이루어진다.

이벤트 캡쳐링이란? 최상위 요소에서 가장 안쪽에 있는 타깃까지 이벤트가 내려가는 단계! addEventListener하고 인자로 capture:true를 해야 캡쳐링때 이벤트 핸들러가 동작함.

이벤트 버블링이란? 한 요소의 이벤트 핸들러가 동작하고 부모 요소의 핸들러가 동작하고, 또 그 부모 요소의 해들러가 동작하는 것. 그렇게 최상단 요소까지 진행된다. (버블링과 캡쳐링을 막는 것이 그 유명한 event.stopPropagation())

나는 이 중에서 버블링을 이용할 것임. DOM이 바뀌지 않는 곳에 이벤트를 걸어주고, 하위에서 버블링으로 이벤트핸들러가 올라오면 내가 걸어준 이벤트가 실행이 됨. 회사에서 작성한 코드는 공개가 힘들고, 예시를 만들어보자면!

<!DOCTYPE HTML>
<html>
  <head>
    <style>
      .up {
      width: 300px;
      height: 300px;
      background-color: black;
      color: white;
      }

      .middle {
      width: 200px;
      height: 200px;
      background-color: blue;
      color: white;
      }

      .down {
      width: 100px;
      height: 100px;
      background-color: green;
      color: white;
      }
    </style>
  </head>
  <body>
    <div class="up">
      내가 바로 상단의 이벤트를 받을곳!
      <div class="middle">난 아무것도 아님!
        <div class="down">난 이곳에 이벤트를 걸고 싶어!</div>
      </div>
    </div>
  </body>
  <script>
    const upSelector = document.querySelector('.up');
    const downSelector = document.querySelector('.down');

    upSelector.addEventListener('click', (e) => {
    if(e.target === downSelector) alert('event!');
    } )
  </script>
</html>

다음으로 드롭이벤트가 먹지 않던 문제는 간단했다. dragover 중에 e.preventdefault()를 넣으니까 해결. 어플리케이션의 대부분은 drop 속성이 허용되지 않아서 그것을 막고 drop을 허용시키는 것임! (참고자료)

참고자료 모음

https://stackoverflow.com/questions/21339924/drop-event-not-firing-in-chrome https://joshua1988.github.io/web-development/javascript/javascript-interview-3questions/ https://ko.javascript.info/bubbling-and-capturing