Memo

Typescript에서 redux-actions대체하기

2019-10-13T10:03:12+00:00

`Redux-Actions`

리덕스 액션즈는 리덕스에서 귀찮은 일들을 상당부분 줄여주는 유틸리티 라이브러리이다. 많은 기능들이 있지만 필자가 가장 즐겨 쓰는 (사실은 그것만 사용하는)함수는 두개. createAction과 handleActions이다.

이 두가지 함수는 리덕스에서 상당히 귀찮은 작업인 ActionCreator를 만드는 작업과 Reducer를 만드는 작업의 보일러플레이트를 굉장히 편하게 줄여준다. 그래서 개인적으로 작업을 하든, 업무를 할때든 리덕스를 사용할때면 거의 항상 사용하곤 했다.

아래는 라이브러리 사용을 간단하게 작성해 보았다. 하기의 사용 예 말고 다양한 사용 사례가 많지만 개인적으로는 대부분 이 사용 방법에서 벗어나지 않게 사용했던것 같다.

// 액션
const CHANGE_NAME = 'CHANGE_NAME';
const CHANGE_AGE = 'CHANGE_AGE';

const defaultStae = {
  name: 'john',
  age: 27
};

// ------ Before ----------

// 액션 크리에이터
const changeName = name => ({
  type: CHANGE_NAME,
  payload: { name }
});
const changeAge = age => ({
  type: CHANGE_NAME,
  payload: { age }
});

// 리듀셔
const user = (state = defaultState, action) => {
  switch (action.type) {
    case CHNAGE_NAME: {
      return {
        ...state,
        name: action.payload.name
      };
    }
    case CHANGE_AGE: {
      return {
        ...state,
        age: action.payload.age
      };
    }
    default:
      return state;
  }
};

// -------- after -------

// 액션 크리에이터
const changeName = createAction(CHANGE_NAME, (name = { name }));
const changeAge = createAction(CHANGE_AGE, (age = { age }));

// 리듀서
const user = handleActions({
  [CHANGE_NAME]: (state, { payload }) => ({
    ...state,
    name: payload.name
  }),
  [CHANGE_AGE]: (state, action) => {
    ...state,
    age: payload.age
  }
});

확실히 구문이 읽기 편하고 깔끔해졌다. 여기까지 봐서는 안쓸 이유가 없어보인다. 하지만 여기에는 문제가 있다. 이 라이브러리는 타입스크립트 지원이 굉장히 허술하게 되어있다.

무엇이 문제인가?

여러가지 문제가 있지만, 가장 큰 문제는 createAction이 뱉어내는 액션 크리에이터의 타입은 무조건 string으로 고정되어 있다는 사실이다. 타입 정의를 한번 보자.

// FSA-compliant action.
// See: https://github.com/acdlite/flux-standard-action
export interface BaseAction {
  type: string;
}

export interface Action<Payload> extends BaseAction {
  payload: Payload;
  error?: boolean;
}

이 라이브러리를 타입스크립트에서 사용하려고 시도해 보았던 사람들은 알 것이다. string 타입으로 고정해서 내놓는 것이 얼마나 끔찍한 일인지.. 우선 이 액션 크리에이터가 뱉어내는 액션은 기본적으로 string타입이기 때문에 액션 크리에이터가 리턴하는 인터페이스를 따로 짜주어야 한다. 이렇게 말이다.

const changeName = createAction(CHANGE_NAME, name => ({ name }));
interface ChangeName {
  type: typeof CHANGE_NAME;
  payload: {
    name: string;
  };
}

이전 글에서 소개했던 ReturnType을 이용하는 방법도 어림없다. 왜냐하면 changeName이 리턴하는 함수는 무조건 type이 string이기 때문에 올바르게 액션을 만들어내지 못하기 때문이다.

또 다른 문제는 handleActions에도 있다. 이 함수의 문제 역시 꽤 많다. 우선 가장 기본이 되는 타입 정의부터 살펴보자.

export type Reducer<State, Payload> = (
  state: State,
  action: Action<Payload>
) => State;

export type ReducerMeta<State, Payload, Meta> = (
  state: State,
  action: ActionMeta<Payload, Meta>
) => State;

export type ReducerMapValue<State, Payload> =
  | Reducer<State, Payload>
  | ReducerNextThrow<State, Payload>
  | ReducerMap<State, Payload>;

export interface ReducerMap<State, Payload> {
  [actionType: string]: ReducerMapValue<State, Payload>;
}

export function handleActions<State, Payload>(
  reducerMap: ReducerMap<State, Payload>,
  initialState: State,
  options?: Options
): ReduxCompatibleReducer<State, Payload>;

