---
# System prepended metadata

title: 4/12

---

# 4/12

- 정규시간(리뷰)
- columns 로 디렉토리명 변경
- error no-underscore-dangle
- Api 예외처리
- 오류 : App.js `${Actions({ display: actionDisplay })}`, tagComponents/Button.js

- 오전
    - 리뷰

- 오후 
    - no-underscore-dangle
        - lint "_id" 예외로
    - 리뷰 코드 개선
        - draggable 사용 X, dragend 같은 dom 이벤트도 사용 X mouse 관련 이벤트로 만들기
        - peact 는 많은 힘을 쓰지 않는 방향으로

### issue

브라우저 처음 로딩시 정렬된 칼럼 표시 #9 
- 5분도 안걸릴듯

새로운 카드를 등록할 수 있는 박스 만들기 [#12](https://github.com/healtheloper/todo-list/issues/12)
- 버튼 눌러서 등록 요청하는 거는 잠시 보류해도 O

클릭 이벤트를 만져봐야 할 듯

### PR 리뷰

1.0 setValue에 대해

- 말씀하신 것 처럼 Template가 모두 render된 후 콜 스택이 비워져야 setValue에서 발생하는 render함수가 호출되는 시점의 값으로 리렌더링이 되기 때문에 의도적으로 setTimeout을 넣었는데, 이런 의도가 setTimeout을 사용하는 것만으로는 표현이 되지 않았던 것 같습니다. 해당 부분은 리팩토링을 해 보겠습니다.



1.3 

- 렌더링 로직 App 컴포넌트의 반환값 (템플레이트) 에 사용하고자 하는 컴포넌트(Header, ...) 의 반환값(템플레이트) 를 사용하는 방식입니다.
    - App의 Return 에서 각 컴포넌트를 호출해서 해당 컴포넌트가 스택에 쌓이고 평가되어 해당 컴포넌트의 템플레이트가 Return 되고 최종적으로 App 의 템플레이트가 평가되어 반환하는 식
    
- 현재는 columns, todos 와 같은 상태를 App 에서 백엔드와 통신을 한 이후 자식 컴포넌트에 props 로 넘겨주고 있습니다.


1.3.1

> info.$root에 붙이기 위해 나머지 전체 상태를 App에서 관리해야 한다면

- root 에 innerHTML 을 App 의 return 값으로 넣음
    - App 의 return 값에 각 컴포넌트들의 return 값도 포함되어 있음
    - 컴포넌트(함수)들이 스택에 쌓이고 단계적으로 return 이 되어 최종적으로 App 의 템플레이트가 return 됨

- 이렇다면 `전체 상태를 App 에서 관리하는 것이다` 라고 말하는 것 인가요?

- columns 와 todos 는 App 에서 통신하여 가져오지만 실제로는 columns 컴포넌트에서 통신하여 가져와도 정상적으로 동작은 할 수 있습니다.
    - 다만 App 에서 한번에 통신한 이유는 App 이 켜졌을 때 서비스가 바로 필요로 하는 데이터 이기 때문에 App 에서 통신을 한 후 넘겨주는게 좋겠다는 생각으로 App 에서 보내주었는데 특정 상태를 사용하는 컴포넌트에서 통신을 하는게 더 좋은 것인지 궁금해졌습니다. 

>  컴포넌트 자체적으로 상태 관리가 어렵고 하다면, 그것은 컴포넌트라고 불리기 어려운 코드단위라고 여겨집니다.

- 컴포넌트 자체적으로 상태 관리
    - 컴포넌트가 자체적인 상태를 가질 수 있어야 한다는 걸까요? 각 컴포넌트들이 현재 peact 내부의 state 를 활용해서 상태를 가지도록 useState 함수를 사용하고 있는데, 이런 방식이 아닌 컴포넌트 내부에서 가질 수 있어야 한다는 것인지 궁금합니다.

- `addEventAfterRender` 
    - 컴포넌트가 템플릿을 바로 return하는 형태이기 때문에 해당 템플릿에 존재하는 태그에 이벤트를 달아주는 것이 고민사항 이었습니다. 
    - 버그가 발생했던 이유는 setValue와 같이 setTimeout을 사용해서인데, 불확실한 순서로 달아주는 것이 버그의 이유라고 생각이 들어서 setTimeout을 사용하는 방식을 버리고 새로운 방식으로 개선해 보려고 합니다. 

Form?

- 아직 POST 데이터 요청을 안해본 상태입니다

- Form 을 쓰면 Form 안에있는 Input 의 value 를 뽑아서 body 를 만들어 post 요청을 하기 수월하지 않을까 생각했습니다.
    - ex) 새로운 카드 등록
- 만약에 form 을 쓰지 않는다면 DOM API 를 사용해서 value 를 얻어내고 데이터를 파싱해서 post 요청을 보내야 할 것 같은 데, 위 form 을 이용한 방식이 문제가 있는걸까요?

draggable

- mouse 이벤트 를 활용해서 만들어 보도록 하겠습니다.

