API는 기존에 PC버전에서 사용하던 걸 사용한다고해서 금방 구현할 수 있을 줄 알았는데, 개발에 생각보다 시간이 오래걸린다.
원인을 곰곰히 생각해봤다.
내가 결정장애가 너무 심하다.
일단 리액트는 자유도가 너무 높아서, 나같이 결정장애가있는 사람들은 쉽게 결정짓고 개발에 속도를 내기가 힘든 것 같다.
무작정 개발하지말고 나만의 규칙을 어느정도 세워놓고 개발을 진행하자.
린트가 너무 빡세다.
퇴사하신분이 잡아주신 보일러플레이트위에서 개발을 진행하고있는데, 린트가 굉장히 엄격하다.
주석의 띄어쓰기까지 린트를 잡고있다.
처음엔 모든 린트를 수정하느라 너무 고생했다. 지금도 고생은하고있지만 많이 좋아졌다.
나중에 구조를 잡는다면 린트는 어느정도 융통성있게 정해야겠다.
구조가 단순하지 않았다.
PC버전의 프론트를 메뉴별로 여러팀에서 개발했기도하고, 구조자체가 프론트와 백엔드가 명확히 구분되어있지않고 하나의 spring 애플리케이션이 API서버와 SSR서버를 겸임하고있어 어떤 API를 사용하는지 확인하기위해 컨트롤러를 매번 까보면서 파악하고있다.
그래도 전에 스프링부트를 어느정도 공부해둔게 도움이 되고있어 다행이라고 생각한다.
Viewport
layout viewport
(<= document)
브라우저가 렌더링한 영역을 의미
visual viewport
(<= window inner)
사용자에게 실제로 보여지는 영역을 의미
css 에서 사용하는 vw, vh의 viewport는 visual viewport를 의미한다.
컴포넌트 분리 규칙
매번 개발할떄마다 헷갈린다.
재사용이 안되는, 단순 레이아웃단순화를 위해 분리하는 컴포넌트는 하나의 파일에 export 없이 정하자.
render 함수는 조건부 렌더링, 반복렌더링을 위한 경우에만 빼도록 하자
재사용되는 컴포넌트는 별도의 컴포넌트파일로 분리하자.
UI표현로직과 비지니스로직의 분리
React의 경우 Redux hook이 나오기 전에는 기존에 비지니스로직과 UI표현로직을 Container Component와 Presentational Component 로 분리했었다.
하지만 Redux Hook이 나오면서 굳이 분리해야할 필요가 사라졌다.
나는 Container & Presentational Component를 나누는게 꼭 Redux를 사용하기 위함이라기보다 유지보수를 위한 디자인패턴으로 생각하고있었다.
그래서 "Redux Hook이 나왔기때문에 이제 container를 따로 나눌필요가 없습니다!"라는 이야기를 할때마다 "왜 나눌필요가 없을까..?"라는 생각을 하곤했다.
Connect 를 안쓴다고하더라도 나누면 유지보수상에 도움이 될테니말이다.
찾아보니, 나누는게 유지보수의 도움이 되는 것 맞으나, 나누는 기준이 컴포넌트가 될 필요가 없다는 이야기였다.
최근에는 UI표현/동작로직은 컴포넌트에 정의하고, 상태값을 관리하는 비지니스로직은 custom hook으로 분리하여 가져다 사용하는 방식을 쓴다고한다. 리팩토링 기간에 수정해야겠다.
이부분은 별도의 포스팅으로 정리해야겠다.
참고 - https://velog.io/@velopert/using-redux-in-2021
