Bootion Key Interaction

Bootion Key Interaction

해당 문서는...

Bootion의 Key 입력 Interaction 에 대해 설명 합니다.

왜 key Interaction을 Custom 했나요?

Browser는 기본적으로 입력과 관련된 훌륭한 Interaction을 지원 합니다. 하지만 저희 Bootion은 Notion을 Clone 및 Upgrade 한 웹 서비스로 최대한 Notion과 비슷한 UX를 제공해야하기 때문에 Notion의 독자적인 Key Interaction 또한 지원해야 합니다. 이를 Custom한 이유는 기반이 되는 구조와 밀접한 관계가 있으므로 앞서 Block에 대해 알 필요가 있습니다.

Block 이란?

Block은 Notion의 최소단위로 이 Block이 모여서 하나의 Page가 만들어 집니다. Block은 다양한 타입이 있으며 Block들 간에는 위치나 상태에 따른 상호작용이 발생하고 자유로운 배치를 지원 합니다. 그러므로 블록의 상태에 따라 key 입력에 따른 반응이 달라집니다.

불가피한 Custom

위와 같은 이유로 browser에서 제공하는 기본 상호작용으로는 Notion의 UX를 구현하기에는 부족하다고 판단했습니다. 그래서 key 입력에 따른 Interaction을 Custom 하기로 했습니다.

Key Interaction 에 대응하기 위한 상태관리

Bootion은 Recoil을 통해 상태관리가 이루어지며 다음 두 상태를 통해 Block 정보가 관리 됩니다.

• page에 대한 정보를 관리하는 pageState

const pageState = atom<Page>({
  key: StateType.PAGE_STATE,
  default: (async () => (await fetchData()).page)(),
});

interface Page {
  id: IdType;
  title: string;
  rootId: IdType;
}

• block에 대한 정보를 관리하는 blockMapState
• key 입력에 따라 복수의 블록에 대한 상태를 변경해야할 때가 있습니다. 때문에 모든 block에 대한 접근 및 수정이 용이한 상태를 구현할 필요가 있었습니다. 그러므로 모든 Block의 id를 key값, block 객체를 value로 하는 객체를 상태값으로 가지게해서 id를 통해 모든 Block에 대한 접근 및 수정이 가능하게 했습니다.

const blockMapState = atom<BlockMap>({
  key: StateType.BLOCK_MAP_STATE,
  default: (async () => (await fetchData()).blockMap)(),
});

type BlockMap = { [key: string]: Block };

왜 blockMapState를 atomFamily로 구현하지 않았나요?

recoil에는 atomFamily 라는 상태가 있습니다. 해당 상태는 atom하고 비슷하지만 차이점으로 각 인스턴스마다 고유한 key를 매개변수로 받으며 이를 통해 다른 인스턴스와 구분해서 상태관리가 가능 합니다. 그러므로 blockMapState를 atomFamily로 구성할 시 block의 id를 key로 한다면 Map 처럼 접근이 가능함과 동시에 인스턴스로 개별상태 관리가 가능하므로 기존구조보다 용이해보입니다. 하지만...

react Hook은 오직 React 함수내에서만 호출이 가능 합니다!

React 공식문서에 의하면 react Hook은 다음과 같은 규칙을 따릅니다.

1. 최상위(at the Top Level)에서만 Hook을 호출해야 합니다.
2. 오직 React 함수 내에서 Hook을 호출해야 합니다

위의 규칙에 의하면 hook의 inner function 에서는 상태를 구독하는게 불가능 합니다. 즉, atomFamily로 blockMapState를 생성할 경우 필요한 Block 객체를 즉시 구독해서 얻는 것이 불가능 합니다. 단, inner function이 아닌 Custom Hook 내에서 Hook을 호출하는 것은 가능 합니다. 때문에 필요한 모든 Block 정보를 각각 미리 구독해놓으면 되지 않을까 하는 생각이 들 수 있지만 Notion의 블록간 상호작용 범주가 넓어서 결국 모든 블록 정보가 필요하게 됩니다. 그러므로 모든 Block 객체 접근이 용이한 지금의 BlockMap 구조를 사용하게 되었습니다.

Key Interaction 을 관리 및 적용하는 Hook

위에서 설명한 blockMapState를 통해 block의 id를 key로 Block 객체에 접근이 가능 합니다. 다음은 Key Interaction에 따라 Block의 상태를 변경하기 위한 Custom Hook 입니다.