watchStates

- useEffect 를 만들어볼 때 어떤 이름으로 써야할 지 고민하다가 위와 같이 이름을 정했는데 문서에서 dependency list 라고 이야기를 하는군요! 감사합니다.

isUpdate

- shallow compare! 공부해 보겠습니다

app id 로 접근

- 바로 수정하겠습니다! 

document 순회
- Button 같은 tagComponents 를 만들 때 상위 태그를 기억하는 방식을 어떻게 할 것인가 를 고민해보고 개선한다면 해당 태그를 찾기위한 순회가 줄어 들 수 있다고 생각이 들어서 현재 컴포넌트를 `템플릿을 반환하는 형태` 에서 어떻게 개선할 수 있을지를 고민해보겠습니다.

console.log
PR 날리기 전 lint 를 다시한번 확인하는 습관을 들이겠습니다..

스타일 라이브러리를 사용할 때 어떻게 제한을 두어야 하는 건지에 대해서 알아보겠습니다.

- window 환경에서 nodemon 의 --exec 에서 devDependency 를 찾지 못했습니다.
    - global 로 다운받게 의도하기 보다 npm i 를 했을 때 바로 실행이 될 수있게 하고싶었습니다.
- nodemon --exec 를 사용해서 생긴 문제라 nodemon 은 일단 개발환경에서 쓰여진다고 생각하고 watch 옵션을 통해 사용하도록 scripts 를 변경해보았습니다.

```json
"start": "babel-node init.js --delay 1",
"start:watch": "nodemon --exec npm start",
``` 

-------------------

- 렌더링을 어떻게 할 것인가? 클래스사용 vs 함수형
    - 컴포넌트 렌더링 로직을 함수형으로 시도해보기
        
        → 이전 미션에서 사용해보지 않았던 방식을 공부하면서 결과보다 학습에 중점을 두자고 이야기를 하였습니다.
        
        → HTML 태그 자체를 리턴하는 형식은 이전에 써보면서 불편함을 느꼈는데, `각 컴포넌트가 갖는 상태`를 어떻게 저장해야할지, `해당 태그가 render 된 이후 필요한 로직`은 어떻게 처리해야할지 고민이 되었습니다.
        
- 이전 미션을 하면서 느꼈던 학습 경험
    - 처음 SPA 를 만들어 보는 과정에서 `innerHTML 을 통해 templating` 을 하고, 그 이후 `이벤트를 세팅`하고.. 그런 로직을 사용하다보니 `렌더링을 위한 공통된 로직` 이 존재하여 각각 필요한 메서드들(render, template 등등..) 을 추상화한 다음 클래스로 만들어서 사용하게 되었습니다.
    - 나중에 확인해보니 해당 로직이 완벽히 동일하지는 않지만 리액트가 `클래스형으로 동작할 때의 생명주기`와 비슷하다는 생각이 들었습니다.
    
- peact 에 대해
    - 저번주 동안 함수형 프로그래밍으로 렌더링을 어떻게 해야할지 고민해보고, Core 가 될만한 실행 흐름을 이야기 해보자고 했습니다.
        - 이 과정에서 저는 클래스형으로 컴포넌트 구조를 만들었을 때, 결국 `리액트가 클래스형으로 렌더링을 할 때의 생명주기`와 비슷했다고 느꼈던 경험을 비비와 공유하였고, 그렇다면 `함수형도 그와 비슷하게 리액트가 함수형을 렌더링 하는 로직과 비슷하게 흘러가지 않을까` 라는 생각으로 리액트에서 함수형 프로그래밍이 어떻게 되어지고있는지를 알아보니 ‘useEffect 와 useState 라는 것을 사용한다더라, 이것을 우리가 구현할 수 있을지는 모르겠지만 해당 흐름이 도움이 될 것같다’ 라는 생각으로 각자 이와 같은 로직을 공부해보고 구현해본다음 비교해보자 라고 시작하게 되었습니다.
        - 이 과정에서 제 코드를 공유하기 위해 올렸던 것이 peact 레포입니다, 이후 같이 코드를 보며 제 코드를 기반으로 개선을 진행했습니다.
    - 이번 미션을 통해 ‘리액트 내부구조'를 완벽히 구현해내자 는 의도는 없었습니다. 리액트 동작을 확실히 이해하고, 카피하고자 이름을 peact 로 지은 것이 아닌, 함수형으로 동작할 때 어떻게 state 를 다루는지, 클래스형태의 컴포넌트에서 사용되었던 mount, update 당시 로직은 어떻게 해야할 지 참고를 위해 useState, useEffect 의 동작을 간단히 이해하고 그 흐름을 사용한 것이기에 이름을 peact 로 짓게 되었습니다. 렌더링의 흐름만을 이해하고 내부가 어떻게 동작하는지를 고려하지 않고, 각자의 생각대로 구현한 이후 개선한 정도이기 때문에 실제 내부구조와 비교하자면 부족한 점이 많습니다.
    - 현재 addEvent 를 하는 로직에 버그가 있어서 테스트 해보셨을 때 오류가 생겼을 거라고 추측이 되었습니다. (버그가 있는 것을 제대로 확인하지 않고 커밋해서 죄송합니다..)
        - 이와같은 버그가 생겼을 때 `왜 버그가 생겼는지?` 를 추측해보고 그것을 고쳐나가면서 훗날 리액트를 학습할 때에 리액트의 내부구조를 살펴본다면 `아 이래서 이런식으로 썼구나` 가 더 와닿지 않을 까란 생각에 실제 내부구조를 들여다보지않은 상태에서 불편함을 개선해나가려고 했습니다.


