서버로부터 받은 값을, 다시 서버로 보내기까지 어떻게 값들을 관리하고 처리하시나요?

[with-key]

고민

서버로부터 받은 값을 input에 바인딩하고, 유저의 인터렉션이후로,
다시 서버로 보내기까지 여러분들은 어떻게 처리를 하시나요?

저는 이 "처리"과정에서 3가지의 타입이 존재한다고 생각하는데요.
각각의 값과 타입으로 넘나들기 위해 필요한 처리들을 어디에서 어떻게 하는것이 적절할지 고민이 됩니다.

1. response type (서버로부터 받은 값)

2. form value type (유저가 form에서 입력할 수 있는 값)

3. payload type (서버로 보낼 값)

한가지 간단한 예시로 위 과정을 설명할게요.

[과정1] 서버로부터 어떤 데이터를 받았습니다. 저는 이 응답값의 타입을 아래와 같이 작성했습니다.

type Response = {sum : number; itemCode : "01" | "02"; createdAt: "2020-01-01" };

[과정2] 그리고 이 값중 sum은 text input 컴포넌트, itemCode는 select 컴포넌트에 바인딩이 되며 유저들은 이 값을 수정 할 수 있습니다. 그리고 itemCode 같은 경우는 유저가 입력을 하는 중간에 "선택안함" 이라는 값을 선택할 수 있으므로 null을 타입에 추가했습니다. 이런 상황을 종합하여 아래와 같이 타입을 작성했습니다.

type Form = { sum : string; itemCode : "01" | "02" | null };

[과정3] 마지막으로 유저로부터 받은 값들을 서버로청을 보내기 위해 아래와 같이 paylaod 타입을 작성했습니다. 대부분 이 타입은 백앤드로부터 받은 명세대로 작성을 하고 있죠. 다만 itemCode 같은 경우 서버에서는 null을 허용하고 있지 않네요.

type RequestPayload = {sum : number; itemCode: "01" | "02" };

---

제가 실제로 구현해놓고 나중에 정리하자.. 라고 해놓은 것을 설명하겠습니다.

[과정1]에서 sum은 number타입이였지만, input에서는 해당 값이 string 타입으로 변경되어야 하므로 이 작업을 위해 api 응답을 받은 즉시 ResponseRender 라는 클래스에 주입합니다. Renderer를 거치면 number 타입이였던 sum이 string 타입이 됩니다.

[과정2]에서 itemCode에서 유저가 "선택안함" (null) 을 선택할 수는 있지만, 최종적으로는 반드시 "01" | "02" 중에 하나를 선택해야 하는 기획 의도가 있습니다. 이것을 충족시키기 위해 zod 스키마를 아래와 같이 추가합니다.

z.object({
  sum: z.string(),
  itemCode: z.enum(["01", "02"]),
});

[과정3]에서는 유저의 모든 입력과 그리고 zod를 통한 유효성 검증이 끝났습니다. 이제 서버로 값을 보내려고 하는데 몇가지 처리해야할 것이 있습니다.

1. sum이 ""인 경우 "0"으로 서버로 보내줘야 합니다. ( === 기획자 왈: "유저가 아무것도 입력하지 않으면 "0"을 입력한 것처럼 처리해주세요")
2. 유효성검증을 통해 itemCode가 null이 아님은 확실해지지만, handleSubmit((formValues) => {}); 에서 인자로 받는 formValues의 타입에서는 여전히 itemCode의 타입이 "01" | "02" | null 입니다.

return (
    <button
      onClick={handleSubmit((formValues) => {
        if (formValues.itemCode) {
          mutate({
            sum: formValues.sum || "0",
            itemCode: formValues.itemCode,
          });
        }
      })}
    >
      수정
    </button>
  );

---

고민이 되는 점

1. response type, form value type, payload type은 필연적으로 3개가 모두 따로 존재해야하는 것인가?
2. form values -> payload로 값의 형태, 타입등을 변경하는 것은 어디에서 하는것이 가장 적절한가?

• zod의 transform ? : schema에서 validation 외 다른 작업까지 하는 것은 너무 복잡해지는 것 같다. 그리고 결과적으로 값의 형태는 바꾸지만 form values 의 타입 자체는 form type을 그대로 가지고 와서 결국 마지막 부분 (onSubmit, onClick) 에서 타입 가드가 필요하게 되므로 로직이 파편화 되어 오히려 더 복잡해진다.
• onSubmit(onClick) 내부에서 처리 ? : 많은 타입가드와 값을 변경하는 함수가 난무하게 될텐데, 여기 외엔 어디서 해야할지..막막...하다.

