[1단계 - 음식점 목록] - 치코(이재민) 미션 제출합니다. by jaeml06 · Pull Request #113 · woowacourse/javascript-lunch

jaeml06 · 2024-03-08T07:58:32Z

안녕하세요 블링.

이번 미션을 진행하며 재사용을 위한 컴포넌트를 어떻게 설계할지 고민을 많이 했습니다.

타입스크립트는 처음 사용하여 일단 도메인 부분에만 적용하였습니다.

프로젝트 시작 방법입니다.

npm install

npm run start

궁금점 질문드립니다.

처음에 웹 컴포넌트를 사용하려고 하였으니 태그에 속성 값은 문자열만 넘길 수 있다고 하여 배열과 객체 값을 넘길 수 없었습니다. 그래서 웹 컴포넌트를 포기하고 함수로 동적으로 생성하는 방식으로 만들었습니다. 다만 그렇게 만드는 함수에 값을 너무 다양하게 넘겨줘야하는 문제가 있는 것 같습니다. 위와 같은 방식이 문제가 없는지 궁금합니다.

다음의 파일 구조입니다.

📦src
┣ 📂component
┃ ┣ 📂toast
┃ ┃ ┣ 📜toast.css
┃ ┃ ┗ 📜toast.js
┃ ┣ 📜button.js
┃ ┣ 📜dropDown.js
┃ ┣ 📜header.js
┃ ┣ 📜input.js
┃ ┣ 📜labelWrapper.js
┃ ┣ 📜modal.js
┃ ┣ 📜restaurantCard.js
┃ ┗ 📜textArea.js
┣ 📂constant
┃ ┗ 📜cons.js
┣ 📂domain
┃ ┣ 📂interface
┃ ┃ ┗ 📜IRestaurant.ts
┃ ┗ 📜RestaurantManager.ts
┣ 📂images
┃ ┣ 📜add-button.png
┃ ┣ 📜category-asian.png
┃ ┣ 📜category-chinese.png
┃ ┣ 📜category-etc.png
┃ ┣ 📜category-japanese.png
┃ ┣ 📜category-korean.png
┃ ┣ 📜category-western.png
┃ ┣ 📜favorite-icon-filled.png
┃ ┗ 📜favorite-icon-lined.png
┣ 📂utils
┃ ┗ 📜selector.js
┣ 📂web
┃ ┣ 📂modal
┃ ┃ ┗ 📜addRestaurantModal.js
┃ ┗ 📜control.js
┗ 📜index.js

페이지 링크: https://jaeml06.github.io/javascript-lunch/

Co-authored-by: jaeml06 <jaeml0630@gmail.com>

Co-authored-by: Pakxe <pakxe@users.noreply.github.com>

Co-authored-by: pakxe <pigkill40@naver.com>

Co-authored-by: Pakxe <pakxe@users.noreply.github.com>

Co-authored-by: pakxe <pigkill40@naver.com>

Co-Authored-By: pakxe <pigkill40@naver.com>

parent 삭제 required 추가 innerHTML에서 createElement로 구현 Co-Authored-By: pakxe <pigkill40@naver.com>

parent 삭제 restaurantManager 추가 Co-Authored-By: pakxe <pigkill40@naver.com>

Co-Authored-By: pakxe <pigkill40@naver.com>

jaeml06 · 2024-03-08T08:02:06Z

+  return header;
+}
+
+// REFACTOR: 앱 이름 상수로 분리


header안에 양옆에 들어갈수 있는 아이템과 값들을 상수로 선언하여 밖에서는 무엇을 넣을지 문자열로 넘겨주면 됩니다. 다만 고민되는 것이 이 item들의 위치가 componet파일에 있는 것이 좋은지 아니면 밖에 따로 constant폴더에 존재하는 것이 좋은지 고민 입니다

상황에 따라 다르고 약간은 취향일 것 같아요!
만약에 다른 파일에서도 쓰일 가능성이 있거나 컴포넌트 파일이 너무 방대해진다고 하면 다른 파일로 분리하는게 좋겠고, 그렇지 않다면 같은 파일에 있어도 상관없지 않을까 하는 생각입니다.

네 상황에 따라 유동적으로 하겠습니다.

jaeml06 · 2024-03-08T08:06:38Z