여기서도 보이는 문제는 액션이 type을 string으로 간주한다는 점이다. 액션 타입에 대하여 제네릭이든지 어떤 타입 추론에 도움이 될만한 정보가 존재하지 않는다. 이 끔찍한 가정은 handleActions에서 두번째 제네릭의 인자로 “액션”이 아닌 “페이로드”만 받는것과도 상통한다. 그러면 이 함수를 어떻게 써야할까?

// 페이로드를 가져오기 위한 헬퍼 타입
type GetPayload<A extends (...args: any[]) => any> = ReturnType<A> extends Action<infer P>
  ? P
  : never;

const changeName = createAction(CHANGE_NAME, (name: string) => ({ name }));
const changeAge = createAction(CHANGE_AGE, (age: number) => ({ age }));

type UserPayloads = GetPayload<typeof changeAge | typeof changeName>;

interface User {
  age: number;
  name: string;
}

const defaultState = {
  age: 27,
  name: 'john'
};

const user = handleActions<User, UserPayloads>(
  {
    [CHANGE_NAME]: (state, action) => {
      // 으윽.. 머리가...!
      if(!action.payload.name) {
        return state;
      }
      return {
        ...state,
        name:
      };
    }
  },
  defaultState
);

무언가 머리가 아픈 부분이 발견되었는가? CHANGE_NAME이 받는 함수의 action은 Typescript의 switch/case문 안에서의 Type narrowing의 효과를 전혀 받지 못한다. 모든 액션의 페이로드가 섞여있기 때문에 각 액션 타입에 맞는 페이로드를 걸러낸 다음 사용해야 한다. 이렇게 되면 사실상 Typescript를 사용하는 이점이 많이 사라지기 때문에 타입스크립트를 사용하면서 이 라이브러리를 사용하기 않게 되었다.

대안?

물론 대안을 찾아보지 않은 것은 아니다. 문제를 해결하기 위한 유명한 라이브러리가 있는데 typesafe-actions라는 라이브러리이다. 정말 좋은 라이브러리이지만 이 라이브러리의 사용법이 익숙하지 않고, redux-acton의 액션-핸들액션 맵핑 방식이 가독성이 매우 뛰어나다고 생각하여 직접 만들기로 했다.

수정사항: typesafe-actions를 과거에 확인했을때는 이런 객체 맵핑 방식이 지원되지 않았었는데, 올해 4월에 업데이트된 4.1버전부터 지원되는 것을 확인했다. 미리 확인해볼걸 하는 후회가 든다..

직접 만들기

앞서서 redux-actions의 타입 정의가 엉망이라고 했지만 사실 과거에는 어쩔 수 없었다고 생각한다. string타입으로만 문자열을 사용할 수 있었으니까. 하지만 우리에게는 3.4버전부터 추가된 as const가 있다. 그걸 사용해서 비슷하지만, 타입정의를 정확하게 해주는 대체제를 만들어보자

`handleActions`

코드와 함께 보자.

// 리덕스이 표준 액션 객체를 사용한다.
import { Action } from "redux";

// `type`를 `string`이 아닌 제네릭으로 두어서 `type`의 타입을 유지하여 리턴한다.
// 정확한 액션 크리에이터 함수를 만들기 위해서 함수의 시그니쳐를 오버로딩한다.
// 1. 페이로드 크리에이터 함수가 정의되어 있는 경우
// 2. 페이로드 크리에이터 함수가 정의되어있지 않아 페이로드가 없는 경우
function createAction<T, P extends (...args: any) => any>(
  type: T,
  payloadCreator: P
): (...args: Parameters<P>) => Action<T> & { payload: ReturnType<P> };
function createAction<T>(type: T): () => Action<T>;
function createAction(type: any, payloadCreator?: any) {
  return (...args: any[]) => ({
    type,
    ...(payloadCreator && { payload: payloadCreator(...args) })
  });
}

export default createAction;

자 이렇게 하고 사용해보자. 사용법은 매우 유사하다.

const changeName = createAction(CHANGE_NAME, (name: string) => ({ name }));
const changeAge = createAction(CHANGE_AGE, (age: number) => ({ age }));

type UserActions = ReturnType<typeof changeName | typeof changeAge>;

한결 간결해지고, 단순히 페이로드만의 타입이 아닌, 액션의 타입 전부를 기억하고있는 액션 타입이 만들어졌다. 그 다음은 이것을 처리하는 handleActions의 차례이다.

`handleActions`

처음 타입스크립트를 사용하려고 했을때 이 함수를 어떻게든 만들어보려고 했었다. 결과는 실패로 돌아갔는데 as const의 은총으로 액션 타입에 대한 정확한 정의가 가능해진 지금은 정복이 가능해졌다.

