[React] TODO LIST

TODO LIST

깃허브 링크

개발기간: 04/05 ~ 04/16

실행화면

구현한 기능

• TODO 추가, 삭제, 수정
• TODO 드래그 앤 드롭
• Menu bar의 Log

리액트 첫 프로젝트

리액트를 계속 공부하면서 만든 첫 프로젝트이다. 프로젝트는 hook을 이용해서 함수형 프로그래밍으로 진행했다. 리액트를 처음하면서 좋았던 점과 힘들었던 점이 있었다. 리액트는 신기했다. state를 변경하는 것 만으로도 렌더링이 바로 된다니 이것 자체가 너무 신기했다. 하지만 리액트를 처음 접하게 되면서 오는 어려움들이 훨씬 많았던 프로젝트였다.

힘들었던 점

• 컴포넌트 구조 설계 - 어디까지 쪼개야 할까..?

  컴포넌트를 어느 부분까지 쪼개서 사용해야 될지가 고민이 많이 됐다. 욕심 같아서는 다 나눠 버리고 싶은데 그러면 그 많은 컴포넌트들을 어떤 폴더 구조로 관리할 수 있는지 감도 안 왔다. 이런 고민을 하면서 atomic 디자인 같은 몇몇의 디자인 패턴을 봤는데 적용하기 쉽지는 않았던 것 같다.

• 리액트적 사고?가 어색했다.

  vanilla JS로 개발할 때는 state를 model에 두고 view와 model이 통신하면서 상태를 관리했다. 하지만 리액트에서는 각각의 view가 state를 가지고 있고 서로 다른 view가 하나의 state를 사용하기 위해서는 상위의 컴포넌트에서 state를 관리했어야 했다. 이 점을 다 고려해 어떤 컴포넌트에 어떤 state를 둘까에 대한 고민을 많이 하게 됐다.

• state가 많아질 수록 내가 과부화가 걸린것 같다.

  state를 이곳저곳에서 관리하다 보니 얘가 어디 있던 애더라.. 하면서 많이 헤맸었다. 하지만 우리 팀원 중 Pyro가 리액트에 대해서 잘 아셔서 커스텀 훅이라는 것을 알려주셨고 그것을 적용해 커스텀 훅에서 그 상태를 관리하는 메소드들과 함께 묶어두니까 훨씬 수월했다.

• state의 변경에 대한 확신??이 힘들었다.

  이 문제는 내가 리액트를 아직 잘 모르기 때문에 발생한 문제라고 생각된다. state를 props로 전달해가면서 사용했는데 이 state가 정말 변경된 상태의 state일까? 라는 생각을 정~말 많이 한 것 같다. 기능을 하나씩 추가할 때마다 관리해야 될 state는 점점 늘어가는데 지금 사용하는 이 부분에서 항상 최신의 state가 들어올 수 있을까?라는 확신이 없었다. 리액트의 동작 과정을 정확하게 알지 못하는 상태에서 나오는 문제점 같다.

• 리랜더링이 되는 요소를 정확하게 파악할 수 없었다.

  나는 단순히 상위 컴포넌트가 리랜더링되면 하위 컴포넌트도 변경된 props에 따라서 자연스럽게 바뀔 줄 알았다. 그런데 안 그러더라..? (내가 잘못 만들어서 그럴 확률도 있다.) 그래서 useEffect를 사용해 받아온 props가 변경될 때마다 state를 변경시켜주니까 해결됐다. 이 문제도 리액트를 잘 몰라서 생긴 문제 같다. 근데 왜 상위 컴포넌트가 리랜더링 되면서 하위 컴포넌트들도 다시 호출해서 생성할 텐데 왜 바뀌지 않을까..?

• immutable Data에 대해..

  JS의 Boolean, null, undefined, Number, String, Symbol을 제외한 모든 것은 객체이고 객체는 mutable하다. 하지만 이런 mutable Object는 리액트 상태에서 잘 관리 해줘야 됐다. 새로운 객체로 만들어서 완전히 새로운 객체를 넣어줘야 변경이 됐다고 인지했다. 이 문제가 단순한 1차원, 2차원은 문제가 없었는데 점점 더 깊어질수록 난리가 나더라.... spread syntax를 휘갈기는 나를 보면서 어떻게 해야 되나... 이 생각을 했다. Object.assign, Object.freeze가 있다곤 하지만 shallow copy라서 spread와 다를게 없다고 생각했다. Immutable 객체를 만들기 위해서 Facebook이 Immutable.js를 제공한다고 하는데 공부해봐야겠다. (추가: 깊은 복사와 얕은 복사에 대한 심도있는 이야기글을 보고 깊은 복사를 유발할 때 깊게 고민해봐야겠다. 성능상 별로기 때문에.. 그러면 상태는 immutable.js로 사용해 immutable로 애초에 만들면 보다 안전?하게 관리할 수 있지 않을까??)

• props를 이렇게 많이 넘겨줘도돼???!?

  이것도 문제다. 아직 useContext나 useReducer같은 hook은 사용해보지 못했다. 이번 프로젝트에서는 의도적으로 사용하지 않은 것도 있다. 다른 hook을 사용하면 해결될 수 있는 문제인지는 모르겠지만 props가 기능 추가할 때마다 하나하나 추가되고 결국... 참 많다! 특히, 리팩토링을 하면서 조건부에 따라 랜더링되는 부분을 각각의 큰 컴포넌트 하나하나로 만들려고 했는데 그러면 또 props가 난리가 나더라... 그래서 이번에는 못했다...(크롱 죄송함다..) 이 부분에 대해서는 공부를 더하면서 고민을 해봐야 될 것 같다.

• 성능...? 그게 뭘까요...?

  프로젝트 첫 시작 날의 포부와 달리 성능이나 랜더링 되는 부분 같은 것들을 고려할 처지가 아니었다. 이건 힘들었던 점보다는 아쉬웠던 점이다. (애초에 살짝은 포기했다🤦‍♂️)

회고

TODO LIST나 Drag and Drop의 로직보다는 프로젝트를 진행하면서 느낀점?들을 작성하려고 했는데 무슨 죄다 힘든 점만 나온다...? 깊게 생각하지도 않았는데 계속 나오는 느낌이다. 라이브러리 공부를 병행하면서 진행한 프로젝트여서 어쩔 수 없나 보다. 그래도 재밌었다. 2주전까지 나는 리액트를 1도 모르는 상태였는데 이제는 뭐라도 만질 수 있고 뭐라도 궁금해할 수 있는 상태가 된 것 같다.

항상 그렇지만 기본이 중요하다고 느꼈다. 이게 리액트에 대한 기본이 없으니 이게 왜 안되는 거지? 이게 된다고? 이러면서 개발했던 것 같다. (함께한 Jenny와 제발.. 제발.. 돼라 했던 기억이..) 내 코드에 확신을 가질 수 있게 만들자!

프로젝트를 하면서 분업?에 대해서도 고민이 된다. 이번에는 6시까지만 페어 프로그래밍하고 그 이후 시간에는 각자 공부하는 시간으로 할애했는데 리액트를 처음 접하는 입장에서 나름 좋은 방법이었다고 생각했다. 항상 페어 프로그래밍을 하면서 상대로부터 많은 것을 배운다. 이번에도 Jenny에게 많이 배웠는데 특히 해결하지 못했던 드래그 앤 드롭을 밤까지 고민하고 해결해주셔서 잘 완성할 수 있었다.

다음 프로젝트는 위에 적은 문제점들을 신경 써서 최대한 개선하려고 노력해야겠다.