Dony :)

FE로 성장 중 🌱

TIL 🧐

아쉬워요 🙁

이번 주는 수업 시간에 라이브로 1:1 리뷰를 받아 정신이 혼미한 한 주였다 @_@..
거의 10분 동안 사람들 앞에서 리뷰를 받는게 공개 처형(?)의 느낌이 나서 ..ㅎㅎㅎㅎ
내가 무슨 말을 하는지 기억이 나지 않을 정도였다 😵
그래도 사실 이렇게 길게 리뷰 받을 기회가 언제 있겠나 싶어 위로하는 중이다..ㅎㅎ
사람들 말로는 관심이 있으니 대표로 말해주신거다 라고 하는데.. 그렇다고 행복 회로를 돌려보았다! 🙄
황금 같은 리뷰니!
리뷰의 내용을 정리하자면

event들을 모아놓는 게 일반적이지 않다.
다른 사람이 해당 컴포넌트의 이벤트를 수정하고 싶을 때 해당 컴포넌트의 파일을 열어보지 그 컴포넌트의 이벤트가 다른 곳에 있는지 알기 힘들다.

  • 변명
    원래 의도는 MVC에서 controller가 event를 담당하는 역할도 하므로 controller가 비대해지는 것을 막기 위해 controller는 초기 렌더에 필요한 data와 view를 통신하게 하고, eventListner가 event에 필요한 data와 view를 통신하는 역할을 하려고 했다.
    그러나 이벤트만을 따로 분리해보니 controller에서 생성한 render 함수가 eventListner에서도 필요하여 불러오다보니 eventListner와 controller의 결합이 강해지고 순환참조를 하게 되는 일이 생겨버려 이상한 점을 느끼고 있었다..
  • 개선
    event를 컴포넌트 안에 모두 넣어주고 export 하여 해당 이벤트들을 컴포넌트들을 조합해주는 pages에서 gnb의 target에 따라 해당 페이지를 렌더한 뒤, 해당 페이지에 달린 이벤트들을 실행할 수 있도록 개선하였다.


폴더 구조를 다시 생각해보자. 폴더 안에 파일들은 형제 관계여야 하며, 폴더와 파일이 같은 경로에 있다면 해당 폴더와 파일도 형제 관계여야 한다.

지금은 component 안에서도 작은 컴포넌트와 이를 사용하고 있는 큰 컴포넌트들이 한 폴더에 같이 들어있고, src 폴더 하위에 data폴더와 data.js가 함께 있고 index.html, controller.js, eventListner.js, utility.js 같이 동급 관계가 아닌 파일들이 같은 경로에 함께 들어있다.

  • 변명
    솔직히 폴더 구조는.. 감이 잘 오지 않았다.
    css 관련 파일들은 몰라도 회사에서 js는 여태까지 ui.js, common.js 로, 페이지별 js 이런 식으로 나누어 왔었기 때문에 컴포넌트와 렌더에 관한 js들을 어떻게 해야할지, 어떤 단어를 써야할지도 감이 오지 않았다.
    그러다보니 js 폴더는 다른 사람들 구조를 참고하여 약간 짜집기 식으로 두고 크게 신경쓰지는 않았던 부분이라 굉장히 뜨끔하였다..
    내가 폴더구조를 신경쓰지 못한 걸 바로 알아차리셨다. (지금 다시 보니 모를 수 없을 구조긴 하다.)
    변명의 여지 없음 😷

  • 개선
    👉

    • data.js라고 막연히 적어놓은 파일을 pageDataFinder라는 구체적인 이름과 data 폴더에 json 폴더와 동급으로 넣어두었다.
    • constant라는 애매한 파일은 사실 전역에 둘 필요가 없는 변수들이 많아보여 해당 파일에서 필요한 함수에서 생성하게 변경해두었다. 만약 constant 파일이 필요하다면 common이라는 폴더에 넣지 않을까 생각해보았다.
    • view.js 파일 또한 마찬가지고 render라는 구체적인 역할의 이름으로 바꾼 후 views라는 폴더에 components와 pages 폴더를 함께 넣어두었다.
    • mainBanner.js 안에 두었던 slide 기능도 모듈처럼 사용할 수 있게 수정 후, modules/slider 폴더 안에 slider.js로 빼내었다.
    • eventListner.js 파일은 컴포넌트 안에 이벤트를 넣어주었기 때문에 render.js에서 해당 컴포넌트 이벤트들을 실행해주는 함수에 데이터를 넘겨줄 함수를 controller에서 넣어주었다.

    확실히 개선하고 나니 코드가 깔끔해지고, controller와 eventListner 파일에서 관련 함수들을 어떻게 넘겨주지, 연결고리를 어떻게 느슨하게 하지 하는 고민들이 일부 해결됐고, controller가 깔끔해졌다.