// 역시 리덕스의 표준 액션 인터페이스를 사용한다.
import { Action } from "redux";

// 인자로 받을 리듀서의 키 밸류 맵이다.
// 리덕스의 액션 타입의 기본은 any로 되어있기 때문에 string으로 만든 액션을 상속받아서 사용한다.
type ReducerMap<A extends Action<string>, S> = {
  // 액션을 상속받은 A의 `type`의 타입들을 키로 사용한다.
  // 리듀서 함수의 인자로 넘어가는 액션은 그 키 타입에 맞는 액선을 끄집어내서(MatchedAction) 사용한다.
  [AT in A["type"]]?: (state: S, action: MatchedAction<A, AT>) => S;
} & { [key: string]: (state: S, action: Action) => S }; // 객체의 키 접근을 위한 인덱스 시그니쳐

// 인자로 받은 액션들(A) 중에 액션타입(T)이 일치하는 타입만 내보내고 나머지는 지운다.
type MatchedAction<A, T> = A extends Action<T> ? A : never;

const handleActions = <S, A extends Action<string>>(
  reducerMap: ReducerMap<A, S>,
  defaultState: S
) => (state = defaultState, action?: A): S =>
  action && reducerMap[action.type]
    ? reducerMap[action.type](state, action)
    : state;

export default matchAction;

다음은 사용 예이다. 역시 원본과 유사하게 사용하면 된다. 단, 지금은 액션에 맞추어서 필터해두었기 때문에 해당하는 액션 타입에 맞는 액션이 함수의 인자로 들어온다.

const user = handleActions<UserActions, User>(
  {
    // 정의된 액션들에 맞는 타입만 객체 키값으로 사용가능하고, 인자로 넘겨지는 액션도
    // 그 키에 맞는 액션이 전달되기때문에 타입에 안전하다.
    [CHANGE_NAME]: (state, { payload }) => ({
      ...state,
      name: payload.name
    })
  },
  defaultState
);

여기까지 간단하게 redux-actions의 대체 함수를 만들어보았다. 사실 구현되지 않은 기능들이 리덕스 액션에 많이 존재하지만 간단한 사용 용도로는 이정도 구현도 적절하리라 생각한다. 필요에 따라서 추가로 구현하거나 하면 될 것 같다. 타입스크립트를 사용하면서 redux-actions를 그리워 하는 사람들에게 도움이 되었으면 좋겠다.

mobx-react v6 마이그레이션하기

2019-09-09T03:02:48+00:00

mobx-react는 observable한 상태들, computed로 계산된 결과를 메모이즈 해둘 수 있는 기능들 등 redux와는 다른 매력을 가지고 있는 라이브러리이다. 하지만 react가 16.8버전에 도입된 hooks와 호환이 안되는 문제가 발생하게 되었는데, 이 글에서는 그 문제가 무엇인지, mobx-react는 어떻게 그 방법을 해결했는지를 작성해보고 실제 코드에서 어떻게 마이그레이션 할지를 고민해본 내용을 작성해 볼 생각이다.

`mobx-react` v5의 문제점

이 버전이 가지고 있는 가장 큰 문제는 컴포넌트들의 상태 공유를 하기 위하여 legacy context를 사용한다는 점이다. 레거시 컨텍스트는 이후 react에서 제거될 기능이기 때문에 계속해서 사용한다면 리액트 버전을 최신으로 유지하는 데에 문제가 될 여지가 있다.

두번째 문제점은 observer함수 자체가 클래스를 위해서 만들어진 함수이기 때문에 현재 hook과는 호환되지 않는 문제점이다.

hook을 사용하고싶어서 함수 컴포넌트로 코드를 작성하고 난 다음, 코드를 실행시키면 클래스 컴포넌트에서 hook을 사용할 수 없다는 에러 메시지를 본 것은 필자 뿐만 아니라 많은 사람들이 겪었을 문제라고 생각한다. mobx에서는 아래의 코드 처럼 함수일 경우에는 클래스로 래핑하여 재귀적으로 호출함으로서 해결하였다.

export function observer(arg1, arg2) {
  // ... 기타 내용들
  // Stateless function component:
  // If it is function but doesn't seem to be a react class constructor,
  // wrap it to a react class automatically
  if (
    typeof componentClass === "function" &&
    (!componentClass.prototype || !componentClass.prototype.render) &&
    !componentClass.isReactClass &&
    !Component.isPrototypeOf(componentClass)
  ) {
    const observerComponent = observer(
      class extends Component {
        static displayName = componentClass.displayName || componentClass.name;
        static contextTypes = componentClass.contextTypes;
        static propTypes = componentClass.propTypes;
        static defaultProps = componentClass.defaultProps;
        render() {
          return componentClass.call(this, this.props, this.context);
        }
      }
    );
    hoistStatics(observerComponent, componentClass);
    return observerComponent;
  }
  // 기타 내용들
}

