02. React 탄생 이야기

┌──────────────────────────────────────────────────┐
│                  Facebook (2011)                  │
├──────────────────────┬───────────────────────────┤
│      서버 사이드      │       클라이언트 사이드     │
│                      │                           │
│   PHP + XHP          │   순수 JavaScript (Bolt)   │
│                      │                           │
│  • 서버에서 HTML 생성  │  • 브라우저에서 DOM 조작    │
│  • 컴포넌트 개념 있음  │  • 명령형 코드            │
│  • 데이터→HTML 자동    │  • 수동 DOM 업데이트       │
│  • 매 요청마다 새로 생성│  • 상태 관리는 개발자 몫    │
└──────────────────────┴───────────────────────────┘

// XHP — PHP 안에서 HTML을 컴포넌트처럼 사용
class :ui:badge extends :x:element {
  attribute int count @required;
 
  protected function render() {
    $count = $this->getAttribute('count');
    if ($count === 0) {
      return <x:frag />;  // 0이면 아무것도 안 보임
    }
    return <span class="badge">{$count}</span>;
  }
}
 
// 사용
<ui:badge count={$unreadCount} />

// Bolt — 명령형 DOM 조작
var ChatBadge = {
  update: function(unreadCount) {
    var badge = document.getElementById('chat-badge');
    if (unreadCount > 0) {
      badge.style.display = 'inline';
      badge.textContent = unreadCount;
    } else {
      badge.style.display = 'none';
    }
  }
};
 
// 메시지 읽음 처리 시
MessageStore.onRead(function(messageId) {
  var count = MessageStore.getUnreadCount();
  ChatBadge.update(count);          // ← 직접 업데이트
  HeaderNotification.update(count); // ← 여기도
  TabTitle.update(count);           // ← 여기도
  // ... 더 있을 수 있음
});

┌────────────────────────────────────────────────────┐
│  Facebook  [🔍 검색]  [홈] [👤] [💬1] [🔔3] [▼]    │
│                                      ↑              │
│                              이 "1"이 사라지지 않음   │
├────────────────────────────────────────────────────┤
│                                                    │
│   ┌─ 채팅 창 ──────────┐                           │
│   │ John: Hey!         │  ← 이미 읽었는데          │
│   │ (이미 읽음 상태)    │     뱃지는 여전히 "1"      │
│   └────────────────────┘                           │
│                                                    │
└────────────────────────────────────────────────────┘

메시지 수신 이벤트 발생 시 업데이트해야 하는 곳:
 
  ① 채팅 뱃지 숫자          → Chat 팀 담당
  ② 상단 알림 아이콘         → Notifications 팀 담당
  ③ 브라우저 탭 타이틀       → Platform 팀 담당
  ④ 채팅 목록의 읽지 않음 표시 → Chat 팀 담당
  ⑤ 채팅 창 내부 메시지 상태  → Chat 팀 담당
  ⑥ 사이드바 친구 목록 상태   → Social 팀 담당
  ⑦ 모바일 웹 뷰의 뱃지      → Mobile 팀 담당

// 메시지 읽음 처리 — 여러 팀이 각자 작성한 코드
MessageActions.markAsRead = function(threadId) {
  // 서버에 읽음 상태 전송
  API.post('/messages/read', { thread: threadId });
 
  // 로컬 상태 업데이트
  MessageStore.markRead(threadId);
  var count = MessageStore.getUnreadCount();
 
  // ① Chat 팀이 작성
  ChatBadge.update(count);
 
  // ② Notifications 팀이 작성
  NotificationIcon.refresh();
 
  // ③ Platform 팀이 작성
  TabTitle.setCount(count);
 
  // ④ Chat 팀이 작성
  ChatList.markThreadRead(threadId);
 
  // ⑤ Chat 팀이 작성
  ChatWindow.updateReadStatus(threadId);
 
  // ⑥ 새로 추가된 사이드바 — 누군가 여기에 추가하는 걸 잊음!
  // SidebarFriends.updateStatus(threadId);  ← 빠뜨림!
 
  // ⑦ 모바일 웹 뷰 — 아직 연동 안 됨
  // MobileView.sync();  ← 빠뜨림!
};

문제의 근본 원인:
 
1. 새 UI 영역이 추가될 때마다, 기존의 모든 이벤트 핸들러에
   새 영역 업데이트 코드를 추가해야 함
 
2. 각 영역을 다른 팀이 담당하므로, 다른 팀의 코드에
   자기 영역 업데이트를 추가해달라고 요청해야 함
 
