[2단계 - 자주 가는 음식점] 헤일리(유소정) 미션 제출합니다. by kaori-killer · Pull Request #233 · woowacourse/javascript-lunch

kaori-killer · 2025-03-15T03:39:02Z

안녕하세요, 유조~!
주말 잘 보내고 계신가요? 😄

이번 미션에서는 STEP 1에서 만든 컴포넌트를 재활용하면서,
컴포넌트를 효율적으로 설계하는 것이 얼마나 중요한지 새삼 느꼈어요!
다만, 상태 관리와 E2E 테스트는 여전히 쉽지 않아서 고민이 많았네요. 😭

이번 미션도 잘 부탁드려요! 🙌✨

학습 목표

이번 미션을 통해 다음과 같은 학습 경험들을 쌓는 것을 목표로 합니다.

UI와 도메인 영역을 분리할 수 있는 설계를 고민해보고, 목적에 맞게 객체와 함수를 활용
TDD 방식으로 개발하며, 단위 테스트 기반으로 점진적인 리팩터링

제출 전 체크 리스트

기능 요구 사항을 모두 구현했고, 정상적으로 동작하는지 확인했나요?
기본적인 프로그래밍 요구 사항을 준수하고 있는지 확인했나요?
테스트 코드는 모두 정상적으로 실행되나요?
(해당하는 경우) 배포한 데모 페이지에 정상적으로 접근할 수 있나요?
- 배포한 링크 기입: https://kaori-killer.github.io/javascript-lunch/

리뷰 요청 & 논의하고 싶은 내용

1) 이번 단계에서 가장 많이 고민했던 문제와 해결 과정에서 배운 점

📌 컴포넌트 리렌더링 최적화

기존 방식의 문제점
- 처음에는 특정 조건에서 리렌더링이 필요할 때, 아래와 같이 body 전체를 초기화하는 방식을 사용했어요.

export default function reset() {
  document.querySelector("body").innerHTML = "";
}

하지만 사실 전체 화면을 다시 그릴 필요 없이 음식점 목록만 갱신하면 되는 상황이었어요.
그런데 Restaurant.js를 보면 **헤더(Header)와 음식점 리스트(RestaurantListContainer)**가 하나로 묶여 있어서 리스트만 따로 갱신하기가 쉽지 않았어요.

개선한 방법
이 문제를 해결하기 위해, 특정 조건을 받아서 음식점 목록 부분만 업데이트하는 방식으로 개선했어요.

export default function Restaurant({ isReRender }) {
  ...
  if (isReRender) {
    reRenderRestaurantListContainer($body, $restaurantListContainer);
  }
  ...
}

📌 타입스크립트 & E2E 테스트

아직 타입스크립트와 E2E 테스트가 익숙하지 않아서 부족한 점이 많을 것 같아요..! 😭
특히, E2E 테스트를 UI 단위 테스트가 아니라 사용자 시나리오 중심으로 작성하는 방법이 감이 잘 오지 않네요.

타입스크립트도 도메인 영역에 최대한 적용하려고 노력했는데,
이 방식이 적절한지 확신이 없어요. 🤔

혹시 코드 보시고 작은 피드백이라도 주시면 바로 반영하겠습니다! 💪

2) 이번 리뷰를 통해 논의하고 싶은 부분

🎯 UI와 Domain을 효과적으로 분리하는 방법

현재 상태를 컴포넌트와 완전히 분리하여 별도의 파일에서 전역으로 관리하고 있어요. 하지만 이렇게 하면 관심사가 ‘분리’된 것이 아니라 오히려 ‘파편화’된 느낌이 들더라고요. 상태가 필요할 때마다 여기저기에서 가져다 쓰면서 관리가 어려워지고 있어요. 🤯

그러다 보니 "그럼 상태를 컴포넌트 내부에서만 관리하도록 클래스로 만들면 어떨까?" 라는 고민도 했어요. 하지만 그렇게 하면 UI와 Domain이 분리되지 않는 문제가 발생하더라고요. 😢

현재 가장 큰 고민은:

