fpzmfks 님의 블로그

오늘은 시청중/모집중 필터 구현과 필터와 검색 기능을 헤더로 옮기는 작업을 하였다.  페이지네이션과 데이터 요청필터나 정렬, 검색, 페이지네이션 같은 기능들은 하나하나 놓고 본다면 별 것 아니지만, 이번 프로젝트와 같이 데이터베이스 구조가 복잡할 때에는 이런 기능들을 합치는 것이 가장 큰 이슈 중 하나인 것 같다.  이전의 정렬, 필터, 검색 기능들도 supabase 메서드에 대해 조사하고 잘 활용해야만 페이지네이션과 결합할 수 있었는데 데이터 요청/응답 이슈로 인해 이번에 기어코 시청중/모집중 필터 기능을 구현하는 데에 실패했다. 정확히는 필터 기능 구현 자체는 쉽게 성공했으나 이를 페이지네이션과 결합하는 것이 불가능했다. 이 글의 가장 하단에 노력했지만 실패한 코드가 남아있다.  문제의 핵심은 '시청..

오늘은 어제 붙잡고 있던 것들을 마무리 했고, 내일 남은 헤더 기능만 구현하면 나의 기능 구현은 끝이 난다. 페이지 2개를 구현하려니 너무 힘이 드는데, 그래도 그 어느 때보다도 배우는 게 많았다는 점이 위안이 된다.  먼저 메인 페이지 기능들을 짚어보자면정렬 / 필터정렬은 supabase order를 통해, 필터는 supabase textSearch를 통해 구현했다.  이 중 정렬의 인기순 기능은 어제 붙잡고 한참을 고민하던 것이었다. 문제의 원인은 인기순 정렬을 위한 count값이 배열로 들어오는 것을 곧장 order로 정렬할 수 없었기 때문에 sql editer를 사용해야 했다는 것이다. 하지만 sql에서 사용되는 언어는 내가 모르는 영역이기 때문에 한정된 프로젝트 시간 내에 할 수 있을 지 장담할..

