# J16 피어 세션
## 😀 참여자
|[J155 이인송](https://github.com/ingong)|[J017 김기한](https://github.com/vgihan)|[J164 이찬호](https://github.com/ChanHoLee275)|[J138 이광민](https://github.com/LeeKwang-min)|[J119 안병웅](https://github.com/gomster96)|[J154 이윤성](https://github.com/ddaynew365)|[J187 정요한](https://github.com/ingyeoking13)|[J223 황정빈](http://github.com/jeongbbn)|
|------|---|---|------|---|---|------|---|
|<img src="https://github.com/ingong.png" width="80"> |<img src="https://github.com/vgihan.png" width="80">|<img src="https://github.com/ChanHoLee275.png" width="80">|<img src="https://github.com/LeeKwang-min.png" width="80">|<img src="https://github.com/gomster96.png" width="80">|<img src="https://github.com/ddaynew365.png" width="80">|<img src="https://github.com/ingyeoking13.png" width="80">|<img src="https://github.com/jeongbbn.png" width="80">|
## 📜 키워드
- 전역 상태 관리
- 컴포넌트 상태 관리
- 쿠키와 세션
- 이미지 DB 저장
- 옵저버 설계
- SPA 라우팅
- 함수형 프로그래밍
- 리액트
- flux 패턴
- 컴포넌트 분리
- 백 구조, 프론트 구조
## 🧐 고민
- 컴포넌트를 어느 수준까지 작게 나누는 것이 좋을까?
- 아토믹 디자인의 목적이 재사용성을 위함인데 우리 프로젝트에서는 재사용되는 일이 적었다
- layout 과 데이터를 담는 부분을 분리
- 찬호님은 View 에서 렌더링하는 메서드, state 를 변경하는 메서드를 작성해서, Model 과 View 간의 구분이 명확하지 않아서, 함수의 형태로 template 을 만들어주는 식으로 작성하지는 못했음.
- 해답이 없는 문제라서 자연스러운 고민인 것 같다...!
- 상위 컴포넌트 이벤트 발생 시 하위 컴포넌트만 리렌더링 하는 것이 가능한가
- 가능할 것 같기는 같지만, 어려울 수 있다. 생명주기를 고려해서, 이벤트 이름을 조건문을 통해서 해당 이벤트 발생 시에만 리렌덜이을 할 수 있게한다. so hard...
- 하위 컴포넌트의 렌더링 부분을 나누어 상위 컴포넌트에서 사용하는 방식으로 처리가 가능할 것 같다.
- 사진을 전송할 때는 리렌더링 시 입력한 파일 내용이 초기화 될 수 있기 때문에 formdata를 상태값으로 저장해두었다가 이후에 사용하면 된다. 전송하는 state 중에 이미지가 있으면 formData 를 사용해야하는 것 같습니다.
- 컴포넌트 생성과 동시에 비동기 처리를 해야 하는 경우 어떻게 처리 했는가
- 리액트의 '헤드마운트' 방식을 따라 비동기 처리가 끝나면 해당 부분을 리렌더링 하는 방식으로 2번의 렌더링 과정을 거쳐 처리한다.
- 데이터를 받아오면 그다음에 렌더링하는 방식(async, await)을 사용
- '데이터 받고 렌더링'이란 순서를 보장해주는 정석적인 방법으로는 뭐가 있을까?
-> 리액트의 경우에는 props를 넘겨주는데, 이걸로 보장하는게 아닐까?
- 추가적인 내용 : 좋은 사용자 경험을 선사하기 위한 한가지의 방법 Skeleton UI
- 어떻게하면 효율적으로 사용할 수 있게 DB를 모델링할 수 있을까?
- 위치 Table DB 모델링
- Location Table 이 User, Item 에서 사용되는데 Location을 User와 Item에 column으로 넣는 방법 이외의 다른 방법이 존재하는가.
- location table을 따로 생성한 뒤, location id를 user와 item에 저장을 하는 방법이 있다.
- location table을 따로 생성하면, join을 하기 때문에 생각보다 리소스가 많이 들 수 있다.
- 당근 마켓 ERD 예시 (https://www.erdcloud.com/d/2mDmcrHWY3CqW4Rrp)
- 당근 마켓 ERD 설명 (https://velog.io/@octo-5/%EB%8B%B9%EA%B7%BC-%EB%A7%88%EC%BC%93-%ED%81%B4%EB%A1%A0-%EC%A7%80%EC%97%AD-%EC%A0%95%EB%B3%B4%EC%99%80-DB-%EC%84%A0%ED%83%9D)
- 리소스 별 url mapping 어떤 기준으로 했는가
- 명사형으로 제일 간단하게 post('item')아이템을 포스트, get('item') 아이템을 겟
- 동작과 행위와 관련되도록 설계하지 말라는 것이 Restful 설계 원칙 중 하나이다.
- .post("/", [middleware1, middleware2]) 와 같이 작성하고 middleware1에서 처리를 한 후, next()로 다음 미들웨어에게 넘겨가며 동작한다. -> **✨존경하는 J164님✨** 코드보면서 공부하기! ~~이 줄 삭제해주세요~~
- [express middleware 공식 페이지](https://expressjs.com/ko/guide/using-middleware.html)
- 각 역할 별로 여러번 호출하기
- SPA 라우팅에서 새로고침에 대한 올바른 처리가 무엇일까 주소 목록을 다시 구성하는가?
- login 페이지에서
- 메인(/)->로그인(/login)->새로고침 시, 날아간 history들을 다시 쌓아줘야할까?
- 근데, 새로고침을 해도 history는 쌓여있다!
- url과 페이지를 랜더링하는 함수가 1대1 대응인데, query나 정규표현식을 사용하면 1:m 대응으로 변경할 수 있어서 이를 활용하는 방법도 있을 것 같다.
- cookie로 현재 url의 정보를 보내주면, 사용할 수 있지 않을까?
- 함수형 프로그래밍이 가지는 장점과 단점은 무엇일까
- 함수형 프로그래밍의 장점
- 가독성 있게 표현할 수 있다.
- 함수를 작게 나눌 수 있다.
- 인간의 사고의 흐름대로 작성하기 때문에 유지보수가 쉽다.
- store Layer 에서 활용이 가능하다.
- 순수함수로 작성하며, testable 함수로 작성이 가능하다 (데이터 조작을 우리의 사고의 흐름대로)
- 함수형 프로그래밍의 한계
- 프론트 엔드는 비동기, UX, Interaction 제어, DOM 렌더링 담당임
- 비동기와 이벤트 제어를 할 때 활용이 가능할지에 대한 의문
- 입력과 출력을 예측할 수 있다.
- class component vs functional component
- [react-functional-components-vs-class-components](https://medium.com/wesionary-team/react-functional-components-vs-class-components-86a2d2821a22)
- MV* 구조를 사용하면 백엔드와 프론트엔드가 같이 있는 프로젝트에서 나누는 기준
- 프론트엔드 MVC, 백엔드 MVC가 나뉠 필요가 있을까?
- 웹 페이지를 5가지 계층으로 나눌 수 있다.
- Angular 에서 MVVM 을 참조
- Model : Backend
- ViewModel : 동적인 데이터를 불러오고 데이터를 View 에게 전달
- View : Frontend 에서 UI 를 렌더링
- 개발환경과 배포환경의 차이를 어떻게 구분해서 배포했는가
- Gihub Social Login 시 발생하는
- webpack에도 개발/배포 환경에 따라 구분이 가능하다.
- sequelize에도 mode가 있는데, 환경변수 쪽에서 바꿔줄 수 있다.
- BE : process.env 폴더에 환경변수
- FE : Webpack 설정
```json
{
test: /\.(scss|css)$/,
use: [
process.env.NODE_ENV === 'production'
? MiniCssExtractPlugin.loader
: 'style-loader',
'css-loader',
'sass-loader',
],
},
```
- ~~프론트와 백을 아예 나눠서 분리해서 개발하신 분이 있는지?~~
~~ex) FE 3000, BE 8080 포트로 하고, FE 에서 API 호출만 하는 방식~~
- ~~비동기로 데이터를 언제 가져왔는지 (렌더링 전 or 후?)~~
- MVC 를 적용했을 때 Model, View, Controller 관계 형성 및 상태 변화 알리는 방법 (추가 예정)
- 어디서 관계 형성?
- 메서드로 상태 변화를 알리기
Model -> Controller / Controller -> Model
Controller -> View / View -> Controller
- 좋은 함수를 작성하는 방법
- 함수명과 변수명을 직관적으로 작성, 느슨한 의존성
- 사고의 흐름과 동일하게 동기적인 방식
- 에러 처리를 외부로 위임인데, 에러 처리를 외부로 위임이 뭔지 잘 모르겠다.
-> 외부에서 에러 처리를 했을 때의 장점 : try-catch는 에러처리 로직이 아니라, 확인 용도이기 때문에, 같이 한다면 직관적이지 않게된다.
- 개발 생산성 높였던 방법들?
- 코드 향상 : 코드포맷팅 **prettier**, HTML 태그 표시 **es6-string-html**
- 배포환경 : 환경변수 dotenv
- 레퍼런스 모음 : cookie parking