폴더구조를 바꿔야 하는 이유? 위를 보면 알 수 있듯, 우리 프로젝트의 폴더구조는 굉장히 복잡하다. 컴포넌트 폴더 안에 따로 구분 없이 기능이 적혀있는 폴더들이 가득하기 때문에 구조를 처음 보는 사람은 절대 이해하기 어려울 것이다 (우리도 네이밍 때문에 헷갈리곤 했다). 그래서 어떻게? 팀원들끼리 상의한 결과 DDD (Domain-Driven Design) 설계 방식을 따라가면 좋지 않을까? 결론이 나왔고 '각자 폴더구조를 정리해 오자!'라고 얘기했지만 셋 모두 비효율적이라 느꼈기에 다시금 상의를 진행하였다. 이미 우리의 폴더구조는 어느 정도 페이지별로 구분이 되어있었기 때문에 여기에 맞게 작업을 진행하기로 했다. 이해하기 어렵거나 비슷한 네이밍을 가진 파일, 폴더의 이름을 변경하였고, layout의 기..
목표 이 프로젝트에 관해서 아무것도 모르는 사람이 읽고서 이해하기 쉬운가 새로운 기능을 추가하거나 기존 기능을 제거하기 쉬운가 중복되는 코드를 최소화했는가 적절한 네이밍을 부여했는가 리팩토링 순서 폴더구조 정리 ➡️ 재사용 가능한 컴포넌트 분리 ➡️ 네이밍 ➡️ 인터페이스 정의 ➡️ 테스트코드 도입 매주 월요일 저녁 8시까지 스프린트 방식으로 메인 프로젝트 리팩토링을 하기로 했다. 멘토님에게 지적받은 부분과 우리가 생각하는 보완할 점을 개선하기 위함이다. path alias를 설정, eslint를 일부 추가하였다. 폴더의 depth 가 깊어질수록 경로가 복잡해지기 때문에 path alias를 사용하여, 프로젝트 파일들을 상대경로(../../)에서 절대경로로 전부 변경해 주었다. /** tsconfig.j..
배포 주소 https://joying.vercel.app/ JOYING 세상의 모든 컨텐츠를 한 곳에 보여조잉! joying.vercel.app 깃허브 주소 https://github.com/codestates-seb/seb44_main_003 GitHub - codestates-seb/seb44_main_003: JOYING: 세상의 모든 OTT 컨텐츠를 한 곳에 보여조잉! JOYING: 세상의 모든 OTT 컨텐츠를 한 곳에 보여조잉! Contribute to codestates-seb/seb44_main_003 development by creating an account on GitHub. github.com 프로젝트 회고 개발 기간: 2023.06.28 ~ 2023.07.24 코드스테이츠 프론트엔..
Pre 프로젝트 Day2~3 구현 & 에러 팀원분들과 회의하면서 사용자 요구사항 정의서, API 명세서, 레이아웃, 깃 플로우 방식 등등을 결정했다. 몇몇은 진행하면서 원활한 의사소통을 통해 개선해 나갈 거 같다. 일정에 따라 테스트도 진행하기로 했고, 쭉 그랬듯 앞으로도 엄청 바쁠 거 같다. 레포에는 BE 팀장님과 내가 각각 초기 세팅을 진행하였다. client에 vite build, typescript, eslint, prettier... 상태관리 recoil, react querry... 폴더, 페이지 정리.. 등등.. FE 팀원분들과는 각자 페이지, 기능을 맡아서 작업하기로 했다. 해야 할 것 깃에 이슈, 마일스톤 작성, 무호흡 코딩 팀장, 팀원분들이 갈수록 적극적이어서 엄청 만족 중이다 >
Pre 프로젝트 Day1 부트캠프를 시작한 지 벌써 4개월이나 지났고, 저번주 금요일 pre 프로젝트 팀빌딩이 끝났다. (랜덤) 솔로 프로젝트, 스터디 팀 프로젝트가 끝나자마자 새로운 프로젝트가 시작되려고 한다..😶🌫️ 개인적으로 프로젝트를 진행해야 불타는 성향이라 떨리거나 한다기 보다는 기대되는 마음이 더 큰 것 같다. 나까지 포함해서 총 6명(FE3 + BE3)이 한 팀이 되었고, 팀원 모두 비 전공자에 팀 프로젝트 경험이 없다던 것 같다(아마도). 경험이 많은 분에게 배우기를 바라긴 했지만, 부팀장이 되어버린 내가 팀을 주도하면서 많은 걸 배울 수 있을 거라 생각하기에 만족하고 있다. BE 팀장님과 모든 팀원들이랑 열심히 해서 좋은 결과물을 만들 수 있게 노력해야겠다. pre-project 202..
게시판 프로젝트 Day16 구현 & 에러 db를 총 3개(컬렉션)를 썼는데 (post, comment, like) 3개를 하나하나 불러줘야 해서 로직이 쓸데없이 길어진 느낌이다. db하나에 많은 정보가 담긴 건 안 좋다고 들었는데 뭐가 좋은 건지 잘 모르겠다. 댓글 좋아요, 댓글 삭제를 구현하면서 db가 꼬여서 애좀 먹었다. 게시글 A의 댓글 1, 2 작성 후 댓글 1, 2 좋아요 후에 댓글, 게시글 삭제 시 db가 싹 다 지워지거나, 지워져야 하는데 남아있거나... 새벽 늦게 작업을 하는데 머리가 안 돌아가는 거 같아서 문제점을 주석으로 달아놓고 잤다. 몇 번 꼬이고 풀고 반복하다가 아침에 해결완료함 🤗 댓글 수정만 하면 되는데, 어떻게 해야 하지 생각해 보는데 컴포넌트의 위치나 구조를 좀 바꿔야 할 ..
CORS 정책이 필요한 이유 브라우저에서 기본적으로 API를 요청할 때, 브라우저의 현재 주소와 API의 주소의 도메인이 일치해야만 데이터를 접근할 수 있게 되어 있습니다. 만약 다른 도메인에서 API를 요청해서 사용할 수 있게 해주려면 CORS 설정이 필요합니다. CORS 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 출처 웹 콘텐츠의 출처(origin)는 접근할 때 사용하는 URL의 스킴(프로토콜), 호스트(도메인), 포트로 정의됩니다. 두 객체의 스킴, 호스트, 포트가 모두 일치하는 경우 같..
게시판 프로젝트 Day15 구현 & 에러 db 콜렉션 코멘트를 따로 만들어줬다. 코멘트는 부모게시글의 id, like, content, user, date를 갖고있다. like와 유사하게 코멘트 작성시 콜렉션 post의 comment 숫자를 증가 시킨다. 해야 할 것 코멘트의 좋아요 기능과 본인의 코멘트 수정, 삭제 기능. 마이페이지 ++