UI와 상태 관리(Domain)를 어떻게 적절히 분리할지
클래스 컴포넌트를 언제 사용하면 좋을지
Domain 코드가 너무 복잡해지고 있는 문제를 어떻게 해결할지

이 부분에 대해 조언을 주시면 정말 감사하겠습니다! 🙌

🎯 공통 코드 정리 - 유틸리티 함수 분리

자주 사용하는 함수들을 유틸리티 함수로 정리해 더 효율적으로 관리할 수 있도록 했어요!
특히, 재사용 가능한 컴포넌트의 유틸리티 함수와 일반적인 유틸리티 함수를 명확히 구분하기 위해 📂 src/components/util 과 📂 src/utils로 나누어 관리했습니다.

하지만, 이 구분이 완벽하게 적용된 건지 고민이 되네요. 🤔
혹시 컴포넌트 관련 함수가 일반 유틸 폴더에 들어가 있거나, 반대로 일반 유틸 함수가 컴포넌트 폴더에 포함된 건 아닐까? 하는 의문이 들어요.

이렇게 나누는 게 적절할지, 혹은 더 좋은 방식이 있을지 고민 중입니다. 유조의 의견이 궁금해요!

✅ 리뷰어 체크 포인트

1단계

UI를 컴포넌트 단위로 분리했는가?
재사용 가능한 컴포넌트를 고려했는가?
주요 기능 시나리오에 대한 E2E 테스트를 작성했는가?

2단계

오류 상황(예: 잘못된 입력)에 대해서도 테스트 케이스를 정의했는가?
타입 정의를 적절히 사용하여 컴파일 오류 없이 안정적으로 동작하는가?
로컬/배포 환경에서 테스트가 정상적으로 동작하는지 확인했는가?

yujo11

안녕하세요 헤일리 ~ 다시 만나서 반갑습니다 ㅎㅎ

📌 컴포넌트 리렌더링 최적화

이 부분은 지난 step 리뷰하면서 개선되었으면 좋겠다고 생각한 부분인데 스스로 해결방법을 찾아서 해결해주셨군요. 멋집니다 헤일리 👍 👍 👍

🎯 UI와 Domain을 효과적으로 분리하는 방법

UI와 상태 관리(Domain)를 어떻게 적절히 분리할지

도메인 로직과 UI 컴포넌트가 분리되어 있지만 헤일리가 말씀해주신 것과 같은 문제들(관심사 파편화, 전역 상태 관리)과 같은 문제로 전체 코드를 파악하기가 조금 어렵게 느껴졌어요. 이런 문제들은 요구사항이 추가되고 도메인이 복잡해질수록 점점 더 커져 유지보수하기 어려운 형태로 변하게 될 가능성들이 있다고 느껴졌습니다. 여기에 추가로 다음 질문으로 주신 유틸리티 함수 부분에서도 유틸 함수이지만 도메인에 의존하거나 UI와 관련되어 있는 유틸 함수들이 많아 보였어요.

UI와 도메인 로직을 분리하고 싶어 하시는 것 같은데요. 그렇게 분리하는 경우에는 이벤트 버스 패턴 같은 것을 통해서 분리를 하는 방법도 가능할 것 같습니다.그러나 현재 단계에서 이 정도의 복잡도가 필요하다고는 생각되지 않는데요. 대신에 컴포넌트 패턴을 통해서 각각의 컴포넌트에서 필요한 상태들을 각각의 컴포넌트가 관리하도록 하는 것도 또 하나의 방법이 될 수 있을 것 같아요. 두 방법 외에도 다른 방법들도 있을텐데요. 어떤 방법을 사용하시던 간에 전체적인 아키텍처를 바꿔야 하는 작업이 되는 만큼 시간이 오래 걸리고 구현 과정에서 여러 어려움을 겪을 수 있는데요. 한 번에 진행이 어려우시다면 언제든지 리팩터링 과정에서 중간중간 PR을 생성해주시거나 아니면 따로 여쭤봐 주셔도 좋을 것 같아요.

클래스 컴포넌트를 언제 사용하면 좋을지

