Open feldblume5263 opened 5 months ago
구조 확인했습니다 ! 한가지 고민되는 점은
실제 사용되는 데이터는 MealPlanResultDTO 부터지만 Json 파일이 firestore 의 구조를 만족시키기 위해서 result 가 들어가게 되는 점인데, result 보다 좋은 네이밍이 있을까요 ..??
이게 변경되면 MealPlanResultDTO 도 기존 MealPlanDTO 로 변경하는 편이 나아보입니다 ..!
구조 확인했습니다 ! 한가지 고민되는 점은
실제 사용되는 데이터는 MealPlanResultDTO 부터지만 Json 파일이 firestore 의 구조를 만족시키기 위해서 result 가 들어가게 되는 점인데, result 보다 좋은 네이밍이 있을까요 ..??
이게 변경되면 MealPlanResultDTO 도 기존 MealPlanDTO 로 변경하는 편이 나아보입니다 ..!
앗 result -> results로 수정했습니다. 이 부분 확인 부탁드립니다.
그러게요.. 이 부분이 좋은 코드처럼 보이지 않아서 고민이 되네용...
앗 result 가 더 나은 표현이지 않을까요 ?
각각의 result가 하나의 MealPlanResultDTO 를 갖는것처럼 보여서요 !
그러게요.. 이 부분이 좋은 코드처럼 보이지 않아서 고민이 되네용...
이 부분은 같이 고민해보시죠
앗 result 가 더 나은 표현이지 않을까요 ?
각각의 result가 하나의 MealPlanResultDTO 를 갖는것처럼 보여서요 !
주셨던 서버 스펙에서 results로 내려오고 있어서 results로 적었습니다.....ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
각각의 result가 내려오고 있나요? 제가 이 부분은 확인을 다시 해보겠습니다
아하 이전에 그랬나보네요 .. 이 부분은 일단 result로 업데이트 해두겠습니다 !
확인 해봤는데, 다음과 같은 형태로 내려오고 있습니다!! result는 그냥 [MealPlan] 을 감싸는 형태로 내려오고 있는 것 같습니다
struct MealPlanDTO: Codable {
let results: [MealPlanResultDTO]
}
새로운 DTO에서는 result 로 변경하겠습니다 !
새로운 DTO에서는 result 로 변경하겠습니다 !
앗 배열로 내려온다는 지점에 주목하셔야 할 것 같습니다!!!
result 가 하나의 MealPlanDTO가 되고 있고, 현재 전체 데이터 구조는 MealPlansDTO 가 되버린 것 같습니다...
아아 이해 했습니다 !! results가 맞네요 😓
네이밍 좀 더 고민해보겠습니다 !
아아 이해 �했습니다 !! results가 맞네요 😓
네이밍 좀 더 고민해보겠습니다 !
네 이 구조에 맞춰서 클라이언트도 변경하겠습니다!