- 해당 프로젝트는 개발에 사용되는 api를 좀 더 raw하게 볼 목적으로 제작됐다.
- 그동안 우선순위에 밀려 오랫동안 방치되었다고 들었다.
스벨트 공부
- 프로젝트는 스벨트로 만들어졌다. 스벨트는 한 번도 다뤄보지 않았기 때문에 해당 프로젝트를 하려면 스벨트를 공부해야 했다.
- 리액트 말고 본격적으로 알아보려고 한 건 처음이라 아주 신났다.
- 스벨트를 공부하면서 스벨트의 렌더링 원리, 양방향 바인딩, 철학, 스벨트 문법 등 재밌는 걸 많이 알았다.
- 스벨트는 커뮤니티가 작아서 공식 문서가 오히려 정확하고 많은 정보를 알려줘서 공식 문서 튜토리얼을 하나씩 봤는데… 너무 지루해서 유튜브 4시간 짜리 영상(꿀잼) 찾아보고, 예시도 찾아보고, 스벨트 카톡옵챗도 들어가서 이해안되는 거 이것저것 물어봤다.
- 근데 결국 실제 프로젝트를 리팩터링하면서 공식문서 다봤다.
고쳐보자!
- 현재 프로젝트의 문제점을 요약하자면 다음과 같다.
- url이 쿼리스트링 없이 모두
/로 구분되어 있었다.
- 그래서 어떤 페이지가 있는지 한 눈에 보기 어렵고 이렇게 많은 주소들이 어디에서 보여지는 건지 한참을 봐야 했다.
- 디렉터리 구조의 규칙이 복잡하다.
- 보통 page안에 보여질 페이지를 정의한다고 생각했는데 page, detailpage, component에 있지만 페이지인..? 것들이 있어 이해하기 어려웠다. 추후 sveltekit이나 next js로 이전할 걸 고려하면 많이 쓰이는 패턴으로 바꿔야 겠다 생각했다.
- 컴포넌트 분리가 되어있지 않았다.
- 가뜩이나 svelte는 switch문이나 삼항 연산자 등이 지원되지 않아 if, else 문으로 처리해놓은 것들이 많아 코드가 읽기 어려운데 컴포넌트라도 분리해야 볼 수 있을거라 생각했다.
- 이 외에도 tsconfig나 alias 경로, prettierrc, npm과 yarn의 혼재 등 깨지는 것들이 많아 환경 설정부터 시작해야 했다.
결과
- 목표는 앞서 말한 디스코의 문제점을 수정하면서 기존과 동작이 똑같아야 한다는 거였다.
routes.ts
- 소..속이 너무 시원했다.
- url이 많았던 이유는 음원 페이지다보니 필터링을 하는 경우가 많은데 필터됐을 때 모든 경우들을 url로 만들거나 사이드바를 url로 동작시켰기 때문이다.
- 고치고 보니 정작 필요한 페이지는 5 ~ 6개밖에 되지 않았다.