• Bootion의 key Interaction을 관리하는 useCommand Custom Hook
• Block의 구조나 상태 변경을 관리하는 useManager Custom Hook
• Block의 계층 정보와 접근을 관리하는 useFamily Custom Hook
• Block의 구조나 상태 변경 이력을 관리하는 useHistory Custom Hook

useCommand

useCommand 는 사용자의 key 매개변수로 받아 Bootion에서 제공하는 Key Interaction을 적용하는 함수를 반환하는 Custom Hook 입니다. useCommand 는 블록 구조 변경을 위해 기준이되는 block의 id를 매개변수로 받는 useManager Custom Hook을 사용합니다.

• 기준이되는 블록은 키 입력이 발생한 focus 된 Block 입니다.

key 입력에 따른 동작 방식은 다음과 같습니다.

1. key 입력이 발생하면 Bootion에서 대응해야하는 key인지 검증 합니다.
2. 만약 맞다면 기본 이벤트를 취소하고 key값을 useCommand에서 반환한 dispatcher 함수에 넣어 실행 합니다.
3. Block 구조에 변경사항이 발생하는 입력일 경우 useManager에서 반환한 startTransaction 함수를 실행해 Transaction을 초기화 합니다.
4. key 입력에 대응하는 변경사항을 적용하기 위해 useManager에서 반환한 BlockMap 조작 함수를 싱행해 Transaction에 반영 합니다.
5. 변경사항을 Block에 반영하기위해 useManager에서 반환한 commitTransaction 함수를 실행 합니다.
6. commit과 동시에 useHistroy에 Transaction 정보가 저장 됩니다.
7. Transaction에 적용된 변경사항이 Block에 반영 됩니다.

Key Interaction 알고리즘 순서도

Transaction? 그냥 바로 Block의 상태를 변경하면 되지 않나요?

set 함수로 상태를 변경할 경우 변경사항이 호출과 동시에 반영되지 않습니다. 그러므로 set 함수 호출후 상태를 읽으면 변경 전 상태를 읽게되는 문제가 발생 합니다. Transaction은 위와 같은 문제를 해결하기 위해 복사한 blockMap에 변경사항을 반영하고 commit 시 일괄 반영하는 로직으로 구현되어 있습니다. 때문에 블록을 하나만 수정하면 될 경우에는 Transaction을 경유하지 않아도 됩니다. 하지만 대부분의 수정사항은 복수의 블록에 대한 상태변경으로 이루어지므로 Transaction을 통해 변경사항을 반영해야 합니다.

useManager

useManager 는 매개변수로 받은 block의 id를 기준으로 block의 상태와 구조변경 함수를 반환하는 Custom Hook 입니다. useManager 는 매개변수로 받은 block의 id와 관련된 block 정보를 얻기 위해 useFamily Custom Hook을 사용 합니다. 또한 redo, undo 에 대응하기위해 useHistory Custom Hook을 사용합니다.

위에서 설명한 바와 같이 지역변수로 transaction 이라는 Mutable한 변수를 가지고 있습니다. 해당 변수는 blockMap을 값으로 가지며 block의 상태를 해야하는 사항은 transaction 변수에 반영 됩니다. 관련 함수는 다음과 같습니다.

• startTransaction을 통해 transaction 변수를 blockMap으로 초기화 할 수 있습니다.
• commitTransaction을 통해 transaction 에 적용된 변경사항을 blockMapState에 반영할 수 있습니다. 또한 현재 transaction 정보가 useHistory의 이력정보에 추가 됩니다.

useFamily

useFamily는 매개변수로 받은 block의 id를 기준으로 자신, 부모, 조부모, 자식, 형제들 등에 대한 상태와 특정조건에 부합하는 Block 객체를 탐색하는 함수를 반환하는 Hook 입니다.

• Notion은 Block의 상태와 입력에 따라 주변 Block에 영향을 끼칩니다. useFamily는 해당 Block 들을 탐색하기 위한 함수들을 지원 합니다.

Block 구조 변경 후 Focus 할당

key 입력과 hook들을 통해 Block의 구조가 변경되면 focus된 대상을 변경해야 하는 경우가 생깁니다. 이를 위해서는 focus된 block의 정보를 state로 관리할 필요가 있는데 다음과 같은 문제가 발생합니다.

