왜 React 사용시 DOM에 직접적인 접근은 안티패턴으로 분류될까 ?

[yunseorim1116]

1. React의 선언적 패러다임 위반

React는 "UI = f(state)"라는 개념을 중심으로 설계되었습니다. 이는 UI가 상태의 순수 함수여야 한다는 의미입니다. DOM을 직접 조작하면 이 패러다임을 깨뜨리고, 상태 관리를 복잡하게 만듭니다.
Thinking in React

2. 가상 DOM과의 불일치

React의 가상 DOM은 실제 DOM의 경량화된 복사본입니다. React는 이를 사용해 효율적으로 DOM 업데이트를 수행합니다.
DOM을 직접 조작하면 가상 DOM과 실제 DOM 사이의 동기화가 깨져 예상치 못한 렌더링 문제가 발생할 수 있습니다.

3. 컴포넌트의 예측 가능성 저하

React 컴포넌트는 주어진 props와 state에 대해 항상 같은 출력을 생성해야 합니다.
DOM 직접 조작은 이 원칙을 위반하여 컴포넌트의 동작을 예측하기 어렵게 만듭니다.

4. 테스트의 어려움

React 컴포넌트는 props와 state만으로 테스트할 수 있어야 합니다.
DOM 직접 조작은 단위 테스트를 어렵게 만듭니다.
테스팅 라이브러리

5. React의 생명주기 무시

React 컴포넌트는 정해진 생명주기에 따라 관리됩니다. DOM을 직접 조작하면 이 생명주기를 우회하게 되어상태 업데이트나 부수 효과 처리에 문제가 생길 수 있습니다. 함수형 컴포넌트는 Hooks를 사용하여 생명주기와 유사한 기능을 구현하는데 useEffect Hook이 이 역할을 담당합니다. DOM을 직접 조작하면 useEffect의 실행 타이밍과 충돌할 수 있습니다.

5-1. useEffect의 동작 방해

useEffect는 컴포넌트가 렌더링된 후에 실행됩니다. DOM을 직접 조작하면 useEffect의 실행 전에 DOM이 변경될 수 있어 부작용이 발생할 수 있습니다.

function ProblematicComponent() {
  useEffect(() => {
    //문제 발생 위험이 있는 코드
    document.getElementById('my-element').style.color = 'red';
  }, []);

  return <div id="my-element">Hello, World!</div>;
}

1. 같은 ID를 가진 여러 요소가 생기면 예상치 못한 동작이 일어날 수 있습니다. (컴포넌트 재사용성 저하)
2. React가 DOM 업데이트를 완료하기 전에 이 코드가 실행될 수 있어, 의도하지 않은 결과를 초래할 수 있습니다.
3. document.getElementById는 전체 DOM을 검색합니다.
4. 캡슐화 위반: 컴포넌트의 내부 구현이 외부(전역 document 객체)에 의존하게 되어 컴포넌트의 캡슐화가 깨집니다.

5-2. 불필요한 리렌더링

DOM을 직접 조작하면 React가 변경사항을 인지하지 못해, 불필요한 리렌더링이 발생할 수 있습니다.

한줄 요약

결론은 DOM 직접 조작은

• React의 선언적 패러다임
• 가상 DOM 동기화
• 컴포넌트 재사용성, 테스트 용이성
• 생명주기 관리 위반

등의 문제가 있습니다, ...
그래서 React의 상태 관리 시스템과 ref를 활용한 접근이 권장됩니다 ! 탕탕 ~!

레퍼런스

React Hooks API Reference
useRef Hook 공식 문서
React에서 DOM 조작하기

[lukasjhan]

예전에 react movable 라이브러리를 이용할일이 있었는데요. 내부적으로 Ref를 props로 받아 사용해서 이동가능한 영역을 잡아 이동하는 방식이더라고요. 하지만 처음 렌더할때는 ref가 null이어서 (아직 dom이 그려져잇지 않아서) 이동되지않았었어요. 그래서 강제로 한번 더 매번 렌더했었답니다.

게다가 이 상황을 주석으로 남겨서 다른 개발자들에게 공유하기 굉장히 어렵더라고요. 이상한 상황이어서 더 그랬답니다.