@@ -0,0 +1,43 @@
+import { $ } from '../utils/selector.js';
+
+function createDropDown({ id, callback, options, className, required, cover }) {


전체적인 컴포넌트 고민입니다. 컴포넌트의 구현을 create.... 함수만 공개하고 나머지는 export하지 않아 공개하지 않는 방식을 사용하였습니다. 저는 이러한 함수가 딱히 밖에 공개돼도 상관없다고 생각하여 객체로 묶을 생각이었습니다. 그래서 예시로 dropDown.create() 이런 식으로 사용하고자 했습니다. 아니면 클래스를 이런 부분이 단순히 취향차이인가요? 블링의 의견이 궁금합니다

딱히 밖에 공개돼도 상관없다

라고 판단하신 이유가 중요한 것 같아요! 객체로 묶어서 dropDown.create()로 하는 것을 처음에 더 선호하신 이유가 있을까요? 취향차이라고 하더라도 그 이유는 있을 것 같은데요?

또 노출할 함수들만 export 하더라도 dropDown 객체로 감싸서 내보낸다고 하면 충분히 dropDown.create()로도 할 수 있지 않을까요?

const notExport = () => {} const createDropdown = () => { notExport() } export const Dropdown = { create: createDropdown }

저는 앞에 확실히 dropDown.create와 같이 객체 이름으로 표시되는 것이 이게 무엇에 관련된 함수라는 것을 더 명확히 확인할 수 있어서 선호합니다. 또한 보통 하나의 파일의 이름과 공개되는 객체의 명이 같기 때문에 어느 파일에서 정의된지 더 명확하게 파악할 수 있다고 생각합니다.

블링 말대로 노출할 함수만 객체로 감싸서 내보내는 방법도 있네요. 여기서 궁금증이 생기는데 함수를 공개할지 말지는 무슨 기준이 있을까요? 저는 이 DropDown.js 안에 있는 함수들은 딱히 사이드 이펙트를 발생시키지 않는다고 생각합니다. 그래서 공개해도 문제가 없다고 생각하고 문제가 없다면 쓸일이 있지 않을까?하고 생각합니다. 아직 메서드들의 공개 여부에 대한 기준이 아직 제대로 있지 않아서 생긴 문제 같습니다.

공개하지 않는 이유는 이 컴포넌트를 사용하는 사람들에게 오히려 많은 선택지를 주면 오히려 혼란이 생기기 때문에 원래 제공하려고 했던 기능만을 공개하는 것이 그 이유다 라고 생각하는데 충분히 납득 가능하신가요?

dropDown.create와 같이 객체 이름으로 표시되는 것이 이게 무엇에 관련된 함수라는 것을 더 명확히 확인할 수 있어서 선호

그건 함수명을 createDropdown으로 만들어도 충분히 의미를 드러낼 수 있지 않나요?

보통 하나의 파일의 이름과 공개되는 객체의 명이 같기 때문에

이것도 지금의 컨벤션이고 충분히 달라질 수 있는 부분이라고 생각하구요.

함수를 공개하거나 말아야 하는 이유가 1. 사이드 이펙트를 발생시킨다. 2. 많은 선택지로 인해서 혼란스럽다 정도로 생각하신 것 같아요! 근데 분명 더 다양한 이유도 있을 수 있다고 생각합니다.
export 되어있는 함수는 다른 곳에서 사용할 수 있도록 공개해두었다라고 충분히 판단할 수 있는 근거가 되고, 협업하는 동료들이 이 함수를 자의적으로 해석하고 활용할 수도 있죠. 지금 당장은 그것이 문제가 되지 않을 수도 있습니다. 하지만 만약에 해당 로직에 중대한 변화가 생겨서 원 제작자가 로직을 변경했는데, 그 함수에 의존하던 다른 모듈들이 오류를 일으킨다면, 전혀 예상하지 못하게 문제를 일으킬 수도 있겠죠.
그래서 외부에서 사용하지 말아야 할, 이 파일 혹은 모듈에 특화된 매서드/함수들을 어떻게든 명시해서 '사용하지 마시오'를 알리는 것은 중요하다고 생각합니다. 그중 하나의 방법이 아예 사용을 못하게 export 하지 않는 방식이구요.

이런 점들을 고려했을 때 어떤 방식이 좋다고 생각하시나요?

그런 이유도 있겠네요. 제 생각이 짧았습니다. createDropDown 함수 방법도 있다고 받아들이겠습니다. 처음부터 해오던 방식이 익숙해 새로운 방식에 선입견이 생겨 꺼려졌던 부분이 있던 것 같습니다. 위의 이유를 종합해볼 때 지금 이대로 두는 것이 장점이 더 많다고 생각합니다. 만약 객체로 사용하고 싶으면 예시로 설명했던
#113 (comment)
방법으로 도입하는 것을 고려하겠습니다.

jaeml06 · 2024-03-08T08:14:04Z

+
+  const form = document.createElement('form');
+
+  const categorySelect = createDropDown({


과연 이부분을 따로 선언하고 사용해야 하는지 고민입니다. 재사용이 없어 categorySelcterLabelWrapper의 innerHTML에 바로 값에 넣는 것이 더 가독성이 좋다고 생각하는데 모두 그렇지는 않더라구요. 블링의 의견이 궁금합니다.

음... 가독성의 차이라고 보이지 않을까 싶어요!
처음 코드를 보는 사람이 이 요소를 생성하는 함수만 보고 카테고리를 생성하는 거구나! 라고 알기 쉽지 않다면 의도를 잘 담은 네이밍을 해서 변수에 담는 것이 가독성을 훨씬 높여줄 수 있다고 생각합니다.

그러면 변수에 담는 것이 더 가독성이 좋겠네요!

jaeml06 · 2024-03-08T08:33:36Z

+
+    try {
+      restaurantManager.add(newRestaurant);
+      set.updateRestaurantList(restaurantManager.getRestaurants());


현재 음식점을 추가하면 선택된 카테고리로 보이는 것이 아니라 전체 음식점 리스트가 보이는 버그가 있습니다. 수정중입니다.

수정했습니다. 다만 궁금증이 있습니다. 레스토랑이 추가되는 시점에 내가 선택했던 카테고리와 정렬기준을 반영하기 위해 RestaurantManager 클래스 내에

curentSelectedCategory와 curentSelectedSorting를 사용하여 기억하고 있습니다. 과연 이런게 현재의 최선의 방법인가 생각이 듭니다.

계속 고민했지만 다른 좋은 방법이 생각이 나지 않습니다. 그나마 생각난 방법은 매번 정렬과 카테고리를 선택할 떄마다localStorage에 저장하고 가져오는 방식이 있는데 이는 매번 코드가 단순해지고 private 변수를 줄일 수 있다는 장점이 있지만 매번 데이터를 읽어와야 하기 때문에 성능이 떨어진다고 생각합니다.
실제로 업계에서는 다량의 목록을 매번 최신화된 데이터를 불러와 보여주는지 아니면 한번 로드한 데이터를 필터하여 보여주는 지 궁금해졌습니다. 과연 블링의 취향은 무엇이고 실제로는 무엇을 더 많이 쓰나요?

현재 선택된 정보를 변수로서 기억하지 않고 하는 방법이 있나요?
물론 말씀하신대로 매번 선택의 결과로 저장된 결과를 다르게 만들 수는 있지만,
그렇게 할 때 들어가는 비용과 변수 두 개를 메모리에 들고 있는 비용을 비교했을 때에는
후자가 조금 더 현실적이지 않나 하는 생각입니다. 지금은 데이터가 몇 개 없지만, 수천개, 수만개씩 데이터를 가지고 있는데,
이 정렬 기준에 따라서 매번 다르게 저장하는 것은 어려울 수도 있을 것 같아요.

다만 서버 데이터가 있어서 정렬을 서버에서 하고 있다면 프론트는 매번 요청을 보내서 새로운 목록을 받아오긴 할겁니다.
대신 선택된 정보를 서버로 보내기 위해서 그 때에도 변수를 어딘가에 저장해두고 사용하긴 하겠지만요.

답변 감사합니다. 지금 제가 적용한 방법이 좀 더 현실적이네요.

uk960214

안녕하세요 치코! 이번 미션 리뷰어를 맡게 된 블링이라고 합니다.
미션 구현하느라고 고생 많으셨습니다!!

👍 이런 점이 좋았어요

컴포넌트의 구분과 렌더링 방식이 아주 깔끔하고 좋았어요. 재사용하는 데에도 유용할 것 같아요. (제가 생각하는 가장 적절한 수준의 컴포넌트 구조입니다!! 👍)
아직 제한적이긴 하지만 타입스크립트도 잘 적용해주신 것 같아요.

🤔 이런 점은 조금 더 생각해볼까요?

컴포넌트, 함수의 네이밍이 너무 포괄적이고 모호한 경우가 있는 것 같아요. 여러 개의 파일을 번갈아서 보다보면 어떤 것이 뭐인지 헷갈릴 때가 있는데, 이름이 조금 길어지더라도 의미를 명확하게 드러내주는 편이 더 좋다는 것이 개인적이 생각입니다.
질문주신 부분 전반적으로 '이래도 되고 저래도 되지 않을까'하는 질문들이 많았는데, 물론 취향이나 사소한 이유로 갈릴 수도 있겠지만 나름의 타당한 이유를 가지고 선택하고 협업하는 동료들을 설득할 수 있으면 되지 않을까하는 생각이 들었습니다!

질문 주신 부분에서 함수에 너무 다양한 값을 넘겨주셔야 한다고 하셨는데, 저는 이것이 큰 문제가 되지 않는다고 생각합니다!

코멘트와 리뷰 확인해서 다시 리뷰요청 주세요! 화이팅입니다!! 💪

uk960214 · 2024-03-09T05:41:20Z

이 파일은 어떤 의미가 있나요?

cypress실행시 자동으로 설정된 파일입니다. 제가 알아본 바로는 재사용 가능한 사용자 정의 명령을 만들어 사용할 수 있는 공간이고 합니다. 현재 저도 아직 정확히 감을 잡지 못해서 사용해보면서 익혀야 할 것 같습니다.

cypress에서 제공한 다양한 파일/기능들에 대해서 조금 더 공부해봐도 좋을 것 같네요!

넵. 이용할 수 있는 함수들이 무엇이 있는지 공식 문서에서 더 공부해보겠습니다.

uk960214 · 2024-03-09T05:43:05Z

@@ -0,0 +1,43 @@
+import { $ } from '../utils/selector.js';
+
+function createDropDown({ id, callback, options, className, required, cover }) {


딱히 밖에 공개돼도 상관없다

라고 판단하신 이유가 중요한 것 같아요! 객체로 묶어서 dropDown.create()로 하는 것을 처음에 더 선호하신 이유가 있을까요? 취향차이라고 하더라도 그 이유는 있을 것 같은데요?

uk960214 · 2024-03-09T05:48:13Z

+    const selectedOption = dropdown.value; // 선택된 옵션 값
+    callback(selectedOption); // 콜백 함수 호출


주석이 없어도 코드를 이해하는데에 큰 문제가 없을 것 같은데 어떻게 생각하시나요?

넵 지우겠습니다. 제출 마지막에 알아챈 버그때문에 수정을 깜빡했습니다.

uk960214 · 2024-03-09T05:51:04Z

+  select.className = className;
+  select.required = required;
+
+  if(!!cover) {


여기서는 cover는 무엇인가요??

cover는 select에서 option에 기본으로 선택된 메세지입니다. 이 프로젝트에서는 '선택해 주세요'입니다. 다만 이 변수명으로는 어떤 용도로 쓰이는지 알기 어렵네요.
NoneSelcteddefaultMessage이라는 변수명을 사용하겠습니다.

요 변수는 NoneSelected~로 Pascal로 되어있는 이유가 있을까요?

실수했습니다. 수정했습니다.

uk960214 · 2024-03-09T05:53:49Z

@@ -0,0 +1,43 @@
+import { $ } from '../utils/selector.js';
+
+function createDropDown({ id, callback, options, className, required, cover }) {


또 노출할 함수들만 export 하더라도 dropDown 객체로 감싸서 내보낸다고 하면 충분히 dropDown.create()로도 할 수 있지 않을까요?

const notExport = () => {} const createDropdown = () => { notExport() } export const Dropdown = { create: createDropdown }

uk960214 · 2024-03-09T06:16:17Z

+
+  const form = document.createElement('form');
+
+  const categorySelect = createDropDown({


음... 가독성의 차이라고 보이지 않을까 싶어요!
처음 코드를 보는 사람이 이 요소를 생성하는 함수만 보고 카테고리를 생성하는 거구나! 라고 알기 쉽지 않다면 의도를 잘 담은 네이밍을 해서 변수에 담는 것이 가독성을 훨씬 높여줄 수 있다고 생각합니다.

uk960214 · 2024-03-09T06:18:11Z

+} from '../constant/cons';
+import { RestaurantManager } from '../domain/RestaurantManager';
+
+export const set = {


여기서 set은 무엇을 의미하는 것일까요? index에서 start를 호출하기 위해서 사용하는 것 같은데 어떤 의도로 set이라는 이름이 되었는지 정확히 이해하지 못했습니다. 더구나 파일명은 control이라서 어떤 컨트롤을 어떻게 설정한다는 건지 명확하지 않은 것 같아요.

appControl이라는 명으로 변경했습니다.

uk960214 · 2024-03-09T06:21:20Z

mock data가 함수 사이사이에 포함되어서 어떤 동작을 테스트하는지 한눈에 보기 조금 어려운 부분이 있는 것 같아요!
가독성을 개선하기 위해서 어떤 방법이 있을까요?

mock data를 따로 상수로 선언하여 가독성을 높였습니다.

uk960214 · 2024-03-09T06:25:25Z

+export type Category = '한식' | '중식' | '일식' | '아시안' | '양식' | '기타';
+export type WalkingTime = 5 | 10 | 15 | 20 | 30;
+
+export interface IRestaurant {


interface를 나타내기 위해서 I 프리픽스를 사용한걸까요?
이를 통해서 얻을 수 있는 이점은 무엇이었을까요?

I를 붙인 이유는 인테페이스임 확실히 나타낼 수 있어서 라고 설명을 들었습니다. 그래서 한번 찾아보니 ts공식문서에서는 헝가리안 표기법의 사용을 권고하지 않는 다는군요. 이유는 네이밍 일관성이 떨어지고 타입스크립트는 구조적 타이핑이기에 구조만 일치하다면 연관이 없는 인터페이스나 클래스일지라도 연결이 가능합니다.
제대로 모르고 쓰고 있었네요. 덕분에 I프리픽스가 타입스크립트에서는 권장되지 않는다는 것을 알았습니다.

uk960214 · 2024-03-09T06:28:12Z

+
+
+Co-authored-by: pakxe <pigkill40@naver.com>


감사합니다

uk960214 · 2024-03-11T11:36:03Z

@@ -0,0 +1,9 @@
+export const APP_NAME: string = '점심 뭐 먹지';
+
+export const formIds: string[] = [


이 타입 선언이 없더라도 타입스크립트가 string[]으로 인식할 수 있지 않나요?

넵. 타입스크립트의 타입 추론으로 자동으로 string[]로 타입추론이 됩니다. 다만, 저는 타입스크립트의 타입 추론을 어디까지 믿어야할까 고민입니다. 모든 변수에 타입을 추론한다면 코드의 유연성이 떨어집니다. 하지만 위와 같은 경우에는 타입을 선언하는 것이 더 좋다고 생각합니다. 이유는 타입 선언이 이 배열에 무엇이 들어가야 하는지 바로 알 수 있다는 점입니다. 만약 타입 추론을 사용하면 배열에 5라는 값이 실수로 추가되어도 타입이 string | number 이 되지 에러를 발생하지 않습니다. 그래서 타입 추론을 사용하지 않았습니다.

글쎄요.. 저는 설득되지는 않았습니다.
정확히 말하자면 '타입스크립트의 추론에 어디까지 의존해야할까'가 되겠죠?

지금처럼 자료형에 직접 타입 선언을 해주는 경우는 추론되는 타입보다 더 좁은 타입일 때는 유효하겠지만
(타입이 string으로 추론되지만 'A' | 'B' | 'C'로 좁히고 싶을 때)
정상적으로 추론될 때에도 선언을 해주는 것은 언어의 기능을 제대로 사용하지 못하는 것이 비효율적인 측면이 있다고 생각합니다.

타입 추론에 의존해서 string이던 것이 string | number가 되어서 알아차리지 못한다고 하더라도
이 배열을 사용하는 곳에서 바로 그 오류를 알아차릴 수 있게 되지 않을까요?
데이터를 받아서 사용하는 사용처가 이를 함수의 인자로 사용하든, 다른 값을 만들기 위해서 배열 내장함수를 사용하든,
그 사용처에서 타입을 제대로 설정해두었다면, 이 데이터가 잘못된 타입을 가지고 있음을 바로 알아차리게 되겠죠.

대부분의 경우 사용처에서 그 용도에 맞게 타입을 선언해주는 것이 더 바람직하다고 보는데요,
그렇다면 만약 데이터에도 타입을 선언해둔다면 불필요하게 이중으로 타입을 선언하게 되는 것이지 않을까요?

이 부분에 대해서 조금 더 고민해보시고 의견 알려주세요!

uk960214 · 2024-03-11T11:37:37Z

+    this.restaurants.sort((a, b) => {
+      if (a.name < b.name) return -1;
+      if (a.name > b.name) return 1;
+      return 0;
+    });


요건 중복된 코드인데 지워도 되는 것이겠죠?

넵 지웠습니다.

uk960214 · 2024-03-11T11:39:47Z

+  select.className = className;
+  select.required = required;
+
+  if(!!cover) {


요 변수는 NoneSelected~로 Pascal로 되어있는 이유가 있을까요?

uk960214

피드백 반영해주시느라 수고 많으셨습니다!
그 과정에서 다양한 탐구도 하시고 고민도 하신 것 같아요!
아직 조금 해소되지 않는 궁금증들은 코멘트 남겼습니다.
확인하고 다시 요청 주세요!

uk960214 · 2024-03-11T11:48:19Z

+  const TestData = {
+    addition: {
+      input: {
+        category: '중식' as Category,
+        name: '친친',
+        walkingTime: 5 as WalkingTime,
+      },
+      output: {
+        category: '중식' as Category,
+        name: '친친',
+        walkingTime: 5 as WalkingTime,
+      },
+    },


테스트 파일에서 중요한 것은 테스트인만큼, 테스트가 먼저 나오고 데이터가 나중에 나와도 좋을 것 같아요. 그리고 꼭 describe 내부에 위치하고 있지 않아도 되지 않을까 생각했습니다.

계속해서 단언을 사용해주는 것보다 더 좋은 방법이 있을 것 같아요. 현재 in-, output이 모두 같은 형태다보니 그런 타입을 선언해주고 활용하는 방식이 있지 않을까요?

interface RestaurantData { category: Category, name: string, wakingTime: WalkingTime } interface TestData = { input: RestaurantData output: RestaurantData } const AddTestData: TestData = { input: { category: '중식' name: '친친', walkingTime: 5 }, output: { category: '중식' name: '친친', walkingTime: 5 }, }

넵 수정했습니다. 또한 테스트 데이터의 선언 위치를 cypress/support/e2e.ts 파일안으로 이동했습니다. 주성 내용을 보니 테스트 전에 파일이 로드된다고 해석되어 여기다 선언하였습니다. 하지만 export와 import는 필수였네요. 저는 따로 선언하지 않아도 자동으로 로드될 줄 알았는데 아니였습니다.

uk960214 · 2024-03-11T11:57:02Z

@@ -0,0 +1,43 @@
+import { $ } from '../utils/selector.js';
+
+function createDropDown({ id, callback, options, className, required, cover }) {


dropDown.create와 같이 객체 이름으로 표시되는 것이 이게 무엇에 관련된 함수라는 것을 더 명확히 확인할 수 있어서 선호

그건 함수명을 createDropdown으로 만들어도 충분히 의미를 드러낼 수 있지 않나요?

보통 하나의 파일의 이름과 공개되는 객체의 명이 같기 때문에

이것도 지금의 컨벤션이고 충분히 달라질 수 있는 부분이라고 생각하구요.

함수를 공개하거나 말아야 하는 이유가 1. 사이드 이펙트를 발생시킨다. 2. 많은 선택지로 인해서 혼란스럽다 정도로 생각하신 것 같아요! 근데 분명 더 다양한 이유도 있을 수 있다고 생각합니다.
export 되어있는 함수는 다른 곳에서 사용할 수 있도록 공개해두었다라고 충분히 판단할 수 있는 근거가 되고, 협업하는 동료들이 이 함수를 자의적으로 해석하고 활용할 수도 있죠. 지금 당장은 그것이 문제가 되지 않을 수도 있습니다. 하지만 만약에 해당 로직에 중대한 변화가 생겨서 원 제작자가 로직을 변경했는데, 그 함수에 의존하던 다른 모듈들이 오류를 일으킨다면, 전혀 예상하지 못하게 문제를 일으킬 수도 있겠죠.
그래서 외부에서 사용하지 말아야 할, 이 파일 혹은 모듈에 특화된 매서드/함수들을 어떻게든 명시해서 '사용하지 마시오'를 알리는 것은 중요하다고 생각합니다. 그중 하나의 방법이 아예 사용을 못하게 export 하지 않는 방식이구요.

이런 점들을 고려했을 때 어떤 방식이 좋다고 생각하시나요?

uk960214 · 2024-03-11T12:02:02Z

+
+    try {
+      restaurantManager.add(newRestaurant);
+      set.updateRestaurantList(restaurantManager.getRestaurants());


현재 선택된 정보를 변수로서 기억하지 않고 하는 방법이 있나요?
물론 말씀하신대로 매번 선택의 결과로 저장된 결과를 다르게 만들 수는 있지만,
그렇게 할 때 들어가는 비용과 변수 두 개를 메모리에 들고 있는 비용을 비교했을 때에는
후자가 조금 더 현실적이지 않나 하는 생각입니다. 지금은 데이터가 몇 개 없지만, 수천개, 수만개씩 데이터를 가지고 있는데,
이 정렬 기준에 따라서 매번 다르게 저장하는 것은 어려울 수도 있을 것 같아요.

다만 서버 데이터가 있어서 정렬을 서버에서 하고 있다면 프론트는 매번 요청을 보내서 새로운 목록을 받아오긴 할겁니다.
대신 선택된 정보를 서버로 보내기 위해서 그 때에도 변수를 어딘가에 저장해두고 사용하긴 하겠지만요.

uk960214 · 2024-03-11T12:02:23Z

cypress에서 제공한 다양한 파일/기능들에 대해서 조금 더 공부해봐도 좋을 것 같네요!

uk960214

수고 많으셨습니다 치코! 👏

제가 다양한 부분에서 의견을 많이 드린 것 같은데,
열심히 고민해주시고 의견 제시해주셔서 감사합니다.
이번 단계가 유익했었으면 좋겠네요!
저도 많은 생각을 할 수 있었습니다.

타입스크립트 관련해서 질문을 남겼는데,
다음 단계를 구현하면서 더 고민해서 알려주세요!

그럼 2단계도 기대하고 있겠습니다!!

pakxe and others added 30 commits March 5, 2024 15:21

docs: 기능 목록 작성

182e80b

Co-authored-by: jaeml06 <jaeml0630@gmail.com>

docs: 거리가 같은 경우 이름 오름차순으로 정렬하도록 기능 목록 추가

eeeb87e

Co-authored-by: jaeml06 <jaeml0630@gmail.com>

chore: coworker를 위한 깃메세지 설정

7726648

Co-authored-by: jaeml06 <jaeml0630@gmail.com>

test: 음식점 목록 테스트 작성

195434f

Co-authored-by: jaeml06 <jaeml0630@gmail.com>

feat: IRestaurantManager 클래스 add메소드 구현

69975ba

test: 정상적으로 배열을 비교하지 못하는 오류 수정

bd9bc10

Co-authored-by: Pakxe <pakxe@users.noreply.github.com>

test: 정상적으로 배열을 비교하지 못하는 오류 수정

9023391

Co-authored-by: pakxe <pigkill40@naver.com>

chore: co-worker 수정

8834342

Co-authored-by: pakxe <pigkill40@naver.com>

chore : cypress환경 설정

6b6ea80

Co-authored-by: pakxe <pigkill40@naver.com>

feat: 거리와 이름순으로 정렬하는 로직 구현

70889b7

Co-authored-by: pakxe <pigkill40@naver.com>

feat: 카테고리 이름으로 필터를 적용하여 배열을 반환하는 함수 작성

2779e93

Co-authored-by: pakxe <pigkill40@naver.com>

feat: DropDown 컴포넌트 구현

bb8eec3

Co-authored-by: Pakxe <pakxe@users.noreply.github.com>

refactor: createDropDown.js 이름 변경

1fe8077

feat: button 컴포넌트 구현

58ef6e3

feat: heade컴포넌트 구현

f699393

Co-authored-by: Pakxe <pakxe@users.noreply.github.com>

feat: Modal container 생성 함수 작성

18db306

Co-authored-by: pakxe <pigkill40@naver.com>

feat: reasaueantCard 생성 함수 작성

00fb1c5

Co-Authored-By: pakxe <pigkill40@naver.com>

refacotr: png파일 위치 이동

cf4201b

Co-Authored-By: pakxe <pigkill40@naver.com>

feat: input 컴포넌트 구현

c863944

Co-Authored-By: pakxe <pigkill40@naver.com>

feat: textArea 컴포넌트 구현

2cbae71

Co-Authored-By: pakxe <pigkill40@naver.com>

feat: modal 컴포넌트 구현

1e46823

Co-Authored-By: pakxe <pigkill40@naver.com>

fix: button 컴포넌트 parent 매개 변수 삭제

722eceb

Co-Authored-By: pakxe <pigkill40@naver.com>

chore: prettierc 설정 추가

c209de4

Co-Authored-By: pakxe <pigkill40@naver.com>

feat: labelWrapper 컴포넌트 구현

34c40a6

Co-Authored-By: pakxe <pigkill40@naver.com>

refactor: airbnb 스타일 준수

98c60f3

Co-Authored-By: pakxe <pigkill40@naver.com>

fix: 매개변수 변경

b1286d5

parent 삭제 required 추가 innerHTML에서 createElement로 구현 Co-Authored-By: pakxe <pigkill40@naver.com>

fix: 매개변수 변경

a3a7fe4

parent 삭제 restaurantManager 추가 Co-Authored-By: pakxe <pigkill40@naver.com>

feat: 새로운 가게 생성을 위한 modal form을 구현

b32f0ac

Co-Authored-By: pakxe <pigkill40@naver.com>

fix: index.html 기본 양식 작성

31ea641

Co-Authored-By: pakxe <pigkill40@naver.com>

feat: 필요한 파일 import

5b97f84

Co-Authored-By: pakxe <pigkill40@naver.com>

jaeml06 and others added 6 commits March 8, 2024 15:30

refactor: categoryDiv createRestaurantCard로 대체

cf732c9

Co-Authored-By: pakxe <pigkill40@naver.com>

feat: 같은 이름 가게 생성시 Toast로 에러 출력

1341689

Co-Authored-By: pakxe <pigkill40@naver.com>

fix: script 연결

82025c8

Co-Authored-By: pakxe <pigkill40@naver.com>

refactor: console.log 삭제

8f2543a

Co-Authored-By: pakxe <pigkill40@naver.com>

refactor: console.log 삭제

ca15ab6

Co-Authored-By: pakxe <pigkill40@naver.com>

fix: 바로 추가가 안되는 버그 수정

9601e85

jaeml06 commented Mar 8, 2024

View reviewed changes

chore: 바로가기 링크 추가

458c0d7

jaeml06 commented Mar 8, 2024

View reviewed changes

uk960214 requested changes Mar 9, 2024

View reviewed changes

jaeml06 added 11 commits March 9, 2024 23:20

refactor: 불필요한 주석 메세지 삭제

424b349

refactor: cover 변수명 변셩

1ce0b66

refactor: add 메서드 명 변경

0d6fdaf

refactor: 테스트 케이스 상수로 분리

852d635

refactor: 인터페이스 I 프리픽스 제거

456096e

refactor: control 파일명 변경

13c2f66

refactor: 불필요한 주석 제거

6aae3f1

refactor: 불필요한 주석 제거

0b8e212

test: 테스트 케이스 타입 지정

6024437

fix: 레스토랑 추가시 이전 선택한 카테고리와 정렬이 반영되지 않는 문제 수정

5ab120c

refactor: 불필요한 파일 삭제

7018bcc

uk960214 reviewed Mar 11, 2024

View reviewed changes

uk960214 requested changes Mar 11, 2024

View reviewed changes

jaeml06 added 5 commits March 12, 2024 00:41

refactor: 테스트 데이터 상수 분리

0901713

refactor: 배열 readOnly로 설정

6faa6ed

fix: filteredRestaurants 로직 수정

8d12414

refactor: 카멜 표기법으로 변경

f966cbe

refactor: 불필요한 console.log 제거

d0a7013

uk960214 approved these changes Mar 12, 2024

View reviewed changes

uk960214 merged commit 388f40a into woowacourse:jaeml06 Mar 12, 2024

		@@ -0,0 +1,43 @@
		import { $ } from '../utils/selector.js';

		function createDropDown({ id, callback, options, className, required, cover }) {


		const form = document.createElement('form');

		const categorySelect = createDropDown({

		const selectedOption = dropdown.value; // 선택된 옵션 값
		callback(selectedOption); // 콜백 함수 호출

		@@ -0,0 +1,9 @@
		export const APP_NAME: string = '점심 뭐 먹지';

		export const formIds: string[] = [



		Co-authored-by: pakxe <pigkill40@naver.com> No newline at end of file

Conversation

jaeml06 commented Mar 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaeml06 Mar 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaeml06 Mar 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaeml06 Mar 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

uk960214 left a comment

Choose a reason for hiding this comment

👍 이런 점이 좋았어요

🤔 이런 점은 조금 더 생각해볼까요?

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaeml06 Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaeml06 Mar 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

jaeml06 commented Mar 8, 2024 •

edited

Loading

jaeml06 Mar 9, 2024 •

edited

Loading

jaeml06 Mar 9, 2024 •

edited

Loading

jaeml06 Mar 10, 2024 •

edited

Loading

jaeml06 Mar 11, 2024 •

edited

Loading

jaeml06 Mar 9, 2024 •

edited

Loading

jaeml06 Mar 11, 2024 •

edited

Loading