1. React는 자체적으로 focus를 주기위한 props나 함수를 지원하지 않습니다.
2. 위와 같은 이유로 DOM의 focus 함수를 사용하기 위해 useRef로 DOM을 얻을 필요가 생깁니다.
3. 그리고 이렇게 얻은 ref는 전역으로 접근이 가능해야 합니다.

여기까지 도달하면 Block의 ref를 상태로 관리해야할 필요성을 느낍니다. 하지만...

DOM은 React State로 관리하면 안됩니다!

React State로 관리되기 시작하는 값들은 immutable 해집니다. 그러므로 DOM을 state로 관리할 시 해당 DOM 들은 수정이 불가능하게 됩니다. 이 상태에서 해당 DOM 들이 포함된 Component가 삭제될 시 ReactDom에서 아래와 같은 에러가 발생 합니다.

원인은 ReactDom에서 해당 Component를 삭제하기위해 ref의 current 값을 null로 바꾸려 로직에 있습니다. 수정할 수 없게된 DOM 객체를 수정하려 한 것이지요.

그러면 어떻게 해야할까요?

해결방법은 간단 합니다. block에 대한 DOM 객체를 전역으로 접근할 필요성은 여전히 있지만 이를 state로 관리할 수 없을뿐 입니다. 그러므로 Object에 담아서 전역으로 접근하게하면 됩니다. 코드는 아래와 같습니다.

const blockRefState: { [id: string]: MutableRefObject<any> } = {};

blockRefState는 모든 Block에 대한 DOM 객체접근을 가능하게 하는 책임만 있을뿐 구독을 통해 Component의 표시내용을 매번 갱신해야하는 의존성이 없으므로 위처럼 사용해도 된다는 결론에 이르렀습니다.

Block 생성 후 Focus 할당

Enter 키 입력 시 현재 Focus된 Block의 첫번째 자식 혹은 다음형제에 신규블록이 삽입 됩니다. 삽입후에는 신규블록에 Focus를 할당해야 하는데 해당 로직을 수행중인 useCommand Hook 내에서는 아직 ReactDom에 의해 신규블록이 생성되기 전이므로 blockRefState에는 해당 Block의 DOM 객체가 담겨있지 않습니다. 그러므로 신규블록이 랜더링됨과 동시에 자신이 focus된 블록임을 알 수 있는 상태가 필요합니다.

focusState

위와 같은 필요가 있어 focusState를 통해 현재 focus된 Block의 id를 관리하게 했습니다. 모든 Block은 focusState를 구독하고 focusId가 자신의 id인지 검증하며 자신의 id 일 경우 자신한테 focus를 줍니다. 때문에 focusState의 상태를 변경한다는 것은 변경한 id를 가진 Block에 focus를 주는 것이 됩니다. 해당 방안을 통해 Hook내에서 focusState의 상태값을 신규블록의 id로 변경하는 것으로 랜더링 시 focus가 할당되게 했습니다.

Caret 위치 조작

Interaction에 의해 focus가 변경될 경우 caret의 위치도 조정되어야할 필요가 생깁니다. 보통 다음의 경우가 있습니다.

1. focus 된 블록의 0번째 offset에 caret이 배치되어야 하는 경우
2. focus된 블록의 마지막 offset에 caret이 배치되어야 하는 경우
3. 이전에 focus된 블록의 offset이 현재 focus된 블록에 반영되어야 하는 경우

위와 같은 필요성에 의해 Caret Offset을 조정하기 위해서 Selection API를 사용 했습니다.

• Selection API 는 현재 Caret 의 영향을 받고 있는 Node 와 offset 정보를 가져올 수 있습니다.
• window 혹은 document 객체에서 getSelection() 호출을 통해 사용이 가능합니다.
• Selection 객체의 collapse 함수를 통해 caret offset 을 수정할 수 있습니다.

Selection API를 이용해 Caret 정보를 읽거나 설정하는게 가능해졌지만 다음과 같은 문제가 발생 했습니다.

rerendering, focus 변경에 따른 caret 위치 변경

Block Component가 rerendering 되거나 focus가 변경될 경우 기본 Interaction에 의해 caret offset이 0으로 설정 됩니다. 이 상태에서 Bootion의 Key Interaction이 반영되므로 기능상으로는 문제가 없지만 UX 측면에서는 이전 focus Block의 맨 앞으로 caret이 당겨졌다가 원래 배치되어야할 위치로 재배치 되는 현상을 겪게 됩니다.

어떻게해야 이러한 현상을 방지할 수 있을까요? 🤔

