FlowForge(GTDList) 01 - 04 일지 react-redux의 적용

 원래는 어제 로그인 페이지와 회원가입 페이지를 만들고자 했다. 근데 다른 사람들이 만든 좋은 코드를 보고, redux를 적용하는 예제를 보니까 내가 코드를 얼마나 잘못 짰는지가 보였고 아무래도 리팩토링을 해야 할 것 같다는 생각이 들었다. 물론 가능하다면 위에 있는 두 개의 페이지를 만들면서 진행할 예정이다.

 

 현재 소스파일 구조는 이렇다.

보면 지금 pages 아래에 모든 컴포넌트가 몰려 있는데 페이지 단위로 컴포넌트가 나뉘어 있다. 좋지 못한 방식으로 짜여진 구조라는 게 코드를 짜면서 조금씩이지만 느껴졌다. 거기서 redux를 보고 나니까 확실히 문제가 있는 구조라는 것을 알았다. 다시 쓰일 가능성이 있다면 데이터 주입을 담당하는 컨테이너, 뷰를 담당하는 컴포넌트를 분리해야 했다.

 리덕스를 제대로 학습하지 못한 상태로 그냥 생 state, prop만 가지고 앱을 만들면 이딴 사단이 일어난다. 진짜 callback 지옥이라는 말이 괜히 있는 말이 아닌 듯하다.

 

게다가 css가 styled 문법을 이용해서 쓰인 것, css emotion을 이용해서 인라인으로 쓰인 것, css 파일이 임포팅 된 게 섞여있기까지 하다. 

 

 일단 css부터 전부 styled로 통일하기로 했다. 스타일이 html과는 분리되어있으면서 파일로 분리되어 있는 건 아니라 나름 콤팩트하기 때문에 3가지 방식 중에서는 제일이라고 생각했다. 괜히 다른 사람들이 이 방식으로 쓴 게 아니구나 싶었다.

수정된 스타일들

다만 인라인으로 css를 쓰는 것은 예외적으로 쓸모가 있는 경우가 있었다. 동적으로 스타일을 적용하고 싶은 경우이다. action 하고 defered처럼 각각의 테마 색깔이 다른 경우는 따로 styled를 통해서 스타일을 만들어두고 render에서 각각의 스타일을 매핑해 준 경우가 있었다.

 

예외적인 경우

 

 스타일을 정리한 후에는 react-redux를 이용해서 store를 도입, 코드를 다시 깔끔하게 만드는 작업을 진행했는데, 이게 생각보다는 오래 걸렸다. 심지어 아직 전부 끝난 것도 아니다. 현재는 페이지가 렌더링이 되는 정도이고, 뭔가 눌러버리면 그때는 바로 에러가 뜨는 상황이다. 그래도, 이전보다 훨씬 코드가 유지보수하기 쉬워졌다는 느낌이 들었다.

 

리팩토링 이후 파일 구조

 

 나처럼 container와 component를 무조건 분리해서 둘 필요는 없다. 특히 component가 다시 쓰일 예정이 없다면. 그럼에도,

 

1. callback이나 필요한 state를 따로 지정할 수 있고, 열람할 수 있다. (container안의 js를 참고하면 이 컴포넌트가 뭐가 필요한지 바로 알 수 있다.)

 

2. 상위 컴포넌트에서도 확실히 뷰에 집중할 수 있게 된다. component 단위의 코드들은 주로 styled나 몇몇 중요한 메커니즘 만이 남아서 보기가 편해지고 깔끔해진다.

 

3. 이렇게 되어서 성능이 나빠지기는커녕 필요한 state만이 오고 가기 때문에 render 함수를 불러오는 횟수에 있어서는 오히려 최적화를 꾀할 수도 있다.

 

등이 있었다. 아직 3번은 체감 못했지만(책에는 그렇게 쓰여있었다.), 1~2번의 장점이 나에게는 너무 매력적이었다. props를 통해서 전달전달하는 것도 한계가 있고, 너무 코드가 뚱뚱해지는 기분이었다. 물론, 대가가 아예 없지는 않은데 store.js가 무진장 커지기는 했다.

vscode가 축소해준 store.js

근데 차라리 이런 못생김이 한곳에 집중이라도 되어있으면 다행이라서 그냥 받아들이기로 했다. 이 코드도 언젠간 리팩토링 할 수도 있을 테니까.

 

 다만 오늘로써 전부 리팩토링이 된 건 아니다! 01-03에는 일정이 있어서 아예 코딩을 하지도 못했기 때문에, 이렇게 개발 일지도 늦어지게 되었다. 마침 공동 프로젝트로써 할 일도 생겼기 때문에, 그걸 하러 가야겠다.

 

 다음에는 리펙토링을 끝마치고 원래 계획대로 새로운 페이지 2개를 신설할 것이다.