3. 하나라도 빠뜨리면 → 불일치 버그
 
4. 이 패턴이 메시지뿐 아니라 좋아요, 댓글, 친구 요청,
   그룹 알림 등 모든 기능에 존재

서버(XHP):
  요청이 올 때마다 → 데이터로 HTML을 처음부터 새로 만듦
  → 이전 상태와 동기화할 필요 없음
  → 그래서 동기화 버그가 없음
 
브라우저(Bolt):
  이벤트가 올 때마다 → 기존 DOM을 부분적으로 수정
  → 어디를 수정해야 하는지 추적 필요
  → 빠뜨리면 동기화 버그

기존 방식:
  상태 변경 → 바뀐 부분을 찾아서 DOM 수정 (명령형)
  → 개발자가 "어디를 바꿀지" 알아야 함
 
Jordan의 방식:
  상태 변경 → 전체 UI를 새로 "선언" → 이전과 비교 → 바뀐 부분만 실제 반영
  → 개발자는 "최종 상태"만 선언하면 됨

// Bolt 방식 — "어떻게 바꿀지" 일일이 지시
var NotificationBadge = {
  element: null,
  count: 0,
 
  init: function(el) {
    this.element = el;
    this.render();
  },
 
  setCount: function(newCount) {
    var oldCount = this.count;
    this.count = newCount;
 
    // 변경사항을 직접 추적하고 DOM을 수동 업데이트
    if (oldCount === 0 && newCount > 0) {
      this.element.style.display = 'inline';
      this.element.textContent = newCount;
      this.element.classList.add('badge-pulse');
    } else if (oldCount > 0 && newCount === 0) {
      this.element.style.display = 'none';
      this.element.classList.remove('badge-pulse');
    } else if (newCount !== oldCount) {
      this.element.textContent = newCount;
      this.element.classList.add('badge-pulse');
      setTimeout(function() {
        this.element.classList.remove('badge-pulse');
      }.bind(this), 300);
    }
    // 상태별 분기가 점점 복잡해짐...
  }
};

// FaxJS 방식 — "어떻게 보여야 하는지"만 선언
var NotificationBadge = FaxJS.createComponent({
  getInitialState: function() {
    return { count: 0 };
  },
 
  render: function() {
    // 상태에 따른 최종 모습만 선언
    if (this.state.count === 0) {
      return FaxJS.Div({ style: { display: 'none' } });
    }
 
    return FaxJS.Span({
      className: 'badge',
      content: this.state.count
    });
  }
 
  // DOM 업데이트? FaxJS가 알아서 함
  // 이전 렌더와 비교? FaxJS가 알아서 함
  // 애니메이션 분기? CSS transition으로 처리
});

Bolt (명령형):
  "count가 0에서 1로 바뀌면 display를 inline으로 바꾸고,
   1에서 0으로 바뀌면 none으로 바꾸고,
   1에서 2로 바뀌면 textContent만 바꾸고..."
   → 모든 전환(transition)을 개발자가 직접 관리
 
FaxJS (선언적):
  "count가 0이면 안 보이고, 0이 아니면 숫자를 보여줘"
   → 최종 상태만 선언, 전환은 프레임워크가 관리

2011         2012 초               2012 중          2012 말        2013.05
  │            │                     │               │              │
  ▼            ▼                     ▼               ▼              ▼
FaxJS       Facebook 내부       뉴스피드 적용     Instagram      오픈소스
프로토타입    검색에 첫 적용      + JSX 도입       전면 도입       공개

// JSX 이전 (React.createElement)
React.createElement('div', { className: 'badge' },
  React.createElement('span', null, count)
);
 
// JSX 도입 후
<div className="badge">
  <span>{count}</span>
</div>

// 2013년의 개발자들이 본 것:
function Badge({ count }) {
  return (
    <div className="badge">     {/* ← 이게 JS 파일 안에?! */}
      <span>{count}</span>
    </div>
  );
}

2013년 커뮤니티 반응:
 
"SoC(관심사의 분리) 원칙을 완전히 위반하잖아"
"HTML은 .html에, JS는 .js에 있어야 하는 거 아닌가?"
"이건 PHP 스파게티 코드로 돌아가는 것과 같다"
"Facebook이 또 이상한 걸 만들었네"

비판: "실제 DOM을 직접 수정하는 게 더 빠르지 않나?
       매번 전체를 다시 그리고 비교한다고?"
 
