2주차 멘토님과의 시간
- 백로그 사용시 예상 소요시간과 실제 소요시간이 차이가 많이 날 떄 격차를 줄이도록 노력을 하면 좋을 거 같음 + 백로그로 피드백을 진행했으면 좋겠음
- 백로그 일정을 잡을 때 대충 rough 하게라도 잡아서 계획을 미리 잡아놓자 -> 대분류 정도는 예상 시간을 설정하여 목표를 잡아봐라.
- 깃허브 - 프로젝트에서 지금 처럼 대기 , 진행중, 완료가 기본 => 팀별로 추가적으로 기획중, 디자인중 , 배포대기 등등으로 추가함 .
- 지금은 프로젝트에서 이렇게 하는게 맞는 거 같음 잘하고 있음 -> 장점은 이번주에 해야할 작업을 한눈에 파악하기 쉬움
- 팁 : label을 더욱 더 세분화 시키는 게 좋음 -> 분류에 따라 label 설정 -> 필터링 기능 사용 가능 -> 한눈에 파악가능
- ADR (Architecture Decision Record) : 기술 스택 사용 이유 문서 -> 문서를 작성한게 아주 good
window객체에 이벤트를 등록하여 사용할때 target의 className으로 target 분별해야하는지 Data-set을 사용하여 target을 분별해야하는지
emotion 으로 생성되는 className : 해시값, 소스 코드 내에서는 값을 참조 -> 모든 className을 알고 있어야함 -> rule만 정해놓는다면 상관 없음 -> 일반적으로는 id로 판단하는게 좋을 거 같음 멘토님이 추천하는 건 id값 or CSS CLassName (중복되지 않는다면) global 하게 이벤트를 등록하기 보다는 컴포넌트가 render될 때 이벤트를 달면 그만임 . className 을 굳이 참조할 필요가 없음 -> 라이브러리를 한번 참고해보길 바람
저희가 style관리를 Emoiton으로 사용을 합니다. inline style로 css를 관리해주는 부분이 많아지다보니 style 을 지정해준 변수값이 너무 많아져서 파일이 두꺼워지는 경우가 많아서 불편해지는데 괜찮을까요??
style 각각을 따로 변수로 선언하여 사용하는 건 css에서는 어쩔 수 없는 거 같음.
최상위는 미리 정의해 놓고 아래쪽 컴포넌트들은 static하게 사용 ...
멘토님도 emotion 사용하는데 귀찮음 .
Atomic 구조를 사용하여 최대한 쪼개서 css도 쪼개지기 때문에 파일안에 css는 작아짐 but 어쩔 수 없는 거 같음
아직까지 best는 찾지 못하심.
Atomic 구조를 이루다보니 Page를 다루는 Template과 Template을 다루는 Organism 등등 에 대해서 컴포넌트들이 체이닝 되어 구현된 부분이 많다보니 Page는 MainPage Template은 MainPageBody , MainPageHeader Organism은 MainPageBodyLeft 등 이런식으로 파일이 이루어지다보니 파일 명이 너무 길어지게 되는 문제가 생기게되었습니다..!! 조언 부탁드립니다 !
Atomic 디자인의 주요 문제중 하나
best practice는 없음.
멘토님 같은 경우 재사용이 가능한 경우 atomic이나 molecule...쪽으로 집어넣고 재사용이 안되는 컴포넌트의 경우 하나의 디렉터리(template)에 박아두심 (기존 template의 목적에는 맞지 않지만) => 오히려 한 디렉터리에 몰아넣는게 편할 수 있음
or 아토믹 구조에 맞게 각 디렉터리에 맞게 분류해도 됨
저희 팀원 중 한 명이 스프린트 기간 동안 컴포넌트간 props로 전달 하는 대신에 children으로 넣어서 사용하라고 하는 리뷰를 받았었는데,
깃 전략