BangDori 님의 상세페이지[7팀 강병준] Chapter 1-2. 프레임워크 없이 SPA 만들기 (2)

과제 체크포인트

배포 링크

https://hanghae-plus.github.io/front_6th_chapter1-2/

기본과제

가상돔을 기반으로 렌더링하기

  • createVNode 함수를 이용하여 vNode를 만든다.
  • normalizeVNode 함수를 이용하여 vNode를 정규화한다.
  • createElement 함수를 이용하여 vNode를 실제 DOM으로 만든다.
  • 결과적으로, JSX를 실제 DOM으로 변환할 수 있도록 만들었다.

이벤트 위임

  • 노드를 생성할 때 이벤트를 직접 등록하는게 아니라 이벤트 위임 방식으로 등록해야 한다
  • 동적으로 추가된 요소에도 이벤트가 정상적으로 작동해야 한다
  • 이벤트 핸들러가 제거되면 더 이상 호출되지 않아야 한다

심화 과제

Diff 알고리즘 구현

  • 초기 렌더링이 올바르게 수행되어야 한다
  • diff 알고리즘을 통해 변경된 부분만 업데이트해야 한다
  • 새로운 요소를 추가하고 불필요한 요소를 제거해야 한다
  • 요소의 속성만 변경되었을 때 요소를 재사용해야 한다
  • 요소의 타입이 변경되었을 때 새로운 요소를 생성해야 한다

과제 셀프회고

  • 처음에 문제를 Step by Step으로 요구사항을 해결하다 보니, 큰 그림을 이해하지 못했는데 흐름도를 직접 그리면서 문제를 이해하다보니 문제가 요구하는 것이 무엇이며 내가 어떤 것들을 해야하는 지 알게 되었다. 또 가장 중요한 내가 작성한 코드가 가상 객체(vNode)로 변환되고, 실제 DOM에 어떻게 변환되는지 설명할 수 있게 된 것이 가장 많이 배운 점인 것 같다.
image
  • 처음부터 완벽한 코드를 작성하는 것이 아닌 테스트를 통과하는 코드를 우선 작성하고 리팩토링 하는 과정을 거치니, 더욱 명확하고 안정적인 코드 작성이 가능해진 것 같다. 이전에는 너무 완벽하게 코드를 작성하려고 하다 보니 오히려 시작도 제대로 못하는 경우가 있었는데, 완벽함이라는 마음가짐을 어느정도는 빼버려도 좋을 것 같다는 생각을 하게 되었다.

기술적 성장

  • WeakMap이라는 자료구조를 알기만하고 직접 사용해볼 기회가 없었는데, 이번 계기를 통해 WeakMap을 사용하면서 Map과 WeakMap이 각각 어떤 역할을 하며 언제 사용해야 하는 지 배우게 되었다.
  • String()toString()의 차이가 궁금해서 찾아보았는데, nullish 처리 가능 여부라는 사실을 알게 되었고 새롭게 알게된 정보를 다른 분들께도 공유하였는데 정말 많은 분들이 호응해주셔서 기분이 좋았다. (다들 너무 착하신 것 같다.)
image

코드 품질

  • eventManager.js에서 eventHandler가 위임받은 이벤트를 처리하고 있는데, 깊게 생각하지 못하고 코드를 짜다보니 다른 사람이 이해하기 쉬운 코드가 되지는 못한 것 같았다. 주석을 활용하거나, 리팩토링을 통해 읽기 좋은? 이해하기 좋은 코드가 될 수 있을 것 같다.

학습 효과 분석

  • WeakMap이 실제로 어떻게 동작하는지, 그리고 Map과 어떻게 다른 지 tc39를 통해서 내부 동작 과정을 한 번 확인해 볼 필요가 있을 것 같다.
  • React가 코드 작성 외에 내부적인 과정을 모두 처리해주는 것이 새삼 얼마나 편리한 지 깨닫게 되었고, 이런 편리함을 더 잘 누리기 위해서는 내부 동작 과정과 규칙이 왜 만들어졌는지를 이해하는 것이 앞으로의 성장에 큰 도움이 될 거라고 생각했다. 그래서 앞으로 미션에서나 실무에서도 코드를 작성하는 데 있어, 단순히 코드를 작성하는 것에 그치지 않고 "Hooks는 왜 항상 최상단에 선언되어야 할까?"와 같이 규칙이 만들어진 이유에 대해 파고들어야겠다는 마인드를 가지게 되었다.

과제 피드백

  • 이벤트 매니저를 구현한 것은 처음이었는데, 이 과정에서 실제로 React에서는 이벤트를 어떻게 관리하고 처리하는지를 배우게 되었고 또 이벤트 위임이 실제로 이렇게 된다는 사실을 알게 되었다.

리뷰 받고 싶은 내용

  1. 처음부터 AI의 도움을 받아 코드를 작성하고, 이후 스스로 이해할 수 있도록 수정해나가는 방식으로 진행 중입니다. 이 방법이 바람직한 학습 방식일까요, 아니면 먼저 스스로 코드를 모두 작성한 뒤, 이후에 AI의 도움을 받아 개선하는 것이 더 좋을까요?
  2. 현재 과제에서 createElement.js의 updateAttributesupdateElement.js의 updateAttributes가 유사한 작업을 수행합니다. 이럴 때, 공통 로직을 하나의 모듈로 분리해서 사용하는 것과 각각 파일 내에 따로 정의하는 것에는 어떤 차이가 있을까요? 멘토님은 이처럼 중복된 메서드가 있을 때, 보통 어떤 기준으로 모듈화를 결정하시나요?
    • 저는 현재 두 함수가 서로 유사한 작업을 수행하기는 하지만 큰 맥락(초기 렌더링, 리렌더링)으로 보았을 때, 서로 다른 맥락을 가지고 수행되어지는 작업이라고 생각해서 분리하지 않았습니다..!

과제 피드백

Q. 처음부터 AI의 도움을 받아 코드를 작성하고, 이후 스스로 이해할 수 있도록 수정해나가는 방식으로 진행 중입니다. 이 방법이 바람직한 학습 방식일까요, 아니면 먼저 스스로 코드를 모두 작성한 뒤, 이후에 AI의 도움을 받아 개선하는 것이 더 좋을까요?

A. 저는 인공지능을 사수가아닌 부사수의 개념으로 사용해달라고 가이드 하는 편입니다. 그말은 어떻게 만드는지 이미 알고 있지만 귀찮아서 코드 생성을 AI에게 맡기고 원하는 결과물이 나올때까지 요청하는 것이죠. 지금과 같은 과제는 저라면 AI 도움없이 만들 것 같습니다~

Q. 현재 과제에서 createElement.js의 updateAttributes와 updateElement.js의 updateAttributes가 유사한 작업을 수행합니다. 이럴 때, 공통 로직을 하나의 모듈로 분리해서 사용하는 것과 각각 파일 내에 따로 정의하는 것에는 어떤 차이가 있을까요? 멘토님은 이처럼 중복된 메서드가 있을 때, 보통 어떤 기준으로 모듈화를 결정하시나요?

A. 넵 말씀하신대로 updateAttributes의 일부로직이 재사용된다면, 이것은 코드를 분리해달라는 신호일 수 있어요 그래서 해당 로직의 동작을 설명하는 함수로 분리해서 그 함수를 updateElement와 createElement에서 사용해야할 것 같습니다 :) 저는 맥락보다 중복된 코드 생겼을때를 코드가 보내는 신호라고 판단하고 분리해 재사용합니다!