cloneElement를 쓰지 못한 이유

공통 컴포넌트를 만들다 보면 자주 겪게 되는 흐름이 있다.
처음에는 잘 작동하는 것처럼 보이지만, 시간이 지남에 따라 예측하지 못했던 기획 요구가 추가되고, 다양한 환경에서 재사용되면서 props는 점점 늘어나고 내부 로직도 함께 복잡해지는 경우가 많다. 그래서 향후 어떤 조건이 더해질지는 예측할 수 없지만, 최소한 초기 설계 단계에서는 내부에서 모든 정책을 처리하는 방향으로 구현하고 싶은 마음이 늘 있다.

 

물론 공통화가 언제나 정답이라고 생각하지는 않는다. 급한 일정 속에서 개발하거나 기획이 1차, 2차로 나눠지는 경우에는 섣부른 공통화보다는 최대한 잘 읽히는 코드를 우선으로 개발한 뒤, 나중에 혼자 리팩토링하는 식으로 접근했다. 

 

이번에 개발한 기능은 입력창 옆에 버튼을 붙이고, 버튼 클릭 시 텍스트 인식 결과를 입력 필드에 반영하는 OCR 기능이었는데, 공통화해야 할 부분이 명확하고 작았기에 처음부터 최대한 내부에서 모든 정책을 감싸는 공통 컴포넌트로 구현해보고자 했다.

 

기능 자체는 단순해 보일 수 있지만 다음과 같은 조건들을 함께 만족해야 했다.

• 버튼은 입력 필드에 포커스 되었을 때만 노출되어야 함
• 클릭 시 팝오버 형태의 UI가 표시되고, 그 안에는 정책 조건에 따라 달라지는 세부 로직이 존재함
• 버튼 클릭 결과는 외부로 콜백 형태로 전달되어야 함
• 마침표, 줄 바꿈 등의 기호를 삽입할 수 있는 입력 보조 버튼 패널이 함께 동작해야 함

cloneElement 활용하기

초기에는 children을 받아 cloneElement로 감싸는 방식으로 구현해 보았는데, 실제로 적용해 보니 여러 문제가 드러났다.

React.cloneElement(children, {
  onFocus: handleFocus,
  onBlur: handleBlur,
  ref: inputRef,
});

실제로 부딪힌 문제들

• 일단 children이 단일 요소라는 보장이 없었다.
  • 실제 렌더링되는 컴포넌트들 중 일부는 입력 요소가 하나로 고정되어 있는 것이 아니라, 해당 컴포넌트 내부에서 조건 분기를 통해 서로 다른 input / textarea 가 렌더링되는 구조였다.
• 이미 외부에서 onFocus, onBlur, ref를 사용하는 경우가 있어 충돌이 발생함.

결국 cloneElement는 구조가 예측 가능한 단순한 상황에서는 괜찮지만, 지금처럼 다양한 구조에서는 오히려 더 많은 제약을 발생시킨다는 것을 알게 되었다.

내부 탐색 방식

외부 구조에 의존하지 않고, 컴포넌트 내부에서 입력 필드를 직접 탐색하는 방식으로 전환했다.

const inputElement =
  containerRef.current?.querySelector('input') ||
  containerRef.current?.querySelector('textarea');

 

containerRef를 기준으로 내부에서 가장 가까운 input 또는 textarea 요소를 탐색해 focus 이벤트를 감지하고, 버튼 노출 여부를 결정하도록 하였다.

• 외부에서 ref를 넘기지 않아도 됨
• 구조가 복잡해져도 내부에서 탐색 가능
• 포커스 감지, 렌더링 조건, 버튼 위치 등 모든 판단을 내부에서 처리

입력 보조 패널 역시 같은 구조로 작동하도록 만들었다. ref를 넘겨받는 대신, 동일하게 containerRef.current?. querySelector(...)를 사용해 입력 필드를 탐색하고, 특정 버튼 클릭 시 내부에서 입력 값을 조작하고 이벤트를 트리거하도록 만들었다.

<EditorFieldWrapper>
  <input type="text" />
</EditorFieldWrapper>