리액트에 hooks이 들어온 지금 Stateless Function Component는 더이상 맞지 않는 주석이다. 함수 컴포넌트를 클래스의 랜더 함수에서 실행시켜 리턴하니 경고가 나오고 클래스의 안쪽이므로 자연스럽게 hook을 사용할 수 없게 된다.

이런 문제점은 mobx커뮤니티에서 문제가 되었고 이런 구조들을 개선하기 위해서 라이브러리 전체를 다시 쓰게 되는데, 그래서 나온 것이 mobx-react-lite이다.

`mobx-react-lite`

이 라이브러리는 완전히 다시 쓰여진 모브엑스의 새 버전이다. 그렇다면 mobx-react는 어떻게 되는가? 다음 버전인 v6으로 업데이트 되었지만, 내부는 기존 라이브러리의 호환성을 유지하기 위해서 v5의 함수들을 이 라이브러리로 구현해 둔 것으로 앞으로 주력 개선사항은 mobx-react-lite에서 개발될 것으로 생각이 된다.

mobx-react-lite는 hooks의 도입과 legacy context의 제거 이 두가지를 가장 염두에 둔 것으로 보인다. 이 새 라이브러리가 문제를 어떻게 해결했는지 살펴보자.

`legacy context`

redux의 철학은 single source of truth이다. 따라서 라이브러리에서 관리되는 모든 상태들이 하나의 스토어에 들어있어야 한다. 그렇기 때문에 라이브러리에서 관리되는 프로바이더가 필연적이였을 것이라고 생각한다. 하지만 mobx는 그렇지 않다. 관심사에 따라서 여러개의 스토어를 만들고 필요에 따라서 컴포넌트위에 프로바이더를 만들어서 사용할 수 있다.

새 버전에서는 레거시 컨텍스트를 들어내면서 이 철학에 맞는 가장 간단한 방법을 사용했다.

컨텍스트의 컨셉이 너무나도 간단해서 라이브러리에 추가로 필요한 값들이 없었습니다. 만약 모든 앱을 hook으로 관리하도록 마이그레이션 하는데 성공한다면, Mobx에서 제공하는 Provier가 필요하지 않고 심지어 더 많은 제어가 가능해집니다. (원문)

필요하면 직접 만들어 쓰라는 말이다. 실제로 그 방법은 너무나도 간단하다.

const UserContext = createContext(null);

const UserProvider = ({ children }) => {
  // class로 개발된 mobx 스토어든, mst로 작성된 스토어든, 여기서 초기화를 시켜준다.
  const [userStore] = useState(() => new UserStore());

  // 스토어 생성 비용이 크지 않다면 이렇게 사용해도 된다.
  const userStore = useRef(new UserStore()).current;

  // 공식 문서에서는 useMemo는 리액트에서 랜덤하게 값을 버려버리기 때문에 사용하지 말라고 권장하고 있다.
  // const userStore = useMemo(() => new UserStore(), []);

  return (
    <UserContext.Provider value={userStore}>{children}</UserContext.Provider>
  );
};

// 값이 필요하다면 그냥 useContext를 사용하면 된다.
const UserProfile = () => {
  const userStore = useContext(UserContext);

  // useObserver에 대해서는 아래에 설명이 되어있다.
  return useObserver(() => (
    <div>
      {userStore.name} - {userStore.age}
    </div>
  ));
};

이렇게 함으로서 mobx는 inject를 사용할 필요가 없어졌다. 간결하게 작성할수 있으며 context를 이용하기 때문에 타입스크립트의 타입 추론도 더 잘 받을수 있게 되었다.

사실 mobx-react-lite가 훅을 어떻게 사용하는지 들여다본다면 Provider의 존재조차 필요가 없다. 자세한 내용은 hook을 설명하면서 상세히 들여다 보겠다.

`hooks`

mobx-react에서 많은 훅이 추가가 되었지만 가장 눈여겨 볼 만한 훅은 useObserver이다. 사실상 이 훅이 mobx와 리액트를 이어주는 가장 핵심적인 hook이기 때문이다.

새로 추가된 useLocalStore같은 함수들은 공식 문서를 보면 사용법이 잘 나와있기 때문에 따로 확인하고 넘어가지 않겠다.

핵심적인 내용을 위해서 몇 가지 내용을 제거한 코드를 보자. mobx의 reaction을 알고 있다면 꽤 간단하게 짜여져 있다.