이건 어떤 정답이 있는 부분은 아니라고 생각을 하는데요. 지금 헤일리가 구현해주신 것과 같은 도메인과 관련된 모델을 정의하거나 제가 위에서 말씀드린 컴포넌트 패턴으로 UI 컴포넌트를 구현하는 경우에 기본적인 Component의 형태를 class로 정의하고 extends 하면서 사용하면 캡슐화가 가능하고, class를 통해 특정 메서드의 구현을 강제하는 등의 역할을 할 수 있어 class가 유리할거 같아요.

그럼 언제 함수를 사용하는 게 더 나을지도 생각을 해보면 좋을 것 같은데요. 함수의 경우에는 어떤 상태를 알고 있을 필요가 없는 경우, 간단한 이벤트를 핸들링 하는 경우. 아니면 단순히 한번 호출되어서 어떤 UI를 그리는 경우에는 클래스로 굳이 구현을 할 필요가 없겠죠.

Domain 코드가 너무 복잡해지고 있는 문제를 어떻게 해결할지

이 부분은 위에 UI와 상태관리를 어떻게 적절히 분리할지에 관한 질문에 답변을 드린 내용도 참고하시면 좋을 것 같은데요. 추가로 현재 도메인이라고 불리고 있는 클래스들에서 데이터 구조를 정의하고 유효성 검사를 진행하고 그와 관련된 서비스 로직들도 처리하고 로컬스토리지(저장소)에 접근을 하는 부분들도 모두 들어있는데요. 이런 부분들을 각각의 역할로 보고 하나의 클래스에서 관리되는 게 아니라 레이어를 나눠서 관리해준다면 복잡도가 내려갈 수 있을거 같아요

🎯 공통 코드 정리 - 유틸리티 함수 분리

이 부분은 코드 리뷰 과정에서 코멘트를 남겼는데요. 해당 코멘트들을 참고해주시면 좋을거 같아요! 이 부분은 위 질문에 남겼던 답변들대로 리팩터링이 진행된다면 자연스럽게 어느 정도 해소 되는 부분도 존재할거 같네요!

리뷰를 남기다보니 코멘트가 많아지고 답변이 조금 길어졌는데요. 확인해 보시고 잘 이해가 되지 않는 부분이나 추가적으로 궁금한 부분들이 있다면 언제든지 편하게 말씀해 주세요. step2 진행하느라 고생 많으셨습니다 헤일리 ~~ 👍 👍 👍

yujo11 · 2025-03-15T13:27:35Z

cypress/e2e/restaurantFormModal.cy.js

 import ERROR_MESSAGE from "../../src/constants/errorMessage";