---

위 내용이 현재 고민입니다. 예시는 필드가 2개이지만 실제 코드에서는 필드가 20개가 족히 넘어가다보니 어떤식으로 이 값들을 정리해야할지, 다른 분들은 저와 같은 고민을 하신 적이 없는지 궁금합니다.!

코드

class ResponseRender {
  public sum: number;
  constructor(private readonly response: Response) {
    this.sum = response.sum.toString()
  }
}

참고 자료

No response

[merongmerongmerong]

1, 2, 3은 의외로 FE 개발자가 할 수 있는게 거의 없어요
1, 3은 애초에 서버에서 정해진거고 2는 디자인 의도를 반영해야하니까요 (협업을 하기 때문에 발생하는 문제, 이걸 대화로 풀면 엄청난 팀)

제가 봤을때 고민하시고 있는 부분은 1, 2, 3 각각의 타입의 문제를 떠나서
이 서로 다른 타입에 어떻게 기획 의도(벨리데이션, 디폴트값)를 잘 끼워넣을지가 고민인걸로 보입니다
표현해야하는 기획 의도는 이제 온전히 FE 개발자가 제어하는 부분인데 1, 2, 3이 고정되어 있으니까 움직임에 제약이 생기는거죠

저라면 별도의 레이어를 만들고 거기 안에서 제약 없이 비즈니스 로직을 표현할 것 같습니다
대신 이 레이어에 들어오고 나갈때만 타입을 신경써서 맞춰줄거에요
이 레이어의 표현은 커스텀 훅이 됐건 객체지향이 됐건 본인과 팀이 선호하는 방식을 쓸 수 있어요 (보통은 훅이 국룰이긴 하지만..)
(생각해보면 이 표현은 굉장히 다양해요 예를들어 next의 서버액션이나 고전적인 MVC 모델에선 이걸 FormData로도 받아요, 예전에 저는 Redux Saga로 해본 기억이 있네요)

아무튼 이 기획 의도를 잘 발라내고 캡슐화해서 만든 다음
컴포넌트에 연결고리를 만들면 그나마 깔끔하게 관리할 수 있을거에요 1, 2, 3에서 해결이 안된다면 2.5를 만들어서 해결하는거죠

""을 0으로 바꾸는걸 기획 의도로 본다면 비즈니스 레이어에서 처리할 수 있고
그게 아니라 단순한 변환이라 생각하시면 호출할때 캐스팅 해도 문제 없지요

벨리데이션 로직을 비즈니스 레이어에 진입해서 전부 해결한 뒤 서버 호출을 해도 되고
아니면 따로 임포트해서 form의 표현에 덧대서 사용해도 좋아요 (글의 내용처럼 zod 스키마의 형태로 만들고 hook-form 같은 라이브러리에 연동)

통제할 수 없는 부분과 있는 부분을 잘 분리하면 의외로 쉽게 풀릴것이라 생각합니다
결과적으로 같은 양의 코드를 만들더라도 잘 분리해놓으면 나중에 바꿔야할때 덜 괴로운것도 있구요

+이 접근은 반대로 로직대신 UI가 복잡해져도 유용할거에요
예를 들어 폼을 여러 스탭에 나눠서 받는다면 로직은 자연스럽게 컴포넌트가 아닌 별도의 어딘가로 모여드는 것 처럼요

[chkim116]

말씀해주신 고민은 서버로부터 값을 받고 -> 유저가 그 값을 변형하고 -> 다시 서버로 보내는 Data Lifecycle 진행 시 변형되는 값의 형태를 어떻게 처리할지에 대한 내용인 것 같습니다. 공감 가는 지점이 많은 고민 같아요!

제 의견을 말씀드려보자면,

1. response type, form value type, payload type은 필연적으로 3개가 모두 따로 존재해야하는 것인가?
   필연적이라고 생각해요. response type와 payload type는 서버로부터 파생되기 때문에 있을 수 밖에 없고, form value type 역시 UI에 필요한 값이기 때문에 존재해야해서요.

