pages 디렉토리 속
api : 백엔드 역할
그 밖 _app.tsx, _document.tsx, index.tsx : 프론트 엔드 역할
Nested 라우팅을 구현해놓은 것이고 pages/todo/add 를 통해 자동 라우팅이 됨
객체지향을 하는 이유
재사용성과 확장성이 중요한 코드를 짜야함
lib속에 api와 data 디렉토리는 모듈화를 위해 만든 것들 (axios 통신)
data 디렉토리는 fs를 통해 json으로 갖고 오니까, 원래는 데이터베이스 같은 서비스를 활용해야함
여기서 사용한 css in js는 당연히 좋은 방법이 아님
html, css, js의 역할이 있고 html, css를 합쳐도 js보다 무겁지 않을텐데
js에 괜한 무게를 더욱 실은 것 같은 느낌
Tailwind CSS - 디자이너들이 만든 CSS를 갖다 쓸 때 많이 씀
SASS, SCSS
module CSS - 자기가 만들어서 쓸 때
컴포넌트 분할
컴포넌트 분할에 대해서 이야기 하자면 원래는 UI적으로나 기능적으로 컴포넌트를 나누는 게 좋음
하지만 이 프로젝트에서는 한번에 껴있어서 불필요한 렌더링이 많이 발생
ReactQuery는 서버 상태나 앱의 관리를 하고
앱의 관리는 ContextAPI (부분전역), Redux (완전전역)으로 상태를 관리
MCV
Model - 데이터 | Controll - 데이터 변경 | View - Html, React
React는 Flux pattern (단 방향통신)을 사용함
그렇기에 state로 관리하다가 모아서 Back에 쏴주는 방식
Redux-ReduxSaga는 비동기 데이터, 모듈화르 하는 라이브러리가 존재
이를 통해서 상태관리를 한 다음에 axios (비동기)를 통해 통신
Component는 그저 UI, State만을 관리
컴포넌트를 나누는 기준도 UI관리적인지, State관리적인지 나눌 수 있음
test코드와 TDD
요즘은 test 코드를 작성할 줄 알아야함 (TDD랑 test코드는 살짝 느낌이 다름)
intergrate test, unit test등이 test code - 개발자의 테스트 방법
- 테스트 코드를 만들고 컴포넌트를 짜기 (선 실험 후 개발) - 이것을 TDD라고함
- 컴포넌트를 먼저 짜고 테스트 코드를 짬 (기존 test방법)
Web assembly
기존 3대장 (html, css, js)를 가지고 웹을 그리는 것이 아닌
C, C++, java 같은 언어들로 웹을 만드는 것
개인적으로는 장기적으로 봤을 때 갈아탈 시대가 올 것 같다고 생각함
