잠깐!

해당 포스팅은 프로젝트 진행사항을 보다 깊게 소통하기 위해 작성된 글입니다.

React code, 혹은 이론과는 무관하게 어떤 파트를 진행했고, 무슨 생각을 했는지, 그리고 어떻게 나아갈지에 대한 내용을 다룰 예정입니다.

이에 React 시리즈와는 다르게 코드보다 더 상위 계층의 개념인 플로우를 짜기 위한 소재가 될 글입니다.

또한, 팀원들과의 소통을 위한 글임에 따라 기존 글과는 다른 방식으로 진행됩니다.

서론

모두 아시다시피, 상당히 막막한 일주일이었습니다.

산 넘어 산이었고, 넘어야 할 봉우리가 정말 많습니다.

토요일 하루 푹 쉬시며 재충전의 시간을 보냈셨길 바라며, 월요일 발표 전 서로 생각을 공유할 수 있었으면 좋겠습니다.

시작하겠습니다.

Login / SignUp

아시다시피, Login / SignUp page는 상당히 간소화한 레이아웃과 기능을 작성했습니다.

코드나 레이아웃은 githib를 통해 받으셨으니, 넣지 않겠습니다.

저도 기존 필수 구현사항에 있는 페이지들은 레이아웃 또한 상당히 중요한 부분이라는 점 인지하고 있습니다.

main, menu, detail, login, signUp (필수 구현사항)

그러나 이전 소통에서도 다뤘던 얘기인데, 분명 디자인적 요소나 퍼블리싱 영역의 코드는 간소화하는 것이 기능 개발을 여유롭게 진행할 수 있는 부분이었다고 생각합니다.

하지만 현실적으로 돌아보면, 저는 디자인적 요소를 고려하느라 보낸 시간이 사실 짧다고 생각하지 않습니다.

그건 메인 페이지를 작성하는 저도 그렇고, 프론트엔드 팀원 모두가 마찬가지였습니다.

그럼에도 비교적 여유로운 마음가짐을 가질 수 있게 했던 이유는 제 생각에 이번 프로젝트에서 login과 signUp component가 비교적 높은 난이도가 아니었다는 점입니다.

예정사항 (진행사항 생략)

해당 페이지를 작성하며 가장 난관이 있었던 점은 분명 공용 컴포넌트 분리였습니다.

그래도 공용 component 분리 또한 빠르게 작성하고, suggestion을 반영했습니다.

수요일 쯤 두 페이지가 완성된 것 같은데, 이후로는 전혀 손을 대지 않았습니다.

그러나 commonForm, commonInput component는 여전히 수정할 사항이 많고, 앞으로 여유가 있다면 자잘한 fix가 이루어질 예정입니다.

1. commonForm, commonInput 에서의 style 적용 방법

2. 공용 컴포넌트의 개념에 맞는 props 추가 및 삭제

등이 이루어질 예정입니다.

진행하는 과정에서 비교적 빠른 속도를 내야 한다는 마음가짐이었습니다.

첫 스프린트에서 무조건 완성을 해야 하는 항목이었다는 것은 사전에 충분히 논의된 것 같으니, 해당 페이지들은 짧게 넘어가겠습니다.

다만, 두 페이지에서 어떻게 컴포넌트를 분리했는지, 왜 그래야 했는지 함께 이야기를 나눠볼 시간이 있다면 몇 번이고 꼭 했으면 좋겠습니다.

그 이후에는 프론트 두 분 모두 children, props 의 차이를 더 명확하게 알 수 있으실거라 생각합니다.

추후 2차 프로젝트에 있어 해당 개념을 미리 인지한다면 설계에 있어 다른 관점으로 접근하는 것이 수월하지 않을까 생각합니다.

페이지를 보고 미리 분리할 컴포넌트를 생각해볼 시간을 갖는 것은 실제로 상당히 도움이 되었기에 적어봅니다.

focus

두 페이지를 구성하며 초점을 맞춘 것은 어디까지고 복습입니다.

저는 아시다시피, 복습하는 것을 더 좋아하며, Refactoring에 있어 상당히 진심인 스타일입니다.

단, 개념에 초점을 맞추는 것이지 현재 수준에 있어 코드가 어쩌고 이런 생각은 하지 않기로 했습니다.

요약하자면,

1. state의 위치 & 관리해야 할 데이터

2. props로 전달받아야 할 데이터

3. children과 props의 명확한 차이

4. prevState를 사용하는 이유

네가지 지식을 중점적으로 다뤘습니다.

문법적 요소는 차차 사용할 일이 있으시면 말씀드리겠습니다. (... 등)

Main - imageSlider

대망의 index 페이지입니다.

