프리온보딩 프론트엔드 챌린지 10월 첫날

프리온보딩 코스에 이어서... 취업활동 열심히 해보자! 라는 마음가짐과 함께 원티드 프리온보딩 6차가 끝나고 바로 시작되는 원티드 챌린지를 바로 신청했다. 그리고 첫 강의가 끝이났다.

원티드 프리온보딩이 뭐야?

라고 물으신다면 아래에서 확인 가능하다.
프리온보딩

• 과락하지 않는 코드
• 나쁜 코드, 좋은 코드를 보는 눈을 기르기
• 어떻게 공부해야 하는지
• 기술 면접에 대해 좋은 답변에 대한 기준 세우기
• 취업 성공하기

그리고 10월 챌린지의 주제는 CSR / SSR with Next.js이다.

원티드 이벤트
위 링크에 들어가면 원티드에서 뭔가 하는게 많다. 가끔씩 들러서 확인해보면 재밌는게 종종 있는거 같다.

아무튼, 첫 강의가 끝났으니 바로바로 정리 안하면 보나마나 또 하루하루 미뤄가면서 미적미적 정리하다가 임시글에 박혀 버릴테니 얼른 포스팅 해야지.

✅상황에 맞는 기술

나는 상황에 맞는 기술을 선택할 수 있는가? 그것에 대한 근거를 댈 수 있고 상대방을 설득시킬 수 있을 만한 내공을 가지고 있는가?

어.. 솔직히 말하면 내가 상대방과 기술적인 대화를 나누며 적절한 스택을 선택할 수 있는지 모르겠다. 그나마 스택을 고민하고 적용했던 경험은 현재 틈틈이 진행중인 사이드 프로젝트인 궁금해 약인데, 글쎄... 여기서 태클이 들어온다면 나는 뭐라고 대답할 수 있을까? 평소에 고민하지 않는다면 아마 태클에 그대로 엎어지고 말겠지. 그리고 난 엎어질 준비가 되어있다.(?) 항상 why를 생각해야 하는데... 습관처럼 why를 달고 살아야겠다.

✅리액트에 찌들었어

8월 중순즈음 프로그래머스에 올라와 있는 과제테스트 연습인 프로그래밍 언어 검색을 풀어봤었다. 3시간 짜리였는데, 완성시키지 못했다. 검색 및 하이라이트 처리, 키보드와 마우스로 처리, 제출까지 구현하고 시간이 종료되었다. vanilla JS로 구현했어야 하는 해당 과제는 리액트에 찌들어있는 나에게 너무나도 불편한 과제였다. 그래서 오늘 챌린지 강의를 들으면 굉장히 뜨끔했다.🤥 사실 현재 프론트엔드 개발시장은 리액트를 다룰수 있는게 많이 유리하다고 생각한다. 하지만 리액트도 결국은 그 본질은 HTML과 JS겠지. 프레임워크에 너무 의존적인 개발자로 남는다면, 나의 그릇을 오히려 좁혀버리지 않을까 생각하게 되었다. 본질을 어느정도 이해하고 있어야 다른 붐이 왔을때도 무리없이 적응할수 있겠지. 결국 같은 것 위에서 표현하는 방식이 달라지는 것일테니까. 증말 쉽지 않다. 개발자들 진짜 대단해.

✅AJAX가 없던 시절의 데이터 Fetching

웹 초기에도 데이터 주고받을거 다 했다. 그저 AJAX기술이 나오면서 페이지를 새로고침 하지 않아도 서버와 통신할 수 있게 된 것 뿐...
그럼 기존에는 왜 새로고침 된거지? 당연하지! 데이터를 갱신해야 하니까! 다시 그려야 하니까! 정적인 HTML일 뿐이니까 다시 그려야겠지.
다시 그린다는 의미는 새로운 HTML을 다운로드 받는거고 그동안 유저는 흰 화면을 봐야만 한다.
MDN Form

<form action="" method="get" class="form-example">
  <div class="form-example">
    <label for="name">Enter your name: </label>
    <input type="text" name="name" id="name" required>
  </div>
  <div class="form-example">
    <label for="email">Enter your email: </label>
    <input type="email" name="email" id="email" required>
  </div>
  <div class="form-example">
    <input type="submit" value="Subscribe!">
  </div>
</form>

• action
  양식 데이터를 처리할 프로그램의 URI
• method
  양식을 제출할 때 사용할 HTTP 메서드
  post: POST 메서드. 양식 데이터를 요청 본문으로 전송한다.
  get: GET 메서드. 양식 데이터를 action URL과 ? 구분자 뒤에 이어 붙여서 전송한다.

😮SSR? 그것도 했었데

정적인 HTML 말고, 동적으로는 어떻게 했죠?

사용자 요청을 받고, PHP등의 언어를 사용해서 미리 준비된 템플릿 기반으로 페이지를 HTML로 요청에 맞게 그때그때 그려서 응답!
클라이언트가 정적인 HTML을 받는건 똑같다. 그리는걸 서버단에서 하는것이다.

예시 코드를 보고 떠올랐던건 pug, nunjucks였다. 엘리스 부트캠프 초기, 백엔드에 대해서 무지했던 나는 대체 백엔드는 어떻게 돌아가는가에 대한 호기심에 백엔드 이미지 게시 서버 구현하기 스터디를 했었고, 거기서 pug, nunjucks를 접했다. 정말 퀄리티가 떨어지는 사이트였지만 꽤 재밌게 만들었던 기억이 있는데 비슷한 코드를 보니 떠올랐다.
뭐, 아무튼 다음 회차에 좀 더 다룬다는데 기대가 된다.

