CoStudo 프로젝트 13주차 주간 회고록 🙂
2022.12.05(월)
TIL 🧐
- 자스 스터디
- this, class 복습
주절주절 😗
리액트로 바꿔 생각하기
햄디가 페이지 레이아웃을 만들고 있는 중이다. 현재 디자인에 페이지 레이아웃이 다양하다보니 prop으로 여러 타입을 선택할 수 있게 했는데, 생각해보니 하나의 페이지 레이아웃으로 여러 모양을 만드려다 보니 prop이 다양해지는거 같다.
생각해보니 container에 전페이지 공통 배경색과 위아래 padding 등을 주고, 그 안에 contents에 가운데 정렬을 할 max-width를 줬었는데 지금은 하나의 컴포넌트로 하려다보니 여러 페이지를 고려하기 힘들어진거 같다.
Layout 폴더에 container 역할을 하는 Main 컴포넌트를 추가해서(main 태그는 전페이지에 항상 들어가야하니까) 지금 구현해놓은 outlet을 Main 컴포넌트의 children으로 넣어둔다. 그리고 pageLayout 컴포넌트가 contents 역할을 해서 넓이가 정해지고 가운데 정렬해야하는 페이지에는 pageLayout으로 감싸는 것이다.
html로 작업할 때는(예전에 작업했던 코웨이 페이지) 자연스럽게 생각났던게 리액트로 하니 잊고있다 그렇게 했었지하고 기억이 났다. 내일 스크럼 때 얘기하고 햄디에게 수정 요청을 해야겠다.
아쉬워요 🙁
딥다이브보고 축구 보느라 플젝을 많이 못했다ㅠ
잘했어요 🙂
리액트로 바꿔 생각하기..
2022.12.06(화)
TIL 🧐
- 프로젝트
아쉬워요 🙁
HTTP 통신은 아직도 모르는게 많은거 같다. 실제 업무에서 사용하는 API로 좀 더 연습해보고 싶다. 내일 좀 찾아봐야겠다.
잘했어요 🙂
축구보느라 낮잠을 자서 잘한거 없음ㅠ
2022.12.07(수)
TIL 🧐
- 프로젝트
- Axios API 읽어보기
- query vs param vs body
- react에서 query, param 가져오기
- 스터디 공지사항 리스트 Mock API 구현
아쉬워요 🙁
오래만에 했더니 잊어버린 부분이 있어서 복습했다 ^_ㅠ
2022.12.08(목)
TIL 🧐
- 프로젝트
- 스터디 공지사항 리스트 페이지 구현
주절주절 😗
tag 중첩
Text, FlexBox 컴포넌트를 사용하면서 예상했던 태그 중첩이 깊어지고 있다ㅠㅠ
ThemeProvider에 font 속성은 적절하지 않다고 팀원들이 생각하여 font관련 속성을 가지고 있는 Text 컴포넌트를 만들자는 의견이 나오게 됐다.
Text에는 as로 사용할 수 있는 태그에 제한이 되있는 상태라 flex 관련 css와 font관련 css를 같이 필요로 하는 컴포넌트가 있다면 FlexBox와 Text 컴포넌트로 두번 감싸야한다.
이런 식으로 곳곳에 태그 중첩들이 늘어나고 있어 고민이다. 해결 방법은 as에 모든 태그를 허용하던가 Text를 사용하지 않고 theme으로 typography를 받아서 사용해야 한다.
태그 중첩이 안좋다고 막연히 알고있어 찾아봤더니 toast UI - 성능 최적화에서 보니 중첩이 많아지면 DOM 트리를 생성하는 시간이 길어져 DOM 트리 노드수 권장 개수 제한이 있다고 한다.
권장하는 DOM 트리의 노드 수는 전체 1500개 미만, 최대 깊이는 32개, 자식 노드를 가지는 부모 노드는 60개 미만이다. (참조: Excessive DOM) 다음 주 회의 시간에 한번 얘기해봐야겠다.
아쉬워요 🙁
페이지네이션 컴포넌트까지 구현하고 싶었는데 다하지 못했다.
작업 시간에 비해 구현량이 많지 않은 듯하다. 물론 고민도 많고 학습도 하면서 구현하느라 그런거지만 고민을 좀 더 줄이고 일단 구현해보는 중점을 찾아야할 거 같다.
잘했어요 🙂
컴포넌트 작업만 한달 넘게 했다보니 데이터 받아와서 페이지에 보여지는데 반가웠다.. 언능 상세 페이지도 작업해야지!
2022.12.09(금)
TIL 🧐
- 피어세션 두 탕(프로젝트, 스터디)
주절주절 😗
서로 다른 4명
오늘 프로젝트 피어세션이 끝나고 팀원끼리 서로 피드백과 고민을 나누는 시간을 가졌다.
예전부터 느낀거지만 파크랑 나랑 개발스타일이 제일 다른 것 같다.
파크는 완전 애자일?스럽게 일단 구현하며 부딪혀보자 주의고 나는 고민하며 일어날 수 있는 일을 대비하는 코드를 짜려한다.
파크는 개발에서 예상을 한다고 해서 그 예상대로 되지않는다고 생각하는 편이고, 나는 예상 가능한 부분이 있다면 고민해보고 반영하자는 생각이다.
둘 다 장단점이 있다고 생각한다. 파크 스타일은 빠르게 구현이 가능하고 예상한다고 해서 그 예상이 항상 맞지 않을 때도 있다. 그러나 얼마전에 theme을 수정하면서 기존의 theme으로 되어있던 코드들을 전부 수정하는데 굉장히 번거로웠다.
이렇게 대대적으로 수정할 일이 생기지 않기 위해서 예상을 좀 해보고 구현하자고 생각하는 주의다. 그러나 파크와 달리 고민하는 시간이 길어져 상대적으로 속도가 느리다. 그래서 고민했던게 내가 뚜렷하게 예시를 들 수 있는 부분이라면 진짜 예상 가능한 부분이면 반영하자고 생각했다.
의견 주장도 각자 정도가 다르다. 햄디는 다른 사람의 의견을 일단 수렴하고 구현하면서 문제점이 생긴다면 얘기하는 편이고, 나는 내 의견이 있으면 어필을 하는 편이다.
4명 다 성격이 달라서 토론이 더 활성화되지 않나 싶다. 이전에 프론트가 두 명일 때는 서로 의견이 다를 때 정하기가 힘들 때가 있었는데 4명이다 보니 중간 의견을 수렴하기가 쉬워지고 좁혀지지 않는다면 다수의 의견에 따르기도 한다. 말그대로 답이 없는 부분들이였으니!
아쉬워요 🙁
오늘 피어세션들이 길어지고 금요일 밤이 되니 쉬고 싶어 구현을 아주 조금했다 ^_ㅠ
잘했어요 🙂
그래도 의미 있는 토론들로 시간을 보내 좋다!