목요일, 금요일, 그리고 오늘까지도 imageSlider 로직이 완벽하지는 않습니다.

그래도 어디까지 진행했고, 어떤 생각인지 공유해보겠습니다.

진행사항

1. 이미지 좌, 우 이동 ✔️

2. 이미지(가장 처음, 가장 마지막) 변경에서 좌표 이동 구현 ✔️

3. CDU(), setTimeOut() ✔️

세 부분이 지난 금요일까지와는 다른 부분입니다.

다만, 아직까지 reset되는 시점에 대한 고민은 더 해야 할 것 같습니다.

그렇기에 오늘은 로직에 대한 고민을 조금 더 해봐야겠습니다.

레이아웃은 천천히 작성하기로 했고, branch를 컴포넌트 별로 나누기로 했습니다.

그래야 공용 컴포넌트로 작성할 부분을 미리 뺄 수 있기 때문입니다.

이에 어떤 의견이 있으신지는 월요일에 말씀해주시면 감사하겠습니다.

예정사항

1. imageSlider reset logic 손보기

2. review 요청 - imageSlider

3. recommend block layout & logic & fetch 문 작성 예정

1번은 최대한 빠르게 끝내서 review를 요청할 예정인데, 이는 detail page에서 carousel slider를 사용해야 하기 때문입니다.

따라서, 1, 2 번은 최우선 사항, 3번은 늦어도 화요일 오후에는 착수해야 하는 사항이 되겠습니다.

공용 컴포넌트인 imageSlider 작성에 온 마음을 바치도록 하겠습니다.

focus

main page의 중점이 되는 개념은 아무래도 백엔드 분들과의 연계입니다.

해당 페이지는 많은 요청과 데이터를 요구하는 페이지고, 사실 혼자서 다 해결할 수 없을지도 모르겠습니다.

현재는 백엔드 데이터를 연동해야 할 블럭을 작성하고 있지 않으나, 백엔드 분들의 템포에 맞춰 레이아웃을 포기하고 먼저 데이터부터 받아볼 수도 있겠습니다.

이는 유동적인 부분이므로, 다른 프론트 분들에게 실시간으로 상황을 공유하겠습니다.

CSV, ERD 를 참고해서 로직을 작성하고, mock data를 작성해볼 수도 있으나, 개발 속도에 따라 변경될 사항입니다.

만약 제가 더 늦게 개발하고 있다면 바로 연동해서 데이터를 받고, 받은 데이터를 기준으로 component를 작성해볼 수도 있겠습니다.

따라서 저는 무조건 mock data를 사용해야만 하는 것은 아니라고 생각합니다.

이 부분에 대해서는 화요일 쯤 멘토님들과 프론트 팀원분들 모두 의견을 공유하고자 합니다.

이번 페이지의 초점은 현재까지는

1. imageSlider Logic을 공용으로 작성하는 방법 이해

2. 공용 컴포넌트 이해

두 사항이 됩니다.

이후 recommend block에서의 lazy-loading에 대해서도 다뤄볼 수 있으면 좋겠다고 생각은 하고 있습니다.

마치며

전반적으로 딱딱한 글이 되었습니다.

기왕 딱딱한 글이 되었으니까 제 생각도 얘기해볼까 합니다.

꾸깃 여러분, 모두 힘든 일주일을 보냈음에도 서로 어려웠던 점을 다 알고 있지는 않은 것 같습니다.

그럼에도 우린 더 힘들지도 모를 일주일을 보내야 합니다.

선지님에게 처음부터 말씀드렸듯 우리의 목표는 포기하지 않는 것입니다.

공부가 덜 되었다고 생각하면 언제든 말씀하시고, 공부하시면 됩니다.

어쩌면 완성보다 더 값진 것은 무엇을 확실히 알아냈느냐일지도 모르니까요.

소통이 어려운 저도 있었고, 1인분 해야 하는데 라는 생각을 가지고 계시던 두 분도 있었습니다.

백엔드 분들은 화기애애한 분위기 언제나 감사하고 있습니다.

우린 아직 학생이고, 앞으로 일을 하다 보면 급한 마음에 소위 말하는 복붙을 수도 없이 해야 할 수 있습니다.

학생답게 확실하게 알고 넘어가야 할 것과 아닌 것을 잘 구분하셔서 공부하듯 천천히 여유롭게 진행하는게 저는 좋다고 생각합니다.

개인적으로 저는 우리 팀원 모두가 지금의 팀이 아닌 훗날 스스로에게 떳떳할 수 있는 일주일이 되었으면 좋겠습니다.

꾸깃, 언제나 화이팅입니다.

그래도 발표는 사다리인거 아시죠? 😅