[우테코] Lv. 1 런치 구현 - 2단계

배경지식!

01. 점차 체력이 떨어져간다.

02. 추가되는 기능/ 선호목록 만들기, 선호-비선호, 세부정보 모달

03. 꼬여버린 임포트

---

1. PR 메세지 + 리뷰(답변)

Q. 대략적인 파일 임포트 : 위에서 보실 수 있다시피 굉장히 파일이 엉켜있습니다. 이를 해결하기 위해서 붙잡고 있었지만 도저히 해결할 수 없었습니다. 이렇게 된 원인을 제 생각대로 말하자면, 컴포넌트의 불명확한 정의라고 생각합니다. 컴포넌트를 재활용이 가능한 엘리먼트 단위정도로 생각했습니다. 때문에 파일 안에 템플릿과 그 엘리먼트 용도에 맞는 함수들을 넣었습니다. 그 결과 다른 곳에서 그 함수를 필요로 한다면 그 파일을 임포트하게 되고, 이것이 상하관계 없이 이어지며 결국 서로가 서로를 임포트하는 상황에 이르렀습니다.

이 상황이 굉장히 안 좋은 것은 알고 있지만 타개책을 모르겠습니다. 컴포넌트에서 하는 일들을 빼내어 다른 곳에서 한다면 컴포넌트가 컴포넌트로 존재하는 것인지, 템플릿만 담은 파일인지 모르겠어서, 일단 반대로 각 컴포넌트에 함수를 넣었지만 파일간의 종속성이 강해지고 꼬여버리게 되어버렸습니다. 정답은 없다고 하지만 이 코드는 잘못된 것이 맞는 것 같습니다.. 구조에 대한 조언을 주시면.. 감사하겠습니다..

 

review  음 현재는 그림이 꼬여버리는거 아닌가요??!! 넘 걱정마세요 직접 그려보세요. 그래야 더 배우는 것도 많습니다! 저렇게 생성해주는 것은 보통 import, export 기반으로 그려서 엄청 꼬여서 그려주더라고요. 현재는 UI, 페이지 별로 나누고 공통 로직 같아보이는 것은 도메인으로 보내고 있는데요.

조언이라고 한다면.. 딱 2가지가 떠올라요. App.js와 domain 계층입니다. App.js에서 정말 많은 일을 하고 있는데 어디서 로직을 제어할 것인가에요. 현재 App.js는 마스터처럼 모든 것을 제어하도록 되어있어서 이 부분을 떼어내는 방향을 추천드리지만 아마 현재 앱이 커져서 어려우실거에요. 다음 미션에서 고민해보세요. App.js를 부모님이라고 생각하고 사사건건 모든 것을 통제하게 둘 것인가 vs 아니면 기본적인 틀만 주고 알아서 하도록 확장 시킬 것인가요 ㅎㅎ domain 계층은.. 여전히 뭔가.. UI에 종속적인 느낌이라서 그 부분을 순수한 데이터 관점으로 드리븐해보시면 뭔가 해답이 보일 것 같네요

 

review review app.js 에서 정말 많은 일을 하고 있다? app.js에서는 랜더링하는 것과 이벤트를 부여하는 두 기능을 한다. 이 두 가지 하는 것이 많은 걸까..? index.js 와 app.js는 비우는 경우가 많은데 그걸 생각하면 많은 일을 하고 있는 것 같기도 하다. 그렇담 app.js 안에 있는 두 기능은 어디로 가는 것이 옳을까? 무엇을 해야 하는 지 모르겠다면 일단 그대로 두는 것이 차선책인 것 같다.

 

 

 

* 궁금한 점:  유효성 검사

Q.  유효하지 않은 값들이 들어오거나, select option index에 없는등 문제가 되는 상황에 대해 어떻게 대처할지 말씀해주셨습니다. 이미 html로 필수값 지정이 되어있거나 number 등으로 타입이 정해져 있는 경우에도 유효성 검사를 하는 것을 선호하시는 지 궁금합니다. 더불어서 한다면 어느 파일에서, 어느 부분에서 하는 것이 적절한지 궁금합니다. 이것 역시 try catch 등으로 다시 입력 받도록 유도하는 것이 좋을까요?

 

review 유효성 검사는 무조건 빡빡할수록 좋습니다.  유효성 검사를 어디에서 하는 지는 내 앱을 사용하는 사용자, 내가 만든 함수를 사용하는 동료 개발자 둘에게 어떻게 알려줄 것인가?!로 고민해보시는게 어떨까요!? 

 