우선 mobx의 Raction에 대해서 짚어보고 넘어가자. 공식 문서에 있는 reaction과는 살짝 다르다. reaction은 외부로 노출된 함수이고 Reaction은 실제로 기능을 하는 클래스라고 생각하면 될 것 같다. 아래는 Reaction코드의 주석에 쓰여져 있는 동작 과정이다.

 * The state machine of a Reaction is as follows:
 *
 * 1) 인스턴스가 생성된 뒤에는 reaction은 반드시 runReaction을 호출하거나 스케줄링함으로서 시작되어야 합니다.
 * 2) `onInvalidate`는 `this.track(someFunction)`를 호출하는 함수여야 합니다.
 * 3) `someFunction`에서 접근되는 모든 옵저버블은 이 reaction에 의해서 관찰되어집니다.
 * 4) Reaction의 someFunction의 디펜던시가 변경되게 되면 이 다음 실행때 리스케줄됩니다. 디펜던시가 변경되었을때 `isScheduled`가 ture로 변경됩니다.
 * 5) `onInvalidate`가 실행되고, 1번으로 되돌아갑니다.

// 원본 코드
// https://github.com/mobxjs/mobx-react-lite/blob/master/src/useObserver.ts
import { Reaction } from "mobx";
import { useDebugValue, useRef, useState } from "react";

import { printDebugValue } from "./printDebugValue";
import { isUsingStaticRendering } from "./staticRendering";

export function useObserver<T>(
  fn: () => T,
  baseComponentName: string = "observed"
): T {
  // 강제로 업데이트하는 setState를 만들어준다.
  // 업데이트의 주체가 리액트가 아닌 상태관리 컴포넌트에서 흔히 사용되는 패턴이다.
  const [, setTick] = useState(0);

  const forceUpdate = useCallback(() => {
    setTick(tick => tick + 1);
  }, []);

  // reaction을 만들어 준 다음, 초기화를 시켜준다.
  // 이때, reaction이 일어날때마다 강제로 리랜더를 시켜준다.
  const reaction = useRef<Reaction | null>(null);
  if (!reaction.current) {
    reaction.current = new Reaction(`observer(${baseComponentName})`, () => {
      forceUpdate(); // 리랜더가 되므로 아래 라인의 track을 다시 호출한다. `onInvalidate`의 조건을 충족시킴
    });
  }

  // cleanup 함수를 만들어주고 등록해준다.
  const dispose = () => {
    if (reaction.current && !reaction.current.isDisposed) {
      reaction.current.dispose();
    }
  };

  useEffect(() => dispose, []);

  // reaction의 안쪽에 인자로 받은 함수를 실행시켜주고, 스케줄링한다.
  // 따라서, 인자로 넘겨주는 함수의 안쪽에 observable이 존재하면 이 값이 변경될때마다 리랜더가 되는 것이다.
  // 그렇기 때문에 useObserver로 넘겨주는 값들이 비구조화 할당을 하여 주소가 아닌 값이 된다면 값을 추적하지 못하는 것이다.
  // render the original component, but have the
  // reaction track the observables, so that rendering
  // can be invalidated (see above) once a dependency changes
  let rendering!: T;
  let exception;
  reaction.current.track(() => {
    try {
      rendering = fn();
    } catch (e) {
      exception = e;
    }
  });
  if (exception) {
    dispose();
    throw exception; // re-throw any exceptions catched during rendering
  }
  return rendering;
}

눈치가 빠른 사람들은 왜 Provider가 필요없는지 알 수 있을 것이다. 업데이트 로직이 훅 안에 전부 존재함으로서 더이상 context를 통해서 상태를 전달받을 필요가 없어졌다. 단지 useObserver안에 observable한 값만 존재하면 된다. 이 hook이 알아서 변경을 추적해서 리랜더를 한다. 이렇게 된다면 store를 싱글톤으로 만들고, 컴포넌트에서 그냥 가져다가 쓰는 방식으로 사용할 수도 있다. 물론 mobx 공식 문서에서는 테스트를 위해서라면 권장하지 않는다고 쓰여져 있다.

마이그레이션하기

이제 어느정도 두 버전 사이의 차이를 알아보았으니, 점진적인 마이그레이션을 위해서 mobx가 어떤 방법을 내놓았는지 보자.

눈여겨볼 만한 변경점은 mobx-react v6의 Provider의 변화이다. 공식 문서에 써져있던대로 거의 손을 대지 않고 react의 context를 그대로 사용하고 있다. 역시 불필요한 코드는 제거했다.

// 원본 코드
// https://github.com/mobxjs/mobx-react/blob/master/src/Provider.js
import React from "react";

