# 피어세션-4주차-J8

## 목차
- [🙋🏻‍♂️ 참가자 소개](#🙋🏻‍♂️-참가자)
- [📚 공유할 사항들](#📚-공유할-사항들)
- [📝 피어세션 개인 회고](#📝-피어세션-개인-회고)

## 🙋🏻‍♂️ 참가자 소개
|캠퍼 ID|이름|
|:--:|:--:|
|J012|김경식|
|J023|김무성|
|J041|김영화|
|J091|박주원|
|J120|안승재|
|J164|이찬호|
|J197|조진성|

## 📚 공유할 사항들

### J023 김무성
- 메인 페이지 달력, 요금, 인원 모달 작성
- 요금 모달창에는 레인지 슬라이더만 구현
- 지도 API : 임의의 포인트 작성하여 표시
- webpack 사용 시 MiniCssExtractPlugin 로더 사용
- options -> url 속성을 false로 주어서 이미지 이름 유지함
- entry 파일은 html, scss
- 초기에 setup을 통해 그려주고, observer를 통해 이후 렌더링 방식

### J012 김경식
- 메인 페이지의 달력, 요금, 인원 모달 작성
- 요금 모달창에서 그래프는 베지어 커브를 활용하여 구현
- 프론트 MVC 패턴을 이용하여 JS 파일 구조를 만드려고 시도
- Model-View 와 View-Controller의 역할이 모호해짐

### J197 조진성
- flex 형식을 따라해보려고 시도
- 이벤트 발생 -> dispatcher(데이터 수정) -> data registry(setState 호출)
- element 하나가 객체에 대응되도록 작성
- 모든 기능을 element가 갖고있어야 하지만, 이벤트 처리가 어려워짐
- 복잡도가 오히려 높아지는 듯한 문제 발생

### J041 김영화
- README에 프로젝트 기획(ERD, 프로젝트 구조, 각종 API 문서들)이 꼼꼼하게 작성됨
- 컴포넌트 단위로 html, css, js 파일 묶음

### J120 안승재
- 컴포넌트를 최대한 잘게 나누기 위해 노력함
- MVC 패턴 -> model : storage, 이벤트는 controller, view에 이벤트 등록
- 데이터 변경은 컨트롤러에 EventEmitter 방식으로 전달함으로써, 데이터를 변경하도록 함
- controller가 모든 데이터를 갖고 필요한 부분만 필요할 때 렌더링하는 방식

### J164 이찬호
- fetch 요청 -> DB 요금 데이터에 따라 최소값, 평균값, 최대값 계산
- 레인지 슬라이더 움직임에 따른 요금 범위 변경
- DB에 쿼리를 보내서 지도에 각 포인트 표시
- 아토믹 디자인(컴포넌트를 잘게 나눔 -> 이를 가지고 더 큰 컴포넌트를 만드는 방식) : 재사용성이 높다.
- 사용자 이벤트를 어떻게 처리할 지에 대한 고민을 함
- organism(컴포넌트의 완성 단계) : 이벤트 리스너를 등록하거나, molecule에서 이벤트를 등록하는 방식을 적용
- controller : addEventListener의 콜백함수를 모아둠
- SQL를 직접 짜서 구현(query injection 위험)
- innerHTML 방식이 append보다 효율성이 높다.
- 아토믹 디자인은 태그 단위로 나눈다 -> 재사용적인 측면을 고려해볼 필요가 있음

### J091 박주원
- 컴포넌트들을 createElement -> append 해주는 방식으로 작성
- template literal에 대한 필요성을 느끼게 됨
- 옵저버 패턴 : 상태의 변화가 있을 때 컴포넌트가 다시 렌더링 됨
- 없으면 새로 append, 이미 있으면 replace
- model - view 역할의 모호성

## 📝 피어세션 개인 회고

### J023 김무성
- 프론트 구조를 짜는게 어려웠던 것 같습니다. 프레임워크가 왜 만들어졌는지 알게 된 계기였습니다.
- 피어들간에 자신의 프로젝트 구조를 공유하는 시간을 가졌는데, 개인별로 기획이 다 다르다는 것을 알게 되었습니다.

### J041 김영화
- Component 단위로 레이아웃을 구성하는 작업은 이번이 처음이었는데 프로젝트를 진행하면서 제가 생각한 방식이 맞는지에 대한 의문을 가졌지만 피어세션을 통해 공유함으로써 다양한 방식의 Component 구성 방식을 알 수 있었다.
- 상태 관리에 대한 이해가 부족했지만 피어세션을 통해 깊이 있게 이해할 수 있었다.

### J091 박주원
- 좋은 프로젝트 구조에 대해서 생각해보았다.
- 상태 관리를 직접 구현하려고 하니 막막하고 험난했다...

### J012 김경식
- js 파일들의 구조를 깔끔하게 짜지 못한 것 같아 아쉽습니다.
- MVC 패턴을 최대한 유지하려 했지만, 각각의 역할이 겹치는 점이 많았습니다.
- 다음 프로젝트에서 js파일 구조를 설계할 때는 MVC패턴에 구애받지 않고 깔끔하고 명확한 역할을 부여하는게 목표입니다.
- 프로젝트 설계 및 메인 페이지를 구현하느라 너무 많은 시간을 사용한 것 같습니다.
- 학습 차원에서 웹팩 등의 개념에 대해 많은 것을 배웠지만, 백엔드 쪽이나 지도API 구현을 못한 점이 아쉽습니다.

### J164 이찬호
- 프론트 엔드에서 사용자의 입력 혹은 서버에서의 입력을 어떻게 화면에 반영할 것인지에 대한 아이디어를 얻을 수 있었다.
- 다른 캠퍼 분들은 flux 패턴, observer 패턴, MVC 패턴 등을 적용함으로써, 생겼던 문제점과 해결 방법에 대해서 공유할 수 있어 좋은 시간이었다.
- 사용자의 입력과 DB의 입력을 충분히 고려하지 않아 좋지 않은 파일 구조를 작성하였습니다. 이 점이 아쉽고, 다음에는 이를 잘 컨트롤 할 수 있도록 생각을 정리하는 시간을 가질 것이다.

### J197 조진성
좋게 이미 있는 프레임워크를 따라할 걸 그랬나봅니다. 괜히 주제에 맞지 않게 프레임워크를 구성해보자는 욕심부리다가 설계하고 수정하는 과정만 반복하다 2주가 지나버렸습니다.

### J120 안승재
- 이번 미션은 특히 완성도가 많이 부족했습니다. 아무래도 SPA로 구현을 해야하다보니 설계 과정에서 시간을 많이 쓰게 됐습니다. 계속 구조가 바뀌다보니 기획서의 내용을 모두 구현하기 어려웠습니다.
- 이번 미션에서 SPA구현을 제대로 해봤으니 다음 미션부터는 완벽하게 구현하는 것을 목표로 하고 싶습니다.