-describe("음식점 추가 E2E 테스트", () => {
+describe("유저가 음식점을 추가하고, 추가한 음식점을 목록에서 확인할 수 있어야 한다.", () => {


👍 👍 👍

yujo11 · 2025-03-15T13:28:02Z

cypress/e2e/restaurantWishList.cy.js

+describe("음식점 관리 기능 테스트", () => {
+    beforeEach(() => {
+      cy.visit("http://localhost:5173");
+      cy.viewport(1280, 720);
+    });
+
+    describe("음식점 목록이 정상적으로 렌더링 되는 경우", () => {
+      it("음식점 목록을 확인할 수 있다.", () => {
+        cy.get(".restaurant").should("have.length.at.least", 1);
+      });
+    });
+
+    describe("음식점 상세 정보 모달을 여는 경우", () => {


context를 잘 나눠 주셨네요 👍 👍 👍 💯 💯

yujo11 · 2025-03-15T13:28:51Z

src/components/RestaurantItemDetail/RestaurantItemDetailModal.js

+    $fragment.appendChild(RestaurantItemDetailModalButtonContainer({restaurantId}));
+
+    return $fragment;
+}


코드 포맷터가 잘 동작하고 있는지 한번 점검해보셔도 좋을거 같네요

VSC에 Prettier 설정이 안되어 있었네요 😅
수정했습니다!

c54b7d2

yujo11 · 2025-03-15T13:32:28Z

src/domain/RestaurantData.ts

TypeScript를 사용한 파일과 그렇지 않은 파일들이 있는데 사용 기준이 있었나요?

요구사항 중에 도메인 영역을 TypeScript으로 변환한다. (UI 영역은 선택)라고 되어 있었는데요!
TypeScript가 익숙하지 않아서 도메인 영역만 바꿨습니다. (상태, 유효성 검사)

yujo11 · 2025-03-15T13:33:49Z

src/domain/RestaurantData.ts

+    this.validateDistance(distance);
+    this.validateName(name);
+
+    this.id = id || crypto.randomUUID();


여긴 default parameter를 사용하지 않은 이유가 있을까요?

기존에 등록된 음식점이라면 기존 id를 그대로 유지해야 하고,
새로운 음식점이라면 id가 없으므로 새롭게 생성해야 합니다!

그래서 이를 처리하기 위해 default parameter를 사용하지 않고,
다음과 같이 || 연산자를 활용했습니다 😄

더 개선할 방법이 있을까요?

지금도 충분해보입니다 ㅎㅎ 👍

yujo11 · 2025-03-15T14:04:58Z

src/util/createTabButton.js

+export default function createTabButton({className, text, isWishTab}) {
+    const $tab = createElement({
+        tag: "button",
+        classNames: ["restaurant-tab", className],


여기도 위와 같은 맥락으로 도메인에 대한 내용을 이 함수가 알고 있어 util로 불리는게 어색하게 느껴지네요

새로운 element를 만드는 코드로 보이는데 이 친구는 Component로 만들지 않은 이유가 있을까요?

컴포넌트인데 네이밍을 잘못 지으면서 유틸로 착각했네요 😅
이 부분은 TabButton 컴포넌트로 수정하고 componets/util로 넣었어요.

추가적인 질문이 있습니다!
이 컴포넌트가 도메인에 대해 알고 있다는 것은 해당 컴포넌트가 도메인(상태)를 인자로 받기 때문인가요? 그럼 반복해서 사용하는 컴포넌트지만 유틸로 분리하기 어려울까요?

네네 맞습니다 ㅎㅎ

그럼 반복해서 사용하는 컴포넌트지만 유틸로 분리하기 어려울까요?

반복해서 사용하는 로직 자체는 추상화가 가능하지만 util 함수로 불리는 것이 조금 어색하게 느껴졌습니다

yujo11 · 2025-03-15T14:06:16Z

src/util/filterRestaurantDataList.js

+    const category = selectedFilterValue.getSelectedFilterCategoryValue();
+    const sorting = selectedFilterValue.getSelectedFilterSortingValue();
+    return dataList.filter((data) => 
+      category === "전체" || data.category === category


상수로 만들어서 관리해보셔도 좋을거 같네요

수정했습니다!

0f7c843

yujo11 · 2025-03-15T14:08:42Z

src/util/filterRestaurantDataList.js

+      dataList.sort((a, b) => {
+        if (a.distance > b.distance) return 1;
+        if (a.distance < b.distance) return -1;
+        return 0;
+      });


아래처럼 구현해도 같은 결과가 나올거 같네용

Suggested change

dataList.sort((a, b) => {

if (a.distance > b.distance) return 1;

if (a.distance < b.distance) return -1;

return 0;

});

dataList.sort((a, b) => a.distance - b.distance);

yujo11 · 2025-03-15T14:09:12Z

src/util/filterRestaurantDataList.js

+  }
+
+  function filterByStar(dataList) {
+    return dataList.filter((data) => data.isWish === true) || [];    


|| [] 은 어떤 상황을 대비하기 위해 들어간 코드일까요?

앗! 아무 값도 일치하지 않으면 []를 반환하기 때문에 해당 구문이 필요가 없네요!
수정했습니다 :)

yujo11 · 2025-03-15T14:23:14Z

cypress/e2e/restaurantWishList.cy.js

+    });
+
+    describe("음식점 즐겨찾기(★) 기능을 테스트하는 경우", () => {
+      it("음식점 목록에서 즐겨찾기 버튼 클릭 시 추가 및 삭제 가능", () => {


추가/삭제가 별도의 테스트로 작성되어 있어도 좋을거 같네요

반영했습니다!

5c4a72b

kaori-killer · 2025-03-23T16:24:34Z

안녕하세요 유조~ 요청이 늦었는데 기다려주셔서 감사합니다!

아래 두 작업은 시간이 오래 걸릴 듯 싶어서 이것들을 제외하고 요청드립니다 !!

함수형 컴포넌트를 클래스로 바꿔보는 작업
전역 상태를 없애는 작업

yujo11

코멘트를 꼼꼼하게 확인하고 반영해주셨군요 고생 많으셨습니다 헤일리 !!

헤일리가 남겨주신 질문들에 대한 답변들도 남겼으니 같이 확인해보시면 좋을거 같아요!

전역 상태를 제거하는 작업이나 Class로 전환하는 작업은 다음 미션에서 신경 써서 진행해보시면 좋을거 같습니다!

이 코드베이스에서 위 작업들을 해보고 싶고, 추가로 리뷰 받고 싶으시다면 언제든지 편하게 말씀해주세요~

고생 많으셨습니다 헤일리 ~~ 👍 👍 👍

yujo11 · 2025-03-24T03:03:37Z

src/constants/restaurants.ts

+  },
+];
+
+export default restaurants;


여기는 여전히 EOL이 발생하네요 .ts 파일들에서도 코드 포맷터가 잘 동작하는지 확인해봐도 좋겠네요!

yujo11 · 2025-03-24T03:03:49Z

src/domain/RestaurantDataList.ts

 import RestaurantData from "./RestaurantData.ts";
+import restaurants from "../constants/restaurants.js";
+
+const LOCAL_STORAGE_KEY = "dataList";


👍 👍 👍

yujo11 · 2025-03-24T03:04:00Z

src/domain/RestaurantDataList.ts

  }

-  createData(data: Restaurant): RestaurantData {
+  #createData(data: RestaurantDTO): RestaurantData {


👍 👍 👍

yujo11 · 2025-03-24T03:05:15Z

src/domain/SelectedFilterValue.ts

    updateSelectedFilterValue(id: string, value: string | boolean): void {
-        if (id === "category-filter") {
-            this.#category = value as string;
+        if (id === "category-filter" && typeof value === "string") {


👍 👍 👍

kaori-killer added 30 commits March 10, 2025 13:43

test: 명제를 명확히 하고 각 상황을 Context로 나눠서 부여

ed49423

test: 버튼에 대한 클래스 이름 변경

63abb15

feat: 카테고리별로 필터링를 볼 수 있다

22de1e6

refactor: feat: 옵션에 대한 컴포넌트를 함수로 분리

304c1dc

refactor: 음식점 모달 내에 있는 함수 이름에 form 추가

cd14037

refactor: 전체 화면을 리렌더링 하지 않고 음식점 리스트만 리렌더링하도록 수정

6c67ac4

feat: 음식 종류 필터 값에 따라서 볼 수 있는 음식 리스트가 변환되는 기능

ad459f1

refactor: 모달 닫는 부분 유틸 함수로 분리

65e765c

chore: 더미 데이터 값 수정

6abd451

fix: 모달에 있는 Select의 값이 수정됐을 때는 음식점 리스트를 리렌더링 하지 않도록 수정

e411b51

refactor: 메인 필터 컨테이너는 인자 값을 갖지 않도록 수정

86c1278

feat: 모달에서 정상적으로 음식을 만들면 모달을 닫음

84de749

fix: 음식점 리스트의 필터 Select만 필터 값을 변경하도록 수정

c7cbf5d

feat: 필터 값에 따라서 보여주는 음식점 리스트 변경

f538569

refactor: 음식점 리스트 다시 렌더링하는 부분 유틸 함수로 분리

56cd63f

fix: 음식점의 거리는 문자열에서 숫자로 변경

aebf439

feat: 음식점 목록에서 자주 가는 음식점을 추가

858e37d

feat: 자주 가는 음식점 탭에서 추가한 음식점 목록을 확인

db67a62

feat: 음식점 목록에서 음식점 하나를 선택하면 모달창이 띄워짐

6db1aef

feat: 음식점 상세 모달 추가

748c712

fix: 모달에서 위시리스트 표시를 할 때는 리렌더링 하지 않음

7dfe20f

feat: 음식점 상세보기에서 링크가 보임

3592ff9

feat: 상세보기에서 음식점을 삭제

e0f4442

feat: 모든 음식점, 자주 가는 음식점 부분을 클릭하면 색깔이 바뀜

feb450a

feat: 메인 페이지가 렌더링 될 때 선택된 음식점 필터에 하이라이트가 가게 함

e502c9f

feat: 새로고침해도 추가한 정보들이 유지

1310c25

feat: 도메인 영역을 타입스크립트로 변환

ea55cc9

fix: 거리를 문자열에서 숫자로 타입 변경

dd15214

feat: e2e 테스트 추가

d97385f

fix: 거리를 문자열에서 숫자로 타입 변경

828e885

chore: 카테고리 필터 기본 값을 한식에서 전체로 변경

d6e43fe

kaori-killer marked this pull request as ready for review March 15, 2025 12:23

kaori-killer changed the base branch from main to kaori-killer March 15, 2025 12:24

yujo11 self-requested a review March 15, 2025 13:26

yujo11 self-assigned this Mar 15, 2025

yujo11 requested changes Mar 15, 2025

View reviewed changes

kaori-killer and others added 20 commits March 17, 2025 13:52

chore: Lint 오류 해결

1d92600

chore: Lint 오류 해결

c54b7d2

chore: Lint 오류 해결

78004eb

chore: ERROR_MASSAGE -> ERROR_MESSAGE로 오타 수정

2daca06

refactor: 도메인과 관련 없는 유효성 검사 부분 validation 파일로 분리

adf5b01

refactor: 내부에서만 사용되는 메서드들은 private 접근자 사용

687742d

refactor: 내부에서만 사용되는 메서드들은 private 접근자 사용

a288d31

fix: option 값으로 0이 들어오는 경우에 false가 아닌 true가 반환되도록 수정

9f0869d

fix: isValidation 함수명에 맞게 유효성 검사를 통과하면 true를 아니면 false를 반환하도록 수정

b8ddf55

refactor: 더미 데이터는 별도의 파일로 분리

eaacaa5

fix: LocalStorage에 데이터가 없을 때 더미데이터를 불러오도록 함

ee89501

storage에 접근하는 key 상수화

2d1f34a

refactor: 음식점 데이터 타입에 대한 네임을 구체적으로 변경

e873adc

refactor: 음식점 데이터 타입에 대한 네임을 구체적으로 변경

8b90199

refactor: as 대신 다른 구문으로 타입 검사

2189ca2

refactor: 모달 닫기 유틸 함수의 위치 이동

9f244de

refactor: 유틸 함수 위치 이동

e5f8213

refactor: 필터 값 상수로 분리

0f7c843

refactor: 거리 기준 정렬 함수 간소화

df40634

refactor: 추가/삭제가 별도의 테스트로 작성

5c4a72b

refactor: RestaurantDTO로 타입변경

31ad7e6

yujo11 approved these changes Mar 24, 2025

View reviewed changes

yujo11 merged commit 95a83db into woowacourse:kaori-killer Mar 24, 2025

Conversation

kaori-killer commented Mar 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

학습 목표

제출 전 체크 리스트

리뷰 요청 & 논의하고 싶은 내용

1) 이번 단계에서 가장 많이 고민했던 문제와 해결 과정에서 배운 점

📌 컴포넌트 리렌더링 최적화

📌 타입스크립트 & E2E 테스트

2) 이번 리뷰를 통해 논의하고 싶은 부분

🎯 UI와 Domain을 효과적으로 분리하는 방법

🎯 공통 코드 정리 - 유틸리티 함수 분리

1단계

2단계

Uh oh!

yujo11 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!

kaori-killer Mar 17, 2025 • 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!

kaori-killer Mar 17, 2025 • 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!

kaori-killer Mar 23, 2025 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kaori-killer commented Mar 23, 2025

Uh oh!

yujo11 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!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

kaori-killer commented Mar 15, 2025 •

edited

Loading

kaori-killer Mar 17, 2025 •

edited

Loading

kaori-killer Mar 17, 2025 •

edited

Loading

kaori-killer Mar 23, 2025 •

edited

Loading