오늘은 하루종일 뷰만 잡았다. 페이지 수가 많아도 세 명이서 나누니 할만하다 생각했는데, 머리가 셋인 만큼 각자 생각이 다르니 컴포넌트 사이즈 단위도 다르고, 같은 회색 계열 중에서도 설정하는 색상이 다르고, 적당하다 생각하는 마진도 달랐다. 100%까지는 아니어도 나중에는 어쨌든 통일을 해야 할 텐데. 하지만 코드로 짜서 yarn start를 돌려보기 전까지는 어떤 게 적당한 건지 나 혼자서도 알기 어려운 노릇이니 뾰족한 수를 모르겠다. 이렇게 웬종일 뷰만 잡아도 다 끝내지 못했다. 깃허브 저장소를 어제 만든 것 같은데 벌써 커밋이 36개다.
아침 회의 때 프로젝트 이름을 정했다. 어제 자정까지 온라인 투표를 진행한 결과 두 이름이 동점이었는데, 오늘 아침에 다시 한번 투표를 해서 내가 제출했던 '토크부트(Talk'bout)'로 확정됐다.
S.A 제출할 때 필수적으로 들어가야 하는 내용이라, 팀 전체의 타임라인을 함께 설정했다. 프론트는 어제 저녁에 Miro에서 대강 정해놓은 내용을 거의 옮겨 적었다. 당장 내일도 무슨 일이 일어날지 모르는데 몇 주 앞의 계획을 어떻게 하나하나 자세히 짤 수 있을까. 어차피 애자일인걸! :)
백엔드에서 API 리스트를 만들고 공유해 주셔서 다함께 살펴봤다. 수정할 점이 아예 없는 건 아니지만, 아무튼 어쩌면 그렇게 뚝딱 만드셨을까. 볼 때마다 신기한 분들이다. API 리스트를 보고 있자니 새로운 프로젝트가 시작한 게 확 실감이 났다. 그리고 API는 보면 볼수록 처음 보는 것 같다.. 새롭다.
프론트끼리는 최소 단위 컴포넌트인 엘리먼트들을 만들었다. 프론트가 세 명이니 엘리먼트도 한 시간 반 만에 다 만들어졌다. 역시 일손은 다다익선인가 보다.
오후 6시에는 디자이너님들까지 껴서 8명이서 전체 회의를 했다. 주제는 1차로 나온 와이어프레임이었는데, 다룰 만한 건 정해져 있다고 생각했는데 얘기는 자꾸자꾸 길어졌다. 그리고 우리가 뷰를 잡는 데 최종적으로 쓸 만한 와이어프레임은 한참 뒤에야 나올 것 같은 불길한 예감이 들었다.
PWA와 PWA에서 구현 가능한 푸시 알림 기능에 대한 자료를 찾아보았다. 지금은 읽어보아도 무슨 소리인지 잘 와닿지 않았지만, 조만간 필요할 때가 오면 절실하게 읽게 되지 않을까 싶다.
정규표현식에 대한 유튜브 영상을 봤다. 정규표현식은 외계 문자 같은데, 영상을 보고 나니 그 문법을 다 외우지는 못해도 이제는 어떤 건지 알 것 같다.
리액트 공식문서를 '조건부 렌더링'과 '리스트와 Key'까지 읽었다. 읽는 도중 자꾸 눈이 감겨서 혼났다. 겨우겨우 정신 차려가며 두 장이나 읽은 나, 칭찬해!
내일 할 일
게시판에 들어갈 컨텐츠에 대해 다시 한 번 팀 단위로 논의한다.
언제까지고 와이어프레임만을 기다리고 있을 수만은 없다. 나중에 디자이너님들의 시안에 맞춰 다 뜯어고치는 한이 있더라도 내일부터는 본격적으로 뷰를 잡아야겠다.
쉬는 날이었지만 온전히 쉬지는 않았다, 언제나 그렇듯. 예정대로 정오에 회의가 있을 줄 알고 프론트는 모두 출근했지만 회의는 없었다고 한다. 그래서 오늘까지 제출하기로 한, 각자 생각한 프로젝트의 이름은 슬랙에다가 올리고 우리끼리만 신나게 회의를 했다. 디자이너 분들이 올려주신 로그인, 회원가입, 마이페이지의 와이어프레임에 대한 피드백을 공유한 후 각자 슬랙에 올렸다. 그 외에는 우리 프로젝트의 컨텐츠가 일반적이고 전형적인 만큼 뷰라도 조금 특색 있었으면 해서, 와이어프레임 구조 자체의 변경에 대해 내가 의견을 종합해 팀장님께 말씀드렸다. 사실 혼자만 말씀드릴 생각은 없었고 팀장님의 생각이 궁금해서 그렇게 했던 거였는데, 어쩌다 보니 그 자리에 디자이너 분도 바로 참석하시고 해서 어찌저찌 팀장, 프론트리더, 디자이너의 맞대결회의가 펼쳐졌다. 다행히 디자이너 분이 애초에 우리가 생각한 대로 구상할까 고민하셨었다고 하셔서, 우리의 요청사항은 잘 반영될 수도 있을 것 같다.
제출된 프로젝트 이름 후보에 대해 온라인 기명 투표를 했다. 아직은 결과가 안 나온 것 같다...? 내일 아침 회의 때 알 수 있으려나.
내일 제출해야 하는 S.A에 포함되어야 하는 사항이 주제, 와이어프레임, API, 타임라인이어서 저녁에 프론트끼리 다시 모여 타임라인을 주차별로 간단히 설정했다. 회의 시간이 길어진 것에 비해 결과물은 별로 없었지만... 아직 와이어프레임도, API도 확정되지 않은 상황에서는 어쩔 수 없다. 내일은 추후 디자인적으로 변경이 된다 하더라도 기본 엘리먼트들만 만들기로 했고, 작업량을 적절히 분배했다. 깃 커밋 메시지에 대한 컨벤션도 간단하게나마 정해보았다.
리액트 공식문서 'State와 생명주기', '이벤트 처리하기'를 읽었다.
내일 할 일
아침 9시 회의에 늦지 않게 참석한다. 타임라인, API를 백엔드 분들과 함께 설정한다.
깃헙 저장소를 만들고 브랜치를 만들고(브랜치 만들어 보는 거 처음이다..!) 템플릿을 넣는다.
본격적인 첫 팀 회의였는데 어제 늦게 자서 그런지 30분이나 지각하고 말았다..ㅠㅠ 이제 꼭 반드시 기필코 자는 시간을 앞당겨 보리라.
지각했는데 심지어 게더도, 줌도 자꾸만 터졌다(나 한정). 인터넷이 문제인 것 같았다. 지금까지, 아니 어제 아침 프로젝트 발제 때만 해도 100명도 넘게 있던 줌 회의실 멀쩡하게 잘만 돌아가더니 왜 오늘은...ㅠㅠ 모바일로 접속해야 그나마 원활했다. 모바일이 데스크탑보다 잘 돌아간다는 게 말이 되냐고요ㅠㅠ
거기다 더해 오늘은 개인 일정이 있어서 자리를 오래 비웠다. 세 가지 문제가 다 겹쳐서 회의 내용이 내 것처럼 느껴지지 않고 겉도는 것만 같은 기분이다. 글자 하나하나 꾸역꾸역 머리에 집어넣으려고 노력하고 있다.
리액트 공식문서를 'Component와 Props'까지 읽었다. 친절하고 쉽게 쓰여진 공식문서라지만 가끔 무슨 소리인지 모르겠는 건 왜일까.
내일 할 일
내일은 제발 인터넷에 문제가 없었으면 좋겠는데... 갑자기 생긴 문제이니 갑자기 사라졌으면...
일요일이지만 S.A 제출이 월요일인 관계로 시시때때로 회의에 참석할 예정이다. 와이어프레임이 내일 중으로 모두 확정된다면 뷰 작업도 시작하게 될 것 같다.
깃헙 리드미에 클론코딩 프로젝트에서 구현한 기능에 대해 간단하게 적어두었다. 오늘 바로 제대로 작성하는 게 최선이고, 하지 않으면 나중에 기억에 의존해서 꾸역꾸역 해야 한다는 걸 알지만 어쨌든 오늘은 뭘 더 하고 싶지가 않았다.
실전 프로젝트 발제 때 팀 빌딩 관련 공지가 있었는데 다들 반대 의견이 많았다. 팀 정원의 절반 정도만 되는 인원들로 랜덤하게 조를 편성한 다음, 실전 프로젝트의 팀장이 속한 조와 속하지 않은 조가 서로 합쳐서 한 팀을 만드는 방식이었다. 게더와 줌에서 여러 가지 방식에 대한 논의를 거친 후에, 사람들이 팀장의 기획안을 보고 1~3지망을 제출하면 2명은 팀장이 직접 뽑고 나머지는 다른 기준들을 적용해서 배정되는 방식으로 변경되었다. 팀 배정은 오후 7시에나 발표가 되었는데, 처음부터 원했던 팀에 들어갈 수 있어서 다행이었다.
그리고 우리 팀 프론트엔드는 3명이었다. 지금까지의 프로젝트들이 1주일 내에 완성해야 하는 것들이었고 그래서 더 일손이 달렸던 거였지만, 아무튼 제발 이번만큼은 3명이었으면 좋겠다고 계속 생각해 왔는데 이것도 참 다행스러운 일이었다. 어쩌다 보니 프론트 리더가 되어서 막중한 책임이 생겼다. 나는 아직 많이 부족하고 모르는 것도 많은데 이 일을 잘 해나갈 수 있을지 조금 걱정이 된다. 하지만 프론트 회의 분위기가 워낙 좋아서 그런 걱정도 다 잊혀지는 듯했다.
리액트에 대한 체계적인 공부가 필요할 것 같아 공식문서를 정독하기 시작했다. 이걸 이제야 시작한다는 것도 웃기지만, 아무튼 급한 만큼 얼른얼른 속도를 내야겠다. 오늘부터 지혁님과 노션에서 각자 공부한 내용을 공유하기로 해서 공식문서 앞부분에서 따 온 내용을 간략하게 적었다.
내일 할 일
아침 9시 30분에 팀 회의에 참석한다. 오늘 프론트 회의에서 오갔던 얘기들을 다시 한 번 정리한다.
드디어 프로젝트 결과물 제출 기일이 되었다. 수정사항 반영해서 마지막으로 로컬에서 확인해 보는 중에, 검색 결과에서 [관련순] 버튼을 눌러도 게시글 순서가 바뀌지 않는 원인이 모든 페이지에 들어가는 뉴스 목록 컴포넌트에 무조건적으로 날짜 내림차순 정렬이 적용되어 있기 때문이라는 것을 알게 되었다. 급히 수정했다. 검색 결과를 보여주는 방식은 [최신순]과 [관련순]이 있었는데 이 버튼을 누르면 어차피 서버에서 날짜순과 관련순으로 구분해서 데이터를 넘겨주기 때문에, 검색 결과를 보여주는 창에서는 굳이 프론트에서 날짜 내림차순 정렬을 하지 않아도 됐다. 그래서 검색어를 뉴스 목록에 props로 넘겨주고, 검색어가 있는 경우에는 서버에서 들어오는 데이터에 날짜 정렬을 아예 적용하지 않는 방식으로 해결했다. 마지막 배포 전에 후다닥 해치울 수 있어서 다행이었다.
프로젝트 제출 페이지에 넣을 시연 영상을 찍었다. 찍는 게 서툴러서 몇 번을 다시 찍었는지 모르겠다. 제출하고 보니 우리 조가 첫 번째였다. 지금까지 무엇이 됐든 이렇게 일찍 제출해본 적이 없었는데. 왠지 감격스러웠다.
오늘은 피곤이 극에 달해 몇 시간에 한 번씩 자꾸 잠을 잤다. 아침에도 회의 시간에 맞춰 겨우 일어나고, 점심 먹고 나서 다시 자고, 일어나서 조금 하다가 오후 9시쯤 또 자고 다시 일어나고.
내일 할 일
프론트엔드 깃헙 리드미 파일을 좀 작성해야 할 것 같다. 지금껏 한 번도 작성해보지 않아서 어떤 식으로 적어야 할지 모르겠지만... 지금이 뭔가 남길 수 있는 마지막 기회일 것 같다.
내일은 드디어 마지막, 실전 프로젝트가 시작되는 날이다. 조 편성부터 어떻게 될지 많이 궁금하다. 6주라는 기간이 주어지는 만큼, 지금까지처럼 무리하지 말고... 잠도 줄이지 말고... 긴 호흡으로 꾸준히 잘 버틸 수 있으면 좋겠다.
오늘은 주로 CSS 관련 작업만 계속 했다. 메인 페이지의 상단 카테고리 바를 스크롤을 내려도 브라우저 상단에 고정되게 만들었다. 스크롤 높이에 따라 카테고리 바가 고정되거나 고정되지 않는 것을 조정해야 하는 줄 알았는데, 단순히 position: sticky 속성을 주니 해결됐다.
또, 카테고리를 클릭하면 해당 카테고리 아래에 테두리가 생기게 했다. :active 의사 클래스를 사용하면 마우스 클릭 버튼을 누르고 있는 동안 특정 CSS 속성을 활성화하는데, 이걸 유지하는 데에만 신경을 썼었다. 하지만 이것도 해당 카테고리를 클릭하면 들어가 있는 window.location.pathname을 따 와서 이게 카테고리와 일치하는 경우에만 CSS를 주도록 만들었다.
입력한 검색어에 해당하는 검색 결과가 없을 때, 검색 결과가 없다는 걸 알려주는 페이지 하단에 추천 검색어가 뜨는데, 해당 검색어를 클릭하면 그 검색어에 대한 검색 결과 페이지로 넘어가도록 했다.
어제부터 고전하던 로딩 스피너 문제를 드디어 해결했다. 물론 내가 아니라 튜터님이^^; 우리는 어떻게든 해결해보겠다고 이틀 내내 구글에 별 검색어를 다 적어넣으며 샅샅이 찾아봤는데, 그때마다 '아니 로딩 스피너 하나 제대로 붙이는 게 이렇게 어렵다고!?' 라는 말을 하곤 했다. 데이터가 로딩되는 중에는 스피너를 보여주고 싶은데, 꼭 스피너가 나오기 전에 데이터가 로딩되지 않은 미운 컴포넌트가 잠깐 반짝하고 보이는 현상이 있었다. 그래서 루트 컴포넌트인 app.js에 스피너를 넣으려고 시도하던 중이었다. 구글링해서 찾은 내용에 따라 app.js를 함수형 컴포넌트에서 눈에 익지도 않은 클래스형 컴포넌트로 억지로 바꿔가며 끼워 맞추고 있었는데 그러고 나니 끔찍한 혼종(데이터 로딩이 완료되었는데도 스피너가 그 위에서 중첩되어 계속 돌았...다..)이 탄생하고야 말았다. 마침 그때 튜터님이 빛처럼 강림하셔서 뚝딱 해결해주고 가셨다. 구글에서 대충 긁어 온 코드를 갖다붙인 나로서는, 튜터님이 하나하나 코드에 대해 물으실 때마다 내 대답이 시원찮아 너무나 민망했다. 튜터님은 어떤 상황에서 로딩 스피너를 붙이려고 하는 건지 차근차근 생각해보면 어려울 게 없다고 하시면서 토닥여주고 가셨다. 그리고 튜터님이 만들어주신 코드는 먼 길 돌아가려고 했던 내가 생각한 복잡한 코드와는 달리 간결하고 클린한 코드였다ㅠㅠ... 간단하게 생각하는 법을 잘 모르는 나는 갈 길이 무한 스크롤 같다.
오늘은 우리 조 프론트 분에게 리덕스 사용법에 대해 설명해 드렸다. 나도 기본적인 개념은 잘 모르지만, 그래도 데이터가 어떤 방향으로 흐르는지는 알게 되어서 그 덕분에 지금까지 리덕스를 그럭저럭 사용해 왔던 것 같다. 그 방법을 간단하게나마 자료로 만들어 공유해 드렸다. 리덕스가 까다로운 건 분명하지만 부디 너무 어려워하지 않으셨으면 좋겠다. (하지만 나도 어렵지 야호)
지금까지의 수정사항을 모두 반영해서, 며칠간 미루고 미루던 재배포를 했다. 한층 더 완성도가 높아져서 뿌듯하다. ╰(*°▽°*)╯
내일 할 일
자잘한 메뉴들은 우리 팀의 노션 페이지와 연결한다. 하지만 노션 페이지에 개인정보가 있으므로 그 부분은 삭제하거나 다른 페이지를 새로 파야 할 것 같다.
footer에 hover 시 애니메이션을 준다. 이건 완전히 추가적인 기능이지만, 시도해보자.
처음에는 숨겨져 있다가 스크롤을 내리면 나오는 프로그레스 바에 상세 페이지 뉴스 제목을 붙인다. 오늘 프론트 분과 같이 여러 차례 도전해봤지만 허탈하게 실패하고 말았다.
검색창을 띄우는 버튼을 누르면 검색창으로 페이지 이동이 완전하게 이루어져야 하는데, 자꾸만 검색창이 페이지 가운데에 뜨고 양 옆 부분으로는 다른 컴포넌트가 보이는 기현상이 일어났다. z-index 문제인가 싶어서 검색창을 0까지 내려보기도 했는데 , 그런 식으로 해결되는 문제는 아니었다. 왜냐하면 두 컴포넌트의 url이 겹쳤기 때문이었다...^^ 아무리 관련 있는 컴포넌트라지만 url 분기를 제대로 안 하다니, 순식간에 해결되는 걸 보고 허무와 충격을 동시에 느꼈다.
카테고리 이름을 클릭하면 카테고리별로 뉴스 목록이 나타나는 페이지에서는 카테고리가 달라질 때마다 브라우저 주소창 위 타이틀이 달라져야 했다. 구글링 해서 react-helmet 을 설치하니 컴포넌트별로 메타 태그에도 손을 댈 수 있었다. 사용법도 간단했다. 앞으로도 애용할 것 같다.
사용자가 이메일 주소와 닉네임을 입력하면 해당 데이터를 서버로 넘겨서, 서버에서 메일을 발송하기로 했다. axios를 적용해 작업을 완료했다.
검색창에서 검색어를 입력하면 주소창에 검색어를 들어가게 한 후, 곧바로 검색 결과 페이지로 이동시킨 다음 거기서 그 주소창의 검색어를 다시 따서 서버에 보내 관련 뉴스 목록을 받아오는 axios 코드를 다른 프론트 분과 함께 짰다. 버튼을 클릭하면 최신순과 관련순으로도 받아올 수 있도록 했다.
배포해도 수정은 가능하니 일단 배포를 했다. 백엔드 분들도 데이터가 어떻게 펼쳐지는지를 보고 싶으실 텐데 지금까지 프론트에서 공유해주는 화면만 보셨으니 답답하셨을 것 같다는 생각이 들었기 때문이다. 수고했다는 말을 들을 때마다 프론트가 들이는 시간이 상대적으로 많다는 이유로 항상 공이 프론트에게 많이 돌아가게 되는 것 같아 민망스럽다. 협업해서 함께 만든 건데. 언제나 한결같이 배려해주시는 백엔드 분들 덕분에 수월하게 마무리 되어 가는 중이다.
내일 할 일
다른 프론트 분이 로딩 스피너를 달아주셨는데, 스피너 자체가 조금 늦게 뜨거나 해당 컴포넌트에 데이터를 불러오지 않은 모습을 한번 띄운 후 뜨는 미운 모습을 보여서 다시 함께 방법을 연구해보기로 했다.
카테고리 메뉴는 클릭하면 그 밑에 언더라인이 뜨는데 다른 페이지로 이동하기 전까지는 그게 유지된다. 하지만 내가 구현한 걸로는 마우스 클릭이 유지되는 상태에서만 언더라인이 잠깐 뜨고 사라진다. 이 부분 해결이 필요하다.
footer에 마우스를 올리면 글자가 옆으로 흐르는 애니메이션이 적용되어 있다. 구현해보도록 한다.
상세 페이지에서는 프로그레스바가 뜨는데, 스크롤 막대의 위치에 따라 최상단에서는 보이지 않다가 어느 지점에 이르면 나타난다. 이것도 연구하기.
상세 페이지 뉴스 제목 위 카테고리를 클릭하면 해당 카테고리의 뉴스 목록 페이지로 이동하게 한다. 어려울 것 같진 않다.