review review 내 앱을 사용하는 사용자에게 알려주려면 input이 들어오는 그 순간에 확인을 해서 다시 입력하도록 만드는 것이 옳아보인다. 이런 경우 더 깊이 들어와서 비용이 발생하고 데이터를 변화시킬 위험을 만드는 것보단 초장에 잡는 것이다. 그리고 내 동료 개발자에게 알려준다고 한다면 이런 validation을 따로 파일로 빼내고 필요한 곳에서 호출하는 것이겠지? 이건 콘솔게임에서 했던 것과 같은데 이렇게 생각을 해보면 크게 맥락이 다른 것 같지는 않다. form으로 정보를 받았을 때 하는 것이 맞는 것 같다.

 

 

 

Q.  id를 사용하는 것에서 문제가 발생할 수 있다고 해주셨는데, 저 역시도 지금처럼 보호받지 못하는 객체배열, id, html - class, index 등을 기준으로 로직을 짠다면 리팩토링을 하다가, 기능을 추가하다가 자칫 문제가 생길 수 있다고 생각됩니다. 데이터를 다른 곳에 백업을 해놓는 것이 안정성을 높일 수 있는 대안이 될지, 다른 방식이 있을지, 혹은 이를 보호할 함수가 있을지 궁금합니다.

 

review  id, class, index를 기반으로 셀렉터를 활용하고 코드를 작성하는 것이 무조건 문제라는건 아닙니다 ㅎㅎ 하지만 이것은 케이스에 따라 달라요 🤔 id, class는 브라우저에 수 많은 HTML 요소를 개발자가 DOM으로 가져와 어떻게 활용할까? 인것인데요 거기서 그 식별자들을 구별할때 예상될 수 있는 문제점이 보여서 말씀드려봤고요. index 같은 경우에도 언제나 순서가 일정할까? 이 데이터가 서버에서 오는거라면? 유저가 잘못된 정보를 넘긴다면? 이런 관점에서 코드를 작성해보시면 됩니다. 지금은 TDD도 열심히 공부하고 계시니 함수보다는 어떻게 꼼꼼하게 오류가 없는 코드를 만들 수 있는 개발자가 될까라는 의식적인 생각만 있어도 충분해요 💭

 

review review id.. 일단 여기서 언급된 부분은 아니지만 id를 이렇게 쓴느 것보다는 data 속성을 사용하는 것이 좋다고 한다. 왜? html을 열었을 때 보이지 않아서 보호된다는 장점이 있고, 데이터라는 목적이 있기 때문에 사용에 더 적합하다는 것이다. 관련된 부분은 https://riviere.tistory.com/108을 참고하면 좋다. 

 

 

 

* 기능구현 + 테스트 즐겨찾기 기능 추가

즐겨찾기를 위해 레스토랑 객체에 Like 키를 부여했습니다. 더불어 id를 통해 해당 항목을 클릭 시 어느 객체를 부르고 있는지 유추할 수 있도록 만들었습니다. 가장 큰 변화는 레스토랑 목록에 이벤트를 부여하여 즐겨찾기 버튼을 누르면 선호/비선호로 객체 속성이 변화하도록 만들었고, 그외 영역을 누르면 해당 레스토랑 정보가 보이도록 만들었습니다. 이는 이벤트 위임을 하여 레스토랑 목록 전체에 이벤트 하나를 부여하고, 클릭이 어느 영역에 되었는지 판별해 각 후속진행을 했습니다. 목록 영역의 변화, 모달의 여닫음을 위해 토글을 이용했습니다. 유틸로 사용하기 위해 인수로 엘리먼트와 클래스명를 받도록 했습니다. 테스트 간단한 단위테스트와 e2e테스트를 진행했습니다.

 

---

결과적으로 내가 배운 내용

1. 이벤트 위임 = 이벤트를 많이 부여할수록 무거워진다.

2. toggle = 클릭으로 흑/백 이벤트를 만들고 싶다면

3. test를 왜 쓰면서 해야 하는지 = 간결한 코드

4. 도메인과 UI는 분리해야 한다. = 서로가 서로를 임포트하게 만들고 싶지 않으면

5. 목적에 맞게 쓰자 = button/ div에 onClick / input type="button" / nav / li ... / data 속성 등 시멘틱과 용도에 맞게