안녕하세요, 빰빰!
BB입니다! 이번에도 정성스럽게 리뷰해주셔서 감사합니다😊
꼼꼼하게 남겨주신 리뷰를 함께 확인하면서 같이 생각해 본 사항들을 코멘트로 남겼습니다!

염려해주신 부분에 대해서도 코멘트 남겨보겠습니답🙌

- 함수형 컴포넌트?
    - 처음 미션을 받았을 때, 저는 이전 미션들을 진행하면서 익숙해진 클래스 형태의 컴포넌트를 만드는 방식 외에는 떠오르지 않았습니다. 이번에는 함께 작업을 하는 것인 만큼 서로 의견을 나누어 보았는데요.파크의 의견을 들어보니, 아! 이런 식으로 하면 함수형으로 만들수 있겠구나! 하는 깨달음을 얻었고, 서로 공부를 해야할 점이 많이 있을 수 있겠지만 도전해 보고 싶다!는 결론에 이르렀고, 결과물보다 학습하고 배우는 데에 집중하며 이번 프로젝트에 임해보기로 하였습니다.

- peact를 만들어보자!
    - peact라는 이름이나, 파크의 깃허브 레포지토리에 peact가 있었기 때문에 빰빰의 염려대로 온전히 파크의 프로젝트가 아니었을까? 하는 생각이 들 수 있었던 것 같습니다! 리액트의 `useState`와 `useEffect`에서 아이디어를 얻어 이것을 이용하면 저희의 함수형 컴포넌트를 만들수 있을 것이라 생각했습니다. 이를 통해 좀 더 함수형스러운? 컴포넌트를 만들어보기 위해서 각자 useEffect와 useState를 공부하고 구현하는 시간을 가져 보았습니다. 
    - 이 과정에서 코드의 문제점을 발견하면 고쳐주기도 하고, 학습한 내용에 대해 공유하기도 하면서 현재의 peact를 완성할 수 있었습니다.(한정된 시간 안에서 제가 만들어 본 useEffect는 제대로 동작하지 않았지만, 파크의 코드리뷰를 통해 개선된 후에는 동작하게 되기도 하였습니다..!✨) 이름은 peact이지만 함께 피땀눈물(까진 아니더라도😁)로 만들어보았습니다! (실제로 이름이 pbeact가 될 수도 있었답니다👀) 
    - 리액트를 완전히 만들어보기 보다 지금은 리액트의 함수형 컴포넌트의 흐름을 배워보고 적용하기 위해 useState, useEffect를 활용하는데 그쳤는데요, 그만큼 실제 리액트에 견주자면 부족한 것도 사실입니다. 부족했던 점은 앞으로 리액트에 대한 학습을 이어 나갈 때 더욱 채워보려하고, 이런 경험을 통하여 앞으로의 학습에 보탬이 될 수 있기를 기대하고 있습니다.

- 현재 프로젝트를 진행하면서 
    - 서로 충분히 학습할 시간을 가지고, 상대방이 제대로 이 부분에 대해서 알고 있을지 확인하는 과정을 거치고 있습니다! 분업을 통하여 코드를 작성하였더라도 `의존적인 작업하기`라는 목표를 가지고 상대방에게 확인을 받고 코드에 대하여 이야기를 나누며, 혹시 어려운 부분이 없는지 이야기를 나누며 작업하고있습니다! 하루 일과 시간 중 80% 이상은 함께 회의를 하고 이야기를 나누고 있다고 해도 과언이 아닌...🥺! 뿐만 아니라 협업 관점에서도 정말 많은 것을 배우고 익혀가고 있습니다!(빰빰의 리뷰도 정말 많이 공부가 되고 있어요! 감사합니다👍) 
    - 이번 프로젝트 기간에는 결과에 상관없이 협업 전략을 세우고, 회의록, 이슈, 위키, PR등 다양한 방법을 사용해 볼 뿐 아니라, 내가 생각하지 못했던 구현 방식에 대해 도전해보는 정말 귀중한 시간을 보내고 있는 것 같아요! 기존에는 늘 내 지식안에 갇혀 있다는 생각에 답답함도 있었는데, 좋은 동료를 만난 덕분에 새로운 것을 익히고 도전해보는 재미를 느껴보고있습니다! 앞으로도 열심히 즐겁게 해보도록 하겠습니다🙌