실제: DOM 조작 자체가 비싼 연산.
      Virtual DOM은 JavaScript 객체 비교(빠름)를 먼저 하고
      실제 DOM 변경은 최소화함.
 
      그리고 성능보다 중요한 건 "버그 없는 코드"였음.

2013년 인기 프레임워크들:
  - Angular 1.x  — Google의 MVC 프레임워크
  - Backbone.js  — 경량 MVC
  - Ember.js     — Convention over Configuration
 
이들은 모두 Model-View-Controller 패턴을 따름
React는 "V(View)만 담당한다"고 했음
 
비판: "프레임워크도 아닌 게 뭘 하겠다는 거야?"

2013년 말 ~ 2014년:
 
"처음엔 JSX가 이상해 보였는데, 일주일 쓰니까
 이전으로 돌아갈 수 없게 됐다"
 
"뉴스피드에서 매주 터지던 상태 버그가 React 적용 후 사라졌다"
 
"새 기능 추가할 때 기존 코드가 깨질까 두려웠는데,
 React에서는 컴포넌트만 추가하면 되니까 두려움이 없다"
 
"jQuery로 6시간 걸리던 걸 React로 1시간에 했다.
 코드 양이 줄어서가 아니라, 생각할 게 줄어서."

// 여러 이벤트에서 각각 DOM을 직접 조작
$(document).on('newMessage', function(e, data) {
  var $badge = $('#chat-badge');
  var currentCount = parseInt($badge.text()) || 0;
  var newCount = currentCount + 1;
 
  $badge.text(newCount).show().addClass('pulse');
  $('#header-count').text('(' + newCount + ')');
  document.title = '(' + newCount + ') Facebook';
 
  setTimeout(function() {
    $badge.removeClass('pulse');
  }, 300);
});
 
$(document).on('messageRead', function(e, data) {
  var $badge = $('#chat-badge');
  var currentCount = parseInt($badge.text()) || 0;
  var newCount = Math.max(0, currentCount - 1);
 
  if (newCount === 0) {
    $badge.hide();
    document.title = 'Facebook';
  } else {
    $badge.text(newCount);
    document.title = '(' + newCount + ') Facebook';
  }
  $('#header-count').text(newCount > 0 ? '(' + newCount + ')' : '');
 
  // 채팅 목록도 업데이트...
  $('#thread-' + data.threadId).removeClass('unread');
});
 
// 새 영역 추가 시: 위의 두 핸들러 모두에 코드 추가 필요!

function ChatBadge({ unreadCount }) {
  // 선언적: 상태에 따른 최종 모습만 정의
  if (unreadCount === 0) return null;
 
  return <span className="badge">{unreadCount}</span>;
}
 
function Header({ unreadCount }) {
  return (
    <header>
      <h1>Facebook {unreadCount > 0 && `(${unreadCount})`}</h1>
      <nav>
        <ChatBadge unreadCount={unreadCount} />
      </nav>
    </header>
  );
}
 
function App() {
  const [unreadCount, setUnreadCount] = useState(0);
 
  // 이벤트 처리: 상태만 변경하면 모든 UI가 자동으로 맞춰짐
  useEffect(() => {
    socket.on('newMessage', () => setUnreadCount(c => c + 1));
    socket.on('messageRead', () => setUnreadCount(c => Math.max(0, c - 1)));
  }, []);
 
  // unreadCount가 바뀌면 Header, ChatBadge, 탭 타이틀 등
  // 모든 곳이 자동으로 업데이트됨
  return <Header unreadCount={unreadCount} />;
}

jQuery: 이벤트 2개 × DOM 영역 4개 = 8곳에서 수동 업데이트
React:  상태 1개 변경 → 모든 UI 자동 동기화
 
새 영역 추가 시:
  jQuery → 모든 이벤트 핸들러에 새 DOM 조작 코드 추가
  React  → 새 컴포넌트만 추가하면 끝

2012.01  검색 UI에 첫 적용
         → "확실히 버그가 줄었다"
 
2012.06  뉴스피드에 적용
         → "매주 터지던 상태 버그가 사라졌다"
 
2012.09  Instagram 웹 전면 도입
         → "인수 후 웹사이트를 React로 재작성"
 
2013.03  Facebook 내부 대부분의 신규 프로젝트가 React 사용
         → "이제 Bolt로 새 프로젝트를 시작하는 팀이 없다"
 
2013.05  JSConf US에서 오픈소스 공개
         → Pete Hunt: "React의 요점은 성능이 아니라
            예측 가능한 코드를 작성할 수 있게 하는 것이다"