프로젝트 소개
- 개발 기간 : [ 2021.12.27 ~ 2022.01.06 ]
- 개발 인원 : Frontend(4), Backend(1)
- Frontend Tools
- JavaScript(ES6) / React Hook (v17) / SASS / sider
- Github / Slack / Trello
- React packages : react-router-dom
- eslint / prettier
- Github
Frontend Repo
Backend Repo
📺 데모 영상
📋 What I Did
네비게이션 바
- Scroll에 따라 보여지거나, 사라지는 기능
- 로그인, 회원가입, 여러 버튼들 클릭시 라우팅
- 토큰 삭제를 이용한 로그아웃
- 햄버거 버튼 클릭시 hidden side menu가 보여지는 기능
- hidden menu 내부의 수직 / 수평 리스트 자체 스크롤
- 수직 / 수평 리스트에 대한 커스텀 스크롤바
메인 페이지
- 전체 화면 슬라이더
- flex 영역에 2개의 상품이 있고, 각각 2개씩 이미지가 담겨 움직이는 슬라이더
- sticky를 활용한 스크롤 이벤트 적용 영역
Footer
- 모든 페이지 하단에 적용될 Footer 작성
재사용 컴포넌트
- 경계선이 있는 버튼
- 슬라이더 영역의 '이전, 다음' 버튼
- Main 페이지의 flex 영역 슬라이더
- Main 페이지의 sticky 영역 틀
- 최상위로 이동하는 Top 버튼
- Skeleton UI
Custom Functions
- throttle : 스크롤 이벤트의 과다 발생을 방지함
- getUserToken : 통신시 token을 가져오는 함수
Custom Hooks
- useScrollFadeIn
- Intersection Observer를 활용한 교차 관측시 영역 Fade In - useScrollbarHidden
- 호출시, 해당 컴포넌트가 렌더링되면 body의 scrollbar를 보이지 않게함 - useToggleNav
- scroll down시 navigation hide, scroll up시 navigation show - useHorizontalScroll
- navbar 히든 영역의 수평 리스트 스크롤 이벤트 - useVerticalScroll
- navbar 히든 영역의 수직 리스트 스크롤 이벤트
🚀프로젝트가 시작될 때...
첫 인상
일단, 좋았다!
패션을 고민하는 나로선 레퍼런스를 확인하기 위해 페이지를 볼 때마다 재미없을 수가 없었다.
같은 프로젝트를 하게 된 팀원분들은 이미 서로 잘 알고 있는 사이였다보니
팀원이 누군지 발표됐을 때, 물론 새로운 사람들을 만나고 싶었던 것도 맞지만 오히려 협업의 시작을 이 사람들과 하게 되어 다행이다 라고 생각했다.
오히려 안면이 없는 분들과 팀을 했다고 상상해보면, 물론 서로 배려하는 듯한 말과 행동은 하겠지만 스스럼없이 나오지 않았을 것 같다. 친해져야 말 수가 많아지다보니, 극단적으로 말 수가 줄어들었으려나.. 그랬다면 그동안 해온 것의 60% 정도만큼의 의욕만 가지지 않았을까?
목표
구현에 대해
해야되는 일이 있어도 흥미가 돋지 않으면 나라는 사람, 발을 떼기가 매우 어렵다.
검색해서 자기 것처럼 써먹는 나름의 재주(?)가 있다보니, 그것이 오히려 '언젠가 하면 무조건 되겠지~' 하는 생각을 은연 중에 떠오르게 만든다.
일단 이것 때문에 팀원들에게 부끄럽고 싶지 않았고 또 지금까지 React와 밀당을 했다면 이젠 한없이 당기고 싶은 설렘이 한창 진행 중이었다.
그렇게 나는, 가장 현란해보이고 어지러워 보이는 메인 페이지를 직접 골랐다.
협업에 대한 태도
다른 프로젝트 팀의 어떤 분께서, 프로젝트는 개개인의 능력에 달린 것이 아니라 벡터의 합이 만들어내는 결과였던 것같다는 회고 멘트를 날려주셨고, 이 의견은 처음 회의를 할 때부터 가지고 있었던 목표였다.
내가 다른 이들에게 비춰졌을 때 이러한 태도를 가지고 함께 하는구나! 라고 느꼈으면 좋겠다는 생각을 항상 가지고 팀원분들께 다가가려고 나름 노력은 했는데, 그렇지 않다고 느낀 팀원분들이 있다면 이 글을 통해 사과드리고 싶다.
선언형... 선언형을 기억해라..
전공자인 나는 이것저것 여러 언어를 많이 건드려봤었는데
항상 '객체 지향형 프로그래밍' 을 들먹이면서도 실제로 그것을 지킨 것은 많지 않았던 것 같다.
특히나 React는 선언형을 지향하기에 평소의 나와는 정반대라고도 할 수 있었는데
그동안 애매했던 그것이 확실해진다는 생각을 받으며, 이번 프로젝트는 누구나 읽어도 이해가 되는 선언형 코드를 만들자는 목표를 세웠다.
😳 프로젝트를 하며 느낀 점
잘했던 것들
'이 팀, 잘 되고 있는거죠..?'
코드 리뷰 때였나... 언제였나.... 정확히 기억은 나지 않는데 아무튼. 언젠가 멘토님께서 지나가다 왜 이렇게 조용하게 반응하냐면서 넌지시 던진 이야기였다.
하지만 우리 팀원들, 겉으로 보면 조용하지만 가끔 던지는 말투가 재밌게 맵다.
가끔 등 뒤로 들려오는 희원님을 중심으로 한 티키타카를 듣다보면 이마를 절로 탁! 치곤 했다.
튀지는 않았지만 흔들리지 않는 분위기를 유지한 것이 잘했던 점 중 하나였다.
두번째로 잘한 것은 맺고 끊음이 확실했고, 직설적으로 표현했던 점이었던 것 같다.
늘어지게 놀다가도 미팅이나 코딩하는 시간은 빈틈이 없다. 코리안 타임이라고, 약속시간보다 5분 정도는 늦을 수도 있고 나는 나름 그럴 수도 있지~ 하며 용인하는 편인데 우리 팀원들은 왠만하면 정해진 시간보다 더 빨리 모였다.
그리고 스크럼 미팅을 할 때 말이 가끔 길어지면 부드럽게 끊으며 집중력을 유지한 것.
모르는 것을 혼자 품고 고민하지 않고 서로 같이 코드 좀 봐줬으면 좋겠다며 적극적으로 다가가고, 또 그 옆을 함께하며 같이 생각하고 해결의 방향으로 나아갔던 것들.
덕분에 누군가는 분명히 헤맸을 초기 세팅과 각자 초반 레이아웃을 잡는 단계를 큰 어려움없이 통과했다.
분명 당장 닥쳐올 다음 프로젝트가 되든, 그리고 앞으로 있을 수많은 초면일 사람들과 함께 일을 해야될 때 내가 어떻게 처신하며 대응하면 되는가? 에 대해 약간의 답을 찾을 수 있었어서 좋았다.
물론, 이 사람들이기 때문에 더 잘됐다.
아쉬웠던 것들
이 정도면 뭐... 괜찮겠지... 하며 넘어갔던 부분들이 너무나도 아쉽다
git push 주의사항
아마 다들 branch를 분리하고 작업하는 것이 처음이었을텐데, 미리 push하기 전에 main을 꼭 최신화하고 넣어달라고 하지 않은 게 기억난다.
뭐.. 어떻게든 되겠지... 했던 마인드였는데 결국 발표 전날에 그것을 발견했고 순간 사고회로가 정지했다.
코드 컨벤션, 우리끼리의 합의
또한 코드 구현에 대해 어느정도 약속을 맞추고 시작할 걸, 하고 두고두고 후회한다.
소소하게 예를 들면, 나는
hook -> custom hook -> pacakge -> custom functions -> mockdata -> css
이러한 import 순서를 무조건 지키려고 하고
state -> local func or variables -> effects -> return
이 순서대로 컴포넌트를 항상 작성하다보니, 다른 순서로 작성한 코드를 보면 이해하는 데에 시간이 더 소요되는 편이다.
다른 팀원들이 감사하게도 헬프를 요할 때, 가서 빠르게 이해하고 알려주거나 고민했어야했는데 그 귀한 시간의 비중에 이해의 영역이 꽤 컸다는 것이 아쉽다.
정현아, 너 아직도 px쓸래?
처음 닥터마틴 메인 페이지 레이아웃을 따올 때가 기억난다.
전체를 덮는 width 100%. 그 아래에 적용된 width:1140px와 margin: 0 auto.
navigation bar는 대충 125px의 높이를 가졌었던가..?
이걸 보고선 Nav를 담당하던 나는 팀원들에게
1140px 기준으로 너비 설정하시고, 그 안에서 작업해주세요~
그리고 본인 영역에서 padding-top:150px 설정해주세요!
어... padding값은 그럴 수 있다고 쳐도 width를 그냥 그렇게 줘버린 것은 돌아보면 그렇게 해서는 안됐다.
팀원분들이 모두 깔끔하게 레이아웃을 작성해주셔서 큰 문제 없이 화면은 완성되었지만
이것은 초기에 우리가 고민했던 '반응형'과는 거리가 멀었으며
당장 내가 구현한 main 페이지의 슬라이더 영역이라던가, sticky scroll event가 발생하는 영역이라던가. 생각없이 '2주차에 고칠 것으로 남겨두자... 별거 아니니까' 란 생각으로 대충 px나 %를 넣어줬고 나중에 듀얼 모니터 쪽으로 웹 페이지를 이동시켰을 때 무지막지하게 후회했다.
어쨌든 vw,vh를 잘 활용해 다 정리해뒀지만. 그건 나의 이야기가 되고 팀원들에 해당되는 것은 아니기에 꼭 이 부분에 대해 팀원분들에게 이야기를 해야겠다.
나는 생각보다 한 가지에 많이 매몰된다.
이번 프로젝트를 하며 가장 신경썼던 것은 최대한 Declarative 한 코드를 작성하자는 것이었다.
곧 포스팅될 주제인데, 나는 React라는 라이브러리는 자기밖에 모르는 이기적인 친구라고 느꼈었고
그에 따라 Main 페이지는
이렇게 됐다. Main이라는 컴포넌트는 각 컴포넌트가 뭐하는지는 별 관심이 없다.
그냥 Main은 저 컴포넌트를 보여주기만 하는 녀석일 뿐이다.
물론 props의 sectionArea를 통해 어떤 녀석인지 명시는 해두었지만
컴포넌트의 이름 자체를 How 형태로 했으면 더 깔끔했을 것 같다는 잠깐의 반성을 거쳐본다.
그리고 또 오해한 것 중에는, 그렇다면 부모 컴포넌트는 자식들이 뭔지만 얘기해주면 되는거고
실질적인 동작은 자식들이 해주면 되겠지... 이런 생각을 가지고 있었는데
자식들도 어떠한 자식 컴포넌트를 또 가질 수도 있는 거고.
굳이 동작을 그 안에서 해결해야하나? 커스텀 훅으로 빼던가, 따로 함수를 만들던가.
그리고 이 프로젝트에서는 패키지의 사용을 최대한 지양했지만 단순히 npm에서 가져왔어도 되는거다.
코드가 워낙 길어 가져오진 않겠지만, 나는 이 생각에 빠져 실제로 그러한 동작을 자식 컴포넌트에 작성해버렸고 위의 반성을 결국 프로젝트의 말미에 가서야 느끼면서 리팩토링 작업을 거쳤다.
그리고 틀이 똑같지만 내부 요소들의 배열이 미묘하게 달랐거나 아예 달랐던 경우에 대해서는 이 접근이 너무 과한 압축이 될 수 있겠구나...라는 생각을 했다.
어디까지나 필요와 공통성에 의해 컴포넌트를 나누고, 이 영역이 독자적인 영역인가? 혹은 다른 영역과 겹치는 비중이 얼마나되는가? 에 대해 의심하려고 한다.
📑기록해야할 코드
스크롤바를 죽여라!
Navigation bar의 햄버거 버튼을 누르면 useScrollHidden() 이라는 훅이 실행된다.
이 훅은 우선 현재 스크롤바의 overflow 값을 저장해두고, hiddenMenu 컴포넌트가 렌더링되면
해당 overflow를 hidden으로 돌려 스크롤바를 죽였다가 컴포넌트가 unmount되면 다시 overflow를 원상복구시킨다.
난 아직도 react hook의 생태계에서 찍먹러라는 자각을 가져야된다는 의미로서 이 코드를 남긴다.
이 hook에 대한 설명은 여기에 포스팅되어있다.
똑같은 영역인데... 이벤트가 달라야된다고?
반응형으로 바꿀 때 말썽을 일으켰던 주범 중 일부...
계산기를 두드리게 만들었던 장본인..!
단위 길이가 px일 때는 각 section의 고정된 위치를 단순히 매핑하기만하면 되는 일이지만
문제는 모니터의 크기에 따라 그 위치들이 애매하게 바뀐다는 점이다.
덕분에 해당 영역의 시작점에 들어섰을 때부터 어두워지는 효과가 일어나야하는데 미리 일어난채로 사용자에게 나타난다거나, transform이 미리 되고 있다거나..
게다가 의도한 것보다 더 크게 줌인된다거나 하는 곤혹을 치뤘다.
방금 서술한 것과 같이, 단순히 해당 영역의 시작점을 알기만하면 되니
각 이름이 다르게 지어진 영역의 시작 태그에 ref를 붙이고 처음 페이지가 렌더링되었을 때의 top 값을 받아오게끔 하게 처리해 지금은 어떤 크기의 모니터라도 시작점에 오면 그 때부터 이벤트가 발생하도록 잘 변경됐다.
다만 section이 많아진다면 지금의 3개의 ref로는 부족할텐데, 좀 더 통합하여 관리할 수 있는 아이디어는 없을까? 라는 고민을 갖고 있다.
커스텀 스크롤바
진짜.. 스크롤의 지옥에 애꿏은 계산기만 열냈다.
우선 이건 hiddenMenu에 들어간 수직 리스트인데,
스크롤될 길이보다 내부 요소의 길이가 작다면 스크롤되지 않아야 한다.
예를 들어 스크롤 길이가 150h일 때, 30h를 가진 요소는 5개까지 처음에 보일테다.
그렇다면 만약 요소가 5개보다 많다면?
스크롤 한번당 30h씩 위로 올라가든, 아래로 내려가게 만든다.
로직을 정리하면,
- 내부 요소의 길이를 모두 더한다음 스크롤 영역만큼 뺀다.
- 해당 값을 초과된 갯수만큼으로 나눠 translate값을 뽑는다.
- scroll Up / Down의 경우에 따른 동작을 정의한다.
- 스크롤영역으로 판단됐다면, 이벤트를 발생시킨다.
처음에 무작정 머리 속으로만 생각하면서 코딩하다가 도저히 머리가 아파 종이에다가 손으로 하나하나 써서 구현한 부분이다.
차근차근 언제 스크롤이 가능한지, 스크롤은 얼마나 되어야하는지?에 대한 생각을 정리하니 그렇게 안되던 것이 마법처럼 해결됐다.
뭔가 되지 않고 있다면, 잠깐 내려놓고 실타래부터 조금씩 풀어보자는 다짐을 하게 된 코드였다.
📻 주저리주저리
다음에 하고싶은 것
다음 프로젝트 때는 패키지의 사용이 해금(?) 된다고 한다.
그 의미는 즉슨, api를 이거저거 가져와도 되는 거고..
슬라이더를 공을 들여가며 직접 구현하지 않아도 되는거고..
갑자기 해이해지는 기분이 들지만 오히려 코드 퀄리티를 위해 적절한 타이밍에 npm을 검색하여 필요한 것을 꺼내다쓰며 Output을 뽐내고 싶다.
이번 프로젝트에서는 다소 백엔드와의 통신이 많지 않았다.
나름 DB도 꽤 써봤고, Node도 찍먹해봤기에 누구보다(?) 서로를 잘 이해하며 소통할 자신이 있었는데, 그게 조금 아쉬웠다.
다음엔 오히려 백엔드와의 소통거리가 많을 것 같은 분야를 맡고 싶다. 그렇다면 state도 매우매우매우 많이 사용할 것 같고 React와 베프가 되는 계기가 될 것 같다.
마지막으로, 체력 관리를 좀 더 잘해야겠다.
발표를 모두 맡아 진행했었는데, 힘이 없다보니 텐션도 낮고, 목소리도 왠지 갈라진 것만 같고. 머리도 잘 안돌아가니 적절한 문장이 나오지 않아 내가 생각해도 그렇게 좋은 발표는 아니었던 것 같다.