컴포넌트들 안에서 서로가 서로를 불러오는 것은 위험하다.

  • 변명
    카카오페이지는 특이하게 모든 페이지들이 다 중복된 섹션들이 하나씩 있었다.
    때문에 처음에 중복된 섹션들을 재사용하기 위해 섹션별로 컴포넌트를 나누었다.
    그런데 그 안에서도 반복되는 부분들이 또 있었고, 그 부분들에서도 재사용하기 위해 또 나누었다.
    그러다보니 큰 컴포넌트 안에서 작은 컴포넌트들을 import해와 사용을 하였다.
  • 개선
    사실 PR을 더 늦게 보내면 안될거 같아 이 부분은 많이 개선하지 못하고 고민만 늘어놓다 끝이 나버렸다.
    하지만 개선할 방법들을 이것저것 고민해보고 PR 메세지에 남겨보았다.
    카카오페이지 클론 - 6번째 PR
    자세한 설명을 요청하셔서 제일 하단에 댓글로 여러가지 생각한 방법들의 예시 코드를 적어 설명 드렸다.
    그리고 내가 생각하기에 좋아보이는 코드와 그 이유에 대해 말해보고 의견을 여쭤보니 리뷰어님은 다른 코드를 선택하셨지만 취향 차이일 수 있으니 원하는 코드를 하라고 말씀해주셨다.
    크롱과 리뷰어님이 항상 하시는 말씀이 자신이 그걸 왜 좋다고 생각하는지 이유가 뚜렷하면 된다고 하셨다.
    왜냐면 코딩에 정답은 없으니까..!
    그리고 덧붙여주셔서 컴포넌트끼리 참조가 왜 위험하다고 하셨는지 생각을 해보라고 하셨다.
    사실 그러고 보니 직접적으로 참조하는 건 위험하지 맞아! 라고 막연히 생각한 거 같다..
    다시 생각을 해보았다 왜 위험할까?
    컴포넌트끼리 직접 참조하면 해당 컴포넌트 안의 함수와 변수들을 직접적으로 사용하게 된다. 그런데 안에 작은 컴포넌트가 바뀌게 된다면?
    해당 컴포넌트 소스를 거둬내는 일이 쉽지 않을 것이다. 유연성을 잃는 것이다.
    내가 생객해본 위험성은 이렇다. 직접 저런 상황이 되보면 더 잘느끼겠지..!

잘했어요 🙂

사실 이번 주는.. 반성의 시간을 많이 가졌다보니 열심히는 했지만 잘한지는 모르겠다..
그럼에도 칭찬은 해줘야하니!
나와 비슷한 문제가 있는 사람들이 지금 고치기엔 3주간 해왔기 때문에 힘드니 다음에 고려해서 짜보라고 했지만..
한번 코드가 맘에 안들면 지나치지 못하는 병이 있어.. 대공사를.. 시작하였다.
새벽 6시반까지 뜯어고치고 다음 날에도 저녁이 되서야 얼추 마무리해 PR을 보냈다.
잘.. 은 모르겠지만 이전에 비해 확실히 깔끔해졌다.
사실 express가 잘 이해가 안가서 이걸 공부하는 것도 급하지만.. 그래도 후회는 하지 않는다.
주말에 공부 하면 되니까!
포기하지 않고 대공사를 한 점은 칭찬해주고 싶다!

참고