해당 현상은 다음과 같은 경우에 발생 합니다.

1. Block Component가 새로 생성될 경우
2. Block Component 내 로직에 의해 focus가 자신에게 할당될 경우

즉 랜더링 후 focus가 재할당되어서 caret offset이 0으로 설정 되었는데 caret 위치 변경로직이 적용되어서 caret 위치가 왔다갔다 하는 현상이 발생하는 겁니다. 그러므로 아래 코드처럼 위의 경우에 기존 focus된 Block의 caret을 blur(focus를 잃게) 하고 랜더링 이후에 focus된 block에 caret이 배치 될 수 있도록 설정하면 됩니다.

const setFocus = (targetBlock: Block) => {
    if (!targetBlock) {
      return null;
    }
    const beforeOffset = window.getSelection().focusOffset;
    setFocusId(targetBlock.id);
    const targetRef = blockRefState[targetBlock.id];
    targetRef
      ? targetRef.current.focus()
      : blockRefState[block.id].current.blur();
    return beforeOffset;
  }; 

이렇게 focus와 caret 에 대한 UX를 구현할 수 있었습니다. 하지만 이 처럼 구현의 틀이 잡히면서 UX와 밀접한 큰 문제가 발생 했습니다.

연속된 key 입력과 랜더링 속도

Key 입력이 연속으로 빠르게 발생할 경우 랜더링 속도가 key Interaction 적용 속도를 못따라잡아 화면이 멈추는 현상이 발생한 것 입니다. 심지어 Enter Key Interaction의 경우 새로운 블록생성 속도가 focus 상태 변경속도를 못따라잡는 문제가 발생해서 useCommand(useCommand는 focus 된 블록을 기준으로 동작하기 때문 입니다.)에서 에러가 발생할 정도 였습니다. 때문에 Key Interaction이 적용된 후에 새로운 Key 입력을 받게할 필요가 생겼습니다.

Key Interaction과 throttling

해당 문제는 UX와 관련해 자주 언급되는 사항이며 throttling 이 해결책으로 꼽힙니다. 그래서 Lodash 라이브러리의 throttle 함수를 이용해 이를 해결하고자 시도했습니다 하지만 다음과 같은 문제가 발생합니다.

1. Bootion은 Component를 함수형으로 구현하므로 랜더링될 때 마다 지역변수들을 다시 생성 합니다.
2. 그러므로 key 입력에 throttle을 적용해도 리랜더링 될 때 throttle 된 상태인지에 대한 정보가 남지 않으므로 throttle이 적용되지 않습니다.
3. throttle을 사용하는 이벤트 함수를 useRef로 관리하는 방안이 있지만 내부에서 useCommand가 반환한 dispatcher를 사용하므로 useCommand와 관련된 상태에 변경사항이 발생함에 따라 dispatcher가 유효하지 않은 경우가 생겨서 에러가 발생 합니다.

결국 throttle 상태정보가 저장되지 않아 해당 문제가 발생한다고 결론을 내렸습니다.

Custom Throttle

위의 문제를 해결하기 위해서는 아래처럼 현재 throttle 상태에 대한 상태관리가 필요하다고 판단이 되었습니다.

const throttleState = {
  isThrottle: false,
};

위의 상태를 통해 다음과 같은 구조로 Custom throtting을 적용할 수 있습니다.

const handleKeyDown = (event: KeyboardEvent<HTMLDivElement>) => {
    const { focusNode, focusOffset } = window.getSelection();
    if (throttleState.isThrottle) {
      event.preventDefault();
    } else if (/* Bootion이 다뤄야할 key 입력인가? */) {
      throttleState.isThrottle = true;
      event.preventDefault();
      setImmediate(() => {
        Dispatcher(event.key);
        throttleState.isThrottle = false;
      });
    }
  };

해당 로직은 다음과 같은 절차로 진행 됩니다.

1. throttleState의 isThrottle이 false 일 경우에만 Key Interaction이 발생 합니다.
2. key Interaction이 발생해야할 경우 isThrottle 값이 true가 되어 이후 발생하는 key 입력을 버립니다.
3. setImmediate 함수를 통해 콜백함수에서 dispatcher를 실행 합니다. 실행이 완료되면 isThrottle의 값을 false로 변경해서 key 입력에 따라 Key Interaction이 발생하게 합니다.

위의 로직을 통해 Key Interaction 적용이 완료된 이후 다음 Key Interaction 적용을 보장할 수 있습니다.