2. form values -> payload로 값의 형태, 타입등을 변경하는 것은 어디에서 하는것이 가장 적절한가?
   저는 개인적으로 결합도를 낮추기 위해, 중간에 포함시키기보다 추상 레이어를 하나 추가하는 방법을 선호해요. 이 추상 레이어에 서버 데이터를 UI에 맞춰 변형하고 UI 데이터를 서버 데이터에 맞춰 변형하는 작업을 위임합니다.

현재 Data Lifecycle이 이렇다면

추상 레이어를 넣으면 이렇게 변할거예요.

코드로 정말 러프하게 예를 들면 이렇게 돼요.

// 추상 레이어

async function formValueTypeToResponseType(response: FormValueType): ResponseType {
   //
}

// 실제 UI 사용처

<button
  onClick={handleSubmit((formValues) => {
    if (formValues.itemCode) {
      mutate(formValueTypeToResponseType(formValues));
    }
  })}
>
  수정
</button>

하지만 이 방법은 레이어가 하나 더 들어가기 때문에 복잡성을 증가시키는 단점이 있어요. 무엇이 가장 적절한지는 각자 처한 상황에 맞게 판단하는 게 맞다고 생각해요.

번외) zod의 transform ?
zod는 유효성검사까지만 받는게 맞지 않을까란 생각이에요. 책임을 하나씩 관리하기 문서에도 나오듯 추후 유지보수가 어려워질 수 있을거 같아요.

[jangwonyoon]

@with-key

이런 고민, 정말 많이 공감돼요 😵‍💫. 특히 Response, Form, Payload처럼 각 단계의 타입이 달라지면 필드가 많을수록 복잡해지기 쉽죠. 저도 비슷한 상황에서 '어디서 변환을 해야 가장 깔끔할까?'를 고민한 적이 있어요. 결국 이런 문제는 한 번 구조를 잘 잡아두면 이후 유지보수나 확장이 훨씬 편해지더라고요.

"저는 이런 상황에서 세 가지 방법을 고민해본 적이 있는데요, 이런 식으로 접근해보면 어떨까 싶어요:"

1. onSubmit 내부에서 바로 처리하는 방식

• 가장 직관적인 방법이에요.
• 데이터를 최종적으로 서버에 보내기 전에 필요한 변환을 한 번에 처리하는 거죠.
• 다만, 변환 로직이 길어지면 onSubmit 함수가 복잡해질 수 있다는 단점이 있어요.

const onSubmit = (formValues: Form) => {
  const payload: RequestPayload = {
    sum: parseInt(formValues.sum || "0", 10),
    itemCode: formValues.itemCode as "01" | "02",
  };
  mutate(payload);
};

2. 전용 변환 함수를 만드는 방식

• 변환 로직을 별도로 분리해서 가독성과 재사용성을 높이는 방법이에요.
• 이러면 onSubmit은 간단해지고, 변환 로직이 여러 곳에서 재사용될 때 특히 유용하더라고요.

const transformToPayload = (formValues: Form): RequestPayload => ({
  sum: parseInt(formValues.sum || "0", 10),
  itemCode: formValues.itemCode as "01" | "02",
});

const onSubmit = (formValues: Form) => {
  mutate(transformToPayload(formValues));
};

3. Zod의 transform 활용

• 유효성 검증과 변환을 한 번에 처리하는 방법이에요.
• Zod의 transform 기능을 사용하면 스키마 단계에서 데이터를 변환할 수 있어서 깔끔하지만, 복잡한 변환 로직이 필요할 땐 다소 가독성이 떨어질 수 있더라고요.

const schema = z.object({
  sum: z.string().transform((val) => parseInt(val || "0", 10)),
  itemCode: z.enum(["01", "02"]),
});

const onSubmit = (formValues: z.infer<typeof schema>) => {
  mutate(formValues); // 이미 변환된 값 사용
};

저 같은 경우엔 zod의 tranform은 가벼운 데이터 변환에만 사용하고, 복잡한 변환은 전용 변환 함수로 분리하는데, 즉 데이터 핸들링 레이어를 따로 만드는 방식을 선호하는 편이에요. 물론 상황에 따라 Zod를 활용하거나 onSubmit에서 바로 처리하기도 했어요.

결국. 중요한 건 변환 로직을 어디서 처리하느냐를 명확히 정의하고, 한 곳에 집중시켜 복잡도를 줄이는 거라고 생각해요. 이 점만 잘 잡으면 어느 방법을 택해도 큰 무리는 없을 것 같아요. 😊