지금 와서 되돌아보면 기억이 희미해졌다. 그땐 분명 이런저런 생각들이 많이 들었던 것 같은데. 그저 그것도 한때의 감정이었을까. 프로젝트가 끝난지 어연 2달이 지나 당시 팀원들 얼굴도 조끔씩 희미해지는 느낌이다. 최고의 팀을 만나서 좋았다고 서로 칭찬하고 해산한것이 어제같기도 하지만.. 마치 군대 훈련소에서 동기들끼리 자대로 배치받아 떠나기 전에 건내는 인사같은 느낌? 전부같았던 그때가 지금 되돌아보면 또 그렇지만도 않은 것 같다. 지금은 혼자 지내는것에 다시 익숙해진 느낌이다. 팀플레이 그럼에도 다시 생각해보면, 나 자신에게 크게 부끄럼없이 최선을 다했던 것 같다. 어쩌면 이렇게 최선을 다했던 것은 나와 함께 팀을 이루어 프로젝트를 진행하는 동기들에게 적어도 나때문에 발목잡히는 일을 만들고 싶지 않았었..
이제 실제로 숙소 데이터에 필터를 적용해야겠다 앞서서 가격범위, 숙소유형 등 우리가 검색을 할 때 필요한 필터링한 부분을 state 에 저장하는 부분까지 다뤄보았다. 이제 우리가 어떠한 체크박스나 가격 범위등을 설정하면, 그에 따른 설정 값들이 useState 에 의해 저장되어있다. 뭐 침대는 몇개여야 하고, 침실은 몇개에, 개인실이어야 하며 최대 10만 미만인 등등.... 사실 원래 같았음, 이러한 조건들을 한데 모아서 최종적으로 검색 버튼을 클릭할 시 navigate 를 활용하여 URL 을 변경해주고, 메인페이지에서 변경된 URL 을 통해 백엔드 API 에 요청을 하게 되면 된다. 그러니깐 원래 계획은 그냥 사용자가 어떻게 필터를 하던 마지막에 가서 최종적으로 검색을 눌렀을 때의 필터값들을 전송하려고..
앞서서 가격 범위를 결정하는 부분에 대해서 살펴보았고, 이제 나머지 유형들을 필터하는 과정을 살펴보자. 숙소 유형 숙소 요형은 총 3가지로 나뉘게 된다. 전체를 아우르는 집 전체와 개인실, 다인실로 구현하였다. 다만 어떠한 숙소는 개인실로도 사용이 가능할 것이고 다인실로도 사용이 가능하게 된다. 따라서 중복 체크가 될 수 있도록 해야하고, 필터링 결과는 체크된 조건들을 모두 포함하는 숙소를 나타내야 할 것이다. 기존 에어비엔비 사이트의 필터창과 동일하게, 그리고 가장 직관적인 표현방법은 역시나 체크박스를 이용하는것이다. 체크박스는 실제로 로서 구현할 수 있었지만, 위에서 metarial UI 를 활용하였으니 이번에도 같은 라이브러리를 사용해보기로 하였다. 연습할겸 편리하기도 하니 사용하는 게 좋을것이라 ..
매번 다시 리뷰한다고 하면서도 안하고 있는 내모습... 2차 프로젝트에서는 1차와 달리 전체적인 컴포넌트들의 연결들을 담당했던 것을 제외하자면(라우팅 등) 크게 Nav 부분과 더불어 검색 부분의 Filter 를 담당했었다. 사실 원래는 검색 상세페이지를 담당하는 쪽으로 가고있었다가, filter 부분을 담당할 사람이 딱히 정해지지 않아서, 검색과도 연관이 깊은 부분이니 조원들에게 같이 담당을 하겠다고 얘기를 했었다. 스프린트 계획대로라면, filter 를 마무리하고 마지막으로 예약페이지 혹은 마이페이지를 작성하려고 하였으나, 2주라는 프로젝트 시간관계상 벅찬것도 사실이었고, 무엇보다도 나 자신이 생각했던 것보다 Filter 컴포넌트를 구현하는 데 애를 먹었던 기억이 난다. 당시에 뭔가 정리도 잘 안되는것..
그래서 난 무엇을 하고 싶은거지? 12개월 전, 퇴사를 하기 전 항상 물어보는 질문이었다. 호기롭게 이전 직장에서 뛰쳐나와 내 생각을 자유롭게 표현하는 직업을 찾고자 하였다. 겁이 많은 성격에 회사를 나오기 전에 무엇이라도 준비를 해야하지 않을까 인터넷과 서적을 뒤지고 찾아본저 어연 3개월이 넘어갔음에도, 마땅한 직업군을 찾지 못하고 있을 때 개발자라는 익숙하면서도 들려지는 소리가 많은 직업이 내 눈앞에도 아른거리기 시작했었다. 의식적으로 회피하고 있었던 직업이었다. 흥미와 직업은 다르며, 지금 내가 개발자로서 걸어가고자 선택하는것은 과연 나 스스로의 판단인가? 아니면 타고 들어온 외부의 판단일까? 답을 내릴 수 없었다. 그렇기에 어쩌면 앞으로 살아가고 싶은 방향을 제시해줄 수 있는 가능성이 큰 직업이었..
이제 하위 컴포넌트들을 관리하는 최상위 컴포넌트 Nav 를 정리해보자. 처음 Nav 를 설계할 때, 생각 이상으로 상위에서 props 로 전달해주어야 할 변수 및 함수가 많을 것이라 예상되었다. 그도 그럴 것이 실시간으로 조건에 맞는 Nav 를 랜더링 해야하며, 그 각각의 Nav에 대해 따른 모달 컴포넌트도 정상적으로 랜더링 되어야 하기 때문이며 또한 사용자가 편리하게 사용할 수 있도록 신경써야 하였기에 Nav 가 유기적으로 움직이기 위해 좀 더 체계적으로 설계했어야 했다. 이로 인해 Nav 의 코드는 직관적이지 않게 코드가 짜여졌다. import React, { useState, useRef, useEffect } from 'react'; import LoginModal from '../Modal/Lo..
갑작스럽게 일들이 많아져서 작성이 좀 늦어졌다. 조금만 시간이 지나도 다시 가물가물해지는게 내 기억력의 한계인가 싶기도 하고, 원래 다 이런건가 스스로에게 위안을 삼아본다. 검색바를 클릭함에 따라 2가지의 형태로 나뉘게 되는 Nav 이전 글에서 이미 확인을 하셨겠지만, 다시 사진을 참조하자면 아래와 같다. 원래 에어비엔비 사이트가 어떤식으로 Nav 가 형성되어있는지 까지는 모르겠다. 에어비엔비 사이트에서는 마치 검색창을 클릭할 시 가운데 검색바가 확대되면서 밑 Nav 처럼 변하는 식으로 되었는데, 시간도 부족하고 아직 방법을 잘 모르겠어서 나의 경우는 opacity 의 변화로 부드럽게 전환되도록 표현하였다. 파일은 2가지로 컴포넌트를 나누어 놨는데, 상위 Nav 컴포넌트에서 조건부 랜더링을 하지 않고, ..
학원에서 기업 협업을 통해 현업의 환경을 체험할 수 있도록 기회를 제공해주었다. 무엇인가를 배우러 가는 입장이기 때문에, 기대감도 들고 어떤 기술을 사용하고 있을지도 궁금하였는데, 처음으로 마주한 협업툴은 아틀라시안 사의 협업 툴 JIRA 였다. 지금도 '에자일' 하게 일을 한다는 것에 대해서 잘 체감은 못하고 있지만, 간략하게나마 trello 를 활용해보면서 주차 스프린트 단위로 칸반 보드를 활용하여서 각자가 해야할 업무에 관하여 능동적으로 관리하여, 각자가 하는 업무를 관리자가 쉽게 파악할 수 있었던 기억이 있다. 나는 현재 어떠한 업무를 어떻게 진행중이고, 다른 조원은 어떠한 업무를 현재 어떤 단계에 있는지 알 수 있어서 매번 미팅을 통해서 각자 진행사항이 어떻게 되는지 질문할 필요없이 효율적으로 ..