// 컨텍스트를 만든다.
export const MobXProviderContext = React.createContext({});

export function Provider({ children, ...stores }) {
  // 상위 컨텍스트의 스토어들 가져온다.
  const parentValue = React.useContext(MobXProviderContext);
  // 부모의 컨텍스트 값과 새로운 스토어들을 가져와 합쳐준다.
  const value = React.useRef({
    ...parentValue,
    ...stores
  }).current;

  return (
    <MobXProviderContext.Provider value={value}>
      {children}
    </MobXProviderContext.Provider>
  );
}

Provider.displayName = "MobXProvider";

몇 줄만으로 Provider의 구현이 끝났다. 마찬가지로 사용도 간단하다. MobxProviderContext는 상위 컨텍스트의 값을 가져와서 사용하기 때문에 컴포넌트에서 호출만 하면 된다. Inject도, observe로 감싸줄 필요가 없다.

const UserProfile = () => {
  // Inject에 대응하는 부분이다.
  const { userStore } = useContext(MobxProviderContext);

  // 이렇게 하면 타입스크립트의 느낌표(!) 지옥에서도 빠져나올 수 있다.
  if (!userStore) {
    throw "userStore가 없습니다";
  }

  // observe에 대응하는 부분이다.
  return useObserver(() => (
    <div>
      {userStore.name} - {userStore.age}
    </div>
  ));

  // 혹은, 랜더 시에 필요한 특정 값만 필요하다면 이렇게도 사용할 수 있다.
  const businessLogicProfile = useObserver(() => {
    if (!userStore.public) {
      return "조회할수 없는 프로필입니다";
    }
    return `${userStore.name} - ${userStore.age}`;
  });

  return <div>{businessLogicProfile}</div>;
};

mobx는 그 자유도 때문에 프로젝트 구조가 매우 다양할 것이기 때문에 적절한 hook을 작성하여 스토어를 가져다가 쓰면 될 것 같다. 기본 구현이 매우 간단하기 때문이다.

그러면 새로운 코드는 어떻게 짜면 좋을까? 간단하게나마 예제를 작성해 보았다. 가장 좋았던 점은 더이상 타입스크립트의 타입 추론을 !를 사용하여 강제시킬 필요가 없다는 점인것같다.

useObserver의 사용이 살짝 불편한 감이 없지 않아 있는것 같지만 어쨋든 새로운 기능을 사용해보는 것은 언제나 즐거운 일인 것 같다.

지금까지 간략하게 mobx-react의 내부적인 변화를 살펴보고 어떻게 새 변화에 맞추어 기존 코드베이스에 적용할지를 작성해보았다. 마이그레이션 부분은 너무나도 많은 자유도가 있기 때문에 내용이 부족한 부분이 있다고 생각되지만 고민하고 있는 사람들에게 많은 도움이 되었으면 좋겟다.

redux-saga와 typescript 편하게 사용하기

2019-06-04T06:02:15+00:00

나는 리덕스 사가의 팬이다. 작은 단위로 코드를 쪼개놓아 재사용성이 늘어나는 것도 좋고, 개발자의 코드가 개발자가 실행 시점을 정의하는게 아닌 사가가 실행의 주체가 된다는 점도 좋다. 작년 말부터 사가를 쓰기 시작해서 어느정도 비동기 호출이 있는 프로젝트에는 항상 사가를 넣어두고 시작할정도로 지금은 사가 없이는 살수 없는 사람이 되어버렸다.

그러던 중 TypeScript를 알게 되었고, redux-saga와 TypeScript를 함께 쓰면서 꽤 만족스러운 패턴을 작성하게 되어 이것을 소개하고자 글을 작성하게 되었다.

`FetchEntity`

사가를 쓰면서 가장 즐겨 썼던 패턴은 redux-saga의 real-world-example에서의 fetchEntity함수였다. 나는 내가 사용하기 편하게 조금 다른 방식으로 작성했다.

const fetchEntity = (entitiy, apiFn) =>
  function*(...params) {
    yield put(entitiy.request());
    try {
      const data = yield call(apiFN, ...params);
      yield put(entity.success(data));
    } catch (err) {
      yield put(entitiy.failure());
    }
  };

비동기 호출의 단위를 entity로 관리하고 이 호출의 루틴을 함수로 만들어 재사용성을 높인 함수이다.

여기서 안보이는 entity는 이렇게 생겼다. 역시 개인적으로 사용하기 편하게 간략하게 작성했다.

export const user = {
  request: () => ({ type: 'USER_REQUEST' }),
  success: user => ({ type: 'USER_SUCCESS', payload: { user } }),
  failure: () => ({ type: 'USER_FAILURE' }),
};