오늘은 메인 페이지 정렬/필터(페이지네이션 전제)과 모달 창 조정을 하면서 시간을 보냈다.  메인 페이지 정렬/필터먼저 메인 페이지 정렬/필터에 대해서 이야기하자면, 페이지네이션과 정렬/필터 기능을 조합하기 위해서는 supabase에 데이터를 요청할 때 정렬/필터가 되어야 한다. 우리 프로젝트의 경우 최신순/인기순 정렬과 채널 별 필터 기능을 가지고 있는데, 이러한 정렬/필터 기능을 구현하기 위해서 supabase에 다음과 같은 요청을 보냈다. const response: PostgrestSingleResponse = await browserClient .from('party_info') .select( 'party_id,party_name,party_detail..

오늘은 정말 많은 일이 있었다. 어제 이미지 업로드를 했고, 제목에 있는 나머지를 오늘 다 했다. 정말 머리가 터지는 줄 알았는데, 이전 작업들을 잘 기억해두고 있어서 이러한 수정 작업들이 그래도 순조롭게 이루어진 것 같다.  이미지 업로드먼저 이미지 업로드를 짚고 넘어가자면 간단하게 input 창 2개만 띄워놓았던 초대하기(이미지, 닉네임)를 파일 업로드 방식으로 바꾸는 작업이었다. 이건 마이페이지 편집하기 기능을 작업하신 분이 이미 해놓은 코드가 있어서 그 코드를 분석해서 변형하는 과정을 통해 구현할 수 있었다.  그 분과 내 코드에서 다른 점이 있다면, 그 분은 기존의 데이터를 수정(update)하는 과정에서 이미지를 업로드하고, 나는 새 파티 프로필을 등록(insert)하는 과정에서 이미지를 업로..

오늘은 어제보다 더 정신없는 하루를 보냈다. 핵심이 되는 party_info 테이블을 삽입하는 로직이 어느 정도 완성되었기 때문에 이 데이터를 기반으로 여태껏 만들어둔 로직을 테스트하려니, supabase 세팅 관련으로 문제가 있다는 것을 깨달았다.  문제라고 해도 어떤 오류가 있었던 것은 아니고, 서버 컴포넌트와 클라이언트 컴포넌트에서 사용하는 supabase 세팅이 다르다는 것을 기존에 고려하지 못했던 것이었다. 이 점을 고려한다면 서버 컴포넌트와 클라이언트 컴포넌트에서 다 사용되는 로직들은 각각의 세팅을 기준으로 1개씩, 총 2개를 작성해야한다.  이렇게 서버 컴포넌트와 클라이언트 컴포넌트에서 모두 사용되는 로직으로는 대표적으로 getLoginUserId함수가 있고 이 함수를 총 2개 만들어서 공유..

오늘은 하루종일 기능 구현에 매달렸다. 오늘 구현한 기능은 재생 바와 파티 상태 처리 기능인데, 후자는 제대로 테스트를 할 수 없으니 당장에는 간단하게 넘어갔으나, 전자는 생각보다 까다로워서 시간을 많이 잡아먹었다.  어려웠던 것재생 바를 구현하는 데에 생각할 점은 현재시각을 불러온다고 해도 자정00:00을 넘으면 현재 시각이 초기화된다는 것이다. 때문에 나는 오전 8시를 기준으로 삼아서 if(현재시간이 오전 8시 이전이고 && 시작시간이 오전 8시 이전이 아닌 경우)에 현재 시각에 24시간을 더하기로 했다.  아래가 현재시각을 반환하는 함수이다. const getPlayTime = (startPlayTime: number) => { // 현재 시각 const nowTimeArr = [new Date..

오늘은 본격적으로 프로젝트를 진행하기 시작하며 프로젝트를 세팅하고, 각자 우선순위가 높은 순으로 기능을 구현하기 시작했고, 기능을 구현하기 시작하면서 눈에 들어온 ERD의 미흡한 부분을 수정하였다.  아래는 회의록인데 대부분 ERD 수정사항이다.  회의록team_user_profile과 party_info의 외래키 관계 수정ERD에서 필수적인 데이터(party_id) 누락 수정영상 id와 영상 종류가 있어야 데이터를 불러올 수 있으니까 party_info에 영상id와 영상 종류 열을 추가하면 좋을 것 같다type오류 때문에 날짜와 시간을 따로 관리하는 게 더 편할 것 같아서 날짜와 시간을 따로 관리하기로 하였다..prettierrc가 잘 안되었는데 아래 부분을 지우니까 잘 되었다."plugins": ["..

오늘은 와이어프레임을 구성하면서 프로젝트 구조를 약간 개선하고 그에 따라 역할 재분배를 했다. 또한 어제 작성한 ERD를 튜터님께 확인받으면서 ERD 구조도 조금 변화시켰다.  아래는 와이어프레임을 작성하면서 논의한 내용을 기록한 회의록으로 프로젝트 구조를 개선한 내역이라고 봐도 될 것 같다. 중요한 것은 두 가지로 상세페이지를 없애고 파티페이지만 운영과 파티정보 테이블 2개를 하나로 합침이다.  회의록팔로우 후 이웃에 대한 정보를 어떻게 제공할지 생각해보면 좋을것 같다 ex) 어떤 영상을 같이 봤는지최초 로그인 시 프로필 정보를 입력할 수 있도록 ERD 구성이때 선호 장르, 이용 플랫폼, 닉네임 작성기능이 비슷한 페이지 두 개를 하나로 합침상세페이지를 없애고 파티페이지만 운영초대하기 기능을 초대장 방식..

오늘은 다들 만족하는 기획 주제를 확정할 수 있었다. 원래 일요일에 모여서 기획 주제를 확정해보려고 했는데 마땅한 의견이 안 나와서 오늘 다시 회의를 해보고 최종 결정하게 되었다.  우리 팀의 기획은 이전에 '팀을 모아서 사이드 프로젝트를 제작하는 사이트'에서 '팀을 모아서 영상을 시청하고 그에 관한 채팅을 하는 사이트'로 최종확정하였다. 이전 기획에서 변형을 더한 기획인 만큼 페이지별로 프로젝트 구조를 잡고 기능들을 나누는 것에 그리 오래 걸리지는 않았다. 아래가 MVP(Minimum Viable Product) 를 개발하기 위해 필수 기능을 정리하고 우선순위를 나누어 역할까지 대충 정한 리스트이다. 나는 상세페이지를 맡았는데 쉬운 부분이라 내 파트를 끝내고 나서 다른 팀원들이 도움을 필요로 하지 않는..

오늘은 어제 생각한 아이디어를 바탕으로 주제를 정하고, 레퍼런스를 분석한 뒤, 페이지별 기능과 MVP를 작성하고, 유저 플로우 또한 작성해 보았다.  이러한 내용들을 피그마를 통해서 작성했는데, 하루만에 이만큼 많이 진행이 되어서 뿌듯했다. 하지만 막판에 판이 뒤집히고 말았는데...  우리가 진행하려고 한 프로젝트의 주제는 '사이드 프로젝트 팀 모으기 사이트'이다. 팀 단위의 사이드 프로젝트를 진행하기 위해서 팀을 모으려고 할 때 도움을 줄 수 있는 사이트로, 이러한 목적성 아래에 생각할 수 있는 기능이 많아서 좋다고 생각한 아이디어였다. 하지만 튜터님의 따끔한 말씀에 따르면 첫째, 팀원 4명이 진행하기에는 필수적인 기능이 너무 많다.둘째, 실용성이 떨어진다. 개발자들이 이러한 사이트를 통해 팀원을 모으..