✅CSR

서버에서는 최소한의 HTML을 한번만 받고, 화면을 전부 자바스크립트로만 그리자.

MPA는 다음과 같은 특징을 가진다.

• 페이지의 다른 링크를 클릭할 때마다 새롭게 HTML 을 서버에 요청하고, 매번 그 결과물을 받아야한다.
• 이런 과정이 있을 때마다 화면이 깜빡거리는, 즉 새로운 HTML을 받아오기 전까지 하얀화면을 유저가 봐야한다.

CSR은 다음과 같은 순서로 동작한다.

• 브라우저가 HTML을 요청한다.
• 서버는 브라우저로부터 날아온 요청 경로를 확인하고 index.html을 서버 내에서 찾아 응답한다. index.html의 body태그는 비어있다.(SEO에 불리하다.)
• 브라우저는 HTML 파일에서 head 태그를 읽으며 추가로 필요한 자원을 서버로 다시 요청한다.(index.js, index.css 등등)
• 자바스크립트를 다운받고, 로직에 따라 태그를 그려넣는다.
• 초기 로딩 이외의 변경 요청이 있을 때는 서버 API에 요청하여 받아온 데이터로 새롭게 그려넣는다.

✅SPA / CSR 에서의 라우팅

window.onpopstate, pushstate에 대해서 찾아보자. 과제하면서 찾아봐야징

✅Critical Rendering Path

일전에 내가 면접용으로 준비 해 놓은 답변은 다음과 같다.

클라이언트는 서버에 HTML파일을 요청(request)합니다. 서버는 클라이언트에게 HTML파일을 보내줍니다(response).
브라우저는 HTML 파일을 loading 하고, HTML파일을 scripting 합니다. 이 과정에서 DOM(Document Object Model) 트리가 만들어 집니다.
그리고 CSS파일을 파싱하면서 CSSOM(CSS Object Model) 트리가 만들어집니다.
DOM과 CSSOM을 합쳐 Render Tree가 만들어지고, 이 Render Tree를 기반으로 layout, 즉 각각의 요소가 어디에 배치되어야 하는지를 계산합니다.
이후 실제로 그려지는 파트인 painting이 일어나고, composition으로 마무리 됩니다.

지금 보니까 구리다. 멋있게 꾸미고 싶은데 이런거 참 못한다.😑

좀 더 정리했던 내용은 다음과 같다.

Construction part

requests/response: HTML 파일을 요청한다.
loading: HTML 파일을 로딩한다.
scripting: HTML 을 한줄씩 분석해서 DOM 요소로 변환한다. CSS 요소를 CSSOM 으로 변환한다.
rendering: Render Tree 를 만든다.

Operation part

layout: Render Tree 를 기반으로 각각의 요소들이 어떻게 표기 될 것인지 계산을 한다.
painting: 그림을 그린다.
composition: 구성

painting

바로 브라우저에 그리는 것이 아니다. 구역마다 나눠서 이미지를 준비해 놓는다.
여기서 레이어라는 개념이 나온다. 한장에 우리가 볼 홈페이지를 전부 다 그리는 것이 아니다. 구역마다 레이어로 묶어서 준비해 놓는 것이다.
만약 우리가 한 부분을 수정한다고 치면 전체를 다 다시 그리는 것보다, 해당 레이어만 수정하면 되는 것이 훨씬 성능상의 이점을 꾀할 수 있을 것이다.
그렇지만 많은 양의 레이어는 오히려 성능을 해칠 수 있다.

Operation part에서의 성능개선

Paint가 자주 일어나지 않아야 한다. 요소가 이동만 하는 경우면 paint 는 일어나지 않는다. composition 만 일어나면 된다.
이동하고 그림까지 다시 그려져야 한다면, paint 까지 일어난다.
최악의 경우에는 layout 으로 요소를 옮김으로써 주변의 다른 요소들의 위치가 재조정 되어야 한다면 좋지 않다.
layout->paint->composition 까지 모든 과정을 거쳐야한다.

추가적인 키워드로는

• HTML, CSS parser
• 토큰화 (의미를 가지는 단위)
• 쌓임 맥락 (z-index, 두 tag간의 쌓임 맥락으로 인한 이슈)

그래서 최적화는 ..?

✅React의 CSR 최적화

변화가 자주 일어난다. 즉 렌더링 작업이 자주 일어나게 되면 자바스크립트가 브라우저의 메인 스레드를 차지해 버릴 수 있을 것이다.

Request Animation Frame

이벤트 루프를 정리하면서 일전에 정리했던 글이다.

렌더는 브라우저에서 특정 요소가 움직이거나, 애니메이션을 할 때 주기적으로 호출되는데, requestAnimationFrame 함수를 통해 콜백 함수를 등록 해 놓으면, Request Animation Frame queue에 콜백이 쌓이고, 다음번 브라우저 업데이트 때 이벤트 루프는 Request Animation Frame queue에 쌓인 콜백 함수들을 콜 스택에 올린다.

추가적인 키워드로는

• 프레임이 끊기지 않도록 스케쥴링
• 재조정(Reconciliation)
• 렌더 단계, 커밋 단계

추가적으로 나온 답변할 수 있나요? 파트는 좀 고민해보자. 일단 과제 해야 해!