정리하자면 각 비동기 단계의 action을 정의한 것이 entitiy인 것이다. 매번 이렇게 세가지 액션을 만들어주는 것이 귀찮으므로 함수를 작성해서 사용하자.

const createEntityAction = entity => ({
  request: () => ({ type: entity.REQUEST }),
  success: data => ({ type: entitiy.SUCCESS, payload: data }),
  failure: () => ({ type: entity.FAILURE }),
});

이 패턴을 사용하면 간단한 비동기 호출은 정말 편하게 작성할 수 있다. user의 정보를 가져온다고 생각해보자.

const fetchUserAPI = async userId => (await axios.get(`/user/${userId}`)).data;

// Action Types
const FETCH_USER = 'FETCH_USER';
const USER = {
  REQUEST: 'USER_REQUEST',
  SUCCESS: 'USER_SUCCESS',
  FAILURE: 'USER_FAILURE',
};

// action. 컴포넌트에 커넥트 시켜서 사용
const fetchUser = id => ({ type: FETCH_USER, payload: { id } });

// Entity
export const user = createEntityAction(USER);

const fetchUserSaga = fetchEntity(user, fetchUserAPI);

function* fetchUserWatcher() {
  const {
    payload: { id },
  } = yield take(FETCH_USER);
  yield call(fetchUserSaga, id);
}

fetchEntity패턴을 사용하면 기본적인 비동기 호출은 대부분 대응이 가능하다. fetchUserWatcher에서는 call을 사용했지만, 상황에 따라서 fork나, 혹은 watcher자체를 takeLatest나 takeLeading으로 사용해도 무방하다.

TypeScript

이하는 타입스크립트 3.4버전 이상을 기준으로 작성되었습니다.

위의 패턴에서 타입스크립트를 붙여보자. 개인적으로는 사용하는 쪽에서 제네릭을 최대한으로 사용하지 않는 형태로 작성하는 것을 선호한다. 개발자가 통제할 수 없는 부분에서만 제네릭을 넣는 것이 사용성과 생산성을 높이는 것이라고 생각하기 때문이다.

우선 API호출을 하는 함수의 타입 지정을 해보자. 크게 복잡한 타입은 아니지만, 코드 길이를 줄이는데 도움을 준다. 비동기 데이터를 리턴하는 함수의 타입이다.

type APIEndpoint<P extends any[], R> = (...p: P) => Promise<R>;

그 다음은 api 호출을 하는 함수를 작성 해보자.

const fetchUserAPI = async (userID: number) =>
  (await axios.get<IUser>(`/user/${id}`)).data;

인터페이스 IUser는 여기서 중요한 부분이 아니라고 생각되어 작성하지 않았다. 함수는 간단하다. userID를 받아서 IUser를 서버에서 받아온 후 그것을 리턴 하는 함수이다.

이제 액션 타입을 작성 해보자.

// Action Type
const GET_USER = 'GET_USER' as const;
const USER = {
  REQUEST: 'GET_USER_REQUEST',
  SUCCESS: 'GET_USER_SUCCESS',
  FAILURE: 'GET_USER_FAILURE',
} as const;

주목해 보아야 할 부분은 as const의 사용이다. as const구문은 타입스크립트 3.4버전에서 추가된 기능이다. 상세한 문법의 스펙은 다음과 같다.

리터럴의 타입은 확장될 수 없다('hello'에서 string으로 확장되는 행위 불가능)
오브젝트 리터럴은 readonly속성을 가지게 된다.
배열 리터럴은 readonly 튜플이 된다.

따라서, 이 객체나 액션 타입의 선언은 그 자체로 타입과 비슷하게 동작하게 된다. 이렇게 처리하게 되면 리듀서에서 스위치케이스 문을 작성하는 데에 아주 유용하게 사용할 수 있다.

이제 액션 크리에이이터를 작성해 보자. 우선 getUser를 먼저 작성했다.

const getUser = (userId: string) => ({ type: GET_USER, payload: { userId });
type GetUser = ReturnType<typeof getUser>;

ReturnType은 타입스크립트 2.8버전에서 추가된 타입으로, 함수의 반환값을 잡아준다.

3.4버전 as const가 없었을 때에는 액션크리에이터에 사용이 불가능했지만, as const로 액션크리에이터의 타입을 잡아주는데 굉장히 편한 타입이 되었다.

// GET_USER에 as const 가 없을떄
type GetUser = {
  type: string;
  payload: {
    userId: string;
  };
};
// GET_USER에 as const가 있을때
type GetUser = {
  type: 'GET_USER';
  payload: {
    userId: string;
  };
};

그 다음은 entity를 만들어주는 함수를 작성해보자. 이번에는 자바스크립트로 작성했을때와는 모양이 조금 다르다.

// 엔티티 타입을 위한 인터페이스
interface IEntity<R, S, F> {
  REQUEST: R;
  SUCCESS: S;
  FAILURE: F;
}

// 액션을 만들어 내는 데에 필요한 것은 DATA타입이다.
// SUCCESS액션의 리턴타입에 타입 지정을 해주기 해주기 위해서 반드시 필요하다.
// 이때, api를 모르는 상태에서는 반드시 제네릭으로 넣어주는 것이 필요한데,
// 제네릭을 넣어주는 방법을 우회하기 위해서 api와 액션을 함께 묶어 객체로 만들어주는 방법을 택했다.
const createEntityAction = <R, S, F, PARAM extends any[], DATA>(
  entitiy: IEntity<R, S, F>,
  api: ApiEndpoint<DATA, PARAM>
) => ({
  ACTION: {
    REQUEST: () => ({ type: entitiy.REQUEST }),
    SUCCESS: (data: DATA) => ({ type: entitiy.SUCCESS, payload: data }),
    FAILURE: () => ({ type: entitiy.FAILURE })
  },
  API: api
})

// 타입을 끄집어 내기 위한 헬퍼 타입
interface IEntityAction {
  ACTION: {
    REQUEST: (...p: any[]) => any;
    SUCCESS: (...p: any[]) => any;
    FAILURE: (...p: any[]) => any;
    [key: string]: (...p: any[]) => any;
  };
  API: ApiEndpoint<any, any>;
}

// 액션 타입 추출을 위한 타입
// ACTION의 각 단계의 리턴타입을 가져왔다.
EntityAction<T extends IEntityAction> = ReturnType<T['ACTION'][keyof T['ACTION']]>;

const userEntity = createEntityAction(USER, getUserApi);
type UserEntity = EntityAction<typeof userEntity>;

액션이 api에서 리턴하는 타입을 반드시 알고 있어야 하기 때문에 api를 인자로 넣어 주었다. 여러 가지 방법을 시도해 보았지만, 저 세가지 함수를 자동으로 만들어 주기 위해서는 어떤 부분에서 api에서 리턴하는 타입을 반드시 제네릭으로 넣어주어야 했기 때문에 다른 방법을 찾았던 것이 이 방법 이였다.

Entity가 api 앤드포인트 정보를 포함함에 따라서 fetchEntity의 모양도 달라지게 된다.

// 두 가지를 인자로 받는 대신에 객체 하나를 받는것으로 변경했다.
function fetchEntity<T extends IEntityAction>({ ACTION, API }: T) {
  return function*(...p: Parameters<T['API']>) {
    try {
      yield put(ACTION.REQUEST());
      const data = yield call(API, ...p);
      yield put(ACTION.SUCCESS(data));
    } catch {
      yield put(ACTION.FAILURE());
    }
  };
}

Parameters<T>는 ReturnType<T>와 비슷하게 동작한다. 함수에서 인자의 타입을 추출하는 유틸리티 타입인데, API함수에서 받는 인자를 그대로 리턴되는 함수에서 받기 위해서 사용했다.

이렇게 작성했으면 이제 사가를 작성하면 된다.

const getUserSaga = fetchEntity(userEntity);

function* getUserWatcher() {
  const {
    payload: { userId },
  }: GetUser = yield take(GET_USER);
  // fetchEntity가 타입을 제대로 지정해주기 때문에 userId인자의 타입까지 확인해준다.
  yield call(getUserSaga, userId);
}

여기까지 자바스크립트로 작성된 패턴을 타입스크립트로 다시 작성해 보았다. 부족한 실력이지만 이 글을 통해서 사가와 타입스크립트로 프로젝트를 작성하는 사람들에게 도움이 되었으면 좋겠다.

혹시 오타나 잘못된 내용이 있다면 피드백 주시면 감사하겠습니다.

전체 코드는 이곳에서 확인할 수 있습니다.

블로그 첫 글

2019-03-18T07:07:15+00:00

블로그의 첫 글입니다.

Memo

Typescript에서 redux-actions대체하기

Redux-Actions

무엇이 문제인가?

대안?

직접 만들기

handleActions

handleActions

mobx-react v6 마이그레이션하기

mobx-react v5의 문제점

mobx-react-lite

legacy context

hooks

마이그레이션하기

redux-saga와 typescript 편하게 사용하기

FetchEntity

TypeScript

블로그 첫 글

`Redux-Actions`

`handleActions`

`handleActions`

`mobx-react` v5의 문제점

`mobx-react-lite`

`legacy context`

`hooks`

`FetchEntity`