React TypeScript Cheatsheet

React TypeScript Cheatsheet를 알고 계셨나요?
React와 Typescript로 개발하면서 알고 있던 타입과 이렇게 쓸 수 있구나를 함께 알아가기 위해 준비해봤습니다.
10명중에 10명이 알 만한 타입들은 제외했습니다.

Component Props

Basic Prop Types Examples

type AppProps = {
  /** any non-primitive value - 어떤 properties에도 접근 불가 (일반적이지 않지만 placeholder로서 사용됨) */
  obj2: object;
  /** 필수 속성이 없는 인터페이스 - (`React.Component<{}, State>`와 같은 경우를 제외하곤 일반적이진 않음) */
  obj3: {};
  /** 동일한 유형의 속성을 여러개 갖고 있는 객체 */
  dict1: {
    [key: string]: MyTypeHere;
  };
  dict2: Record<string, MyTypeHere>; // dict1과 동일
  
  /** function type syntax that takes an event (VERY COMMON) */
  onChange: (event: React.ChangeEvent<HTMLInputElement>) => void;
  /** alternative function type syntax that takes an event (VERY COMMON) */
  onClick(event: React.MouseEvent<HTMLButtonElement>): void;
  /** any function as long as you don't invoke it (not recommended) */
  onSomething: Function;
};

 

object as the non-primitive type

object non-primitive (not number, string, boolean, symbol, null or undefined.) 리액트에선 거의 사용할 일 없습니다.
 

Empty interface, {} and Object

An empty interface, {} and Object all represent "any non-nullish value"—not "an empty object"

interface AnyNonNullishValue {}
let value: AnyNonNullishValue;

// 굿굿
value = 1;
value = "foo";
value = () => alert("foo");
value = {};
value = { foo: "bar" };

// 에러
value = undefined;
value = null;

 

Useful React Prop Type Examples

export declare interface AppProps {
  children?: React.ReactNode; // Best, React가 렌더링할 수 있는 모든 것을 허용합니다
  childrenElement: React.JSX.Element; // 단일 React 요소
  style?: React.CSSProperties; // 스타일 속성을 전달하기 위한 것
  onChange?: React.FormEventHandler<HTMLInputElement>; // 폼 이벤트! 제네릭 매개변수는 이벤트 타겟의 유형입니다
  // 더 많은 정보: https://react-typescript-cheatsheet.netlify.app/docs/advanced/patterns_by_usecase/#wrappingmirroring
  props: Props & React.ComponentPropsWithoutRef<"button">; // 버튼 요소의 모든 속성을 흉내내어 ref를 명시적으로 전달하지 않음
  props2: Props & React.ComponentPropsWithRef<MyButtonWithForwardRef>; // MyButtonForwardedRef의 모든 속성을 흉내내어 ref를 명시적으로 전달함
  
  // 이 부분은 cheatSheet에는 없지만 유용하게 쓸만한 props
  React.PropsWithChildren
  React.PropsWithRef
  ComponentProps<typeof ComponentName> // interface를 노출하지 않고 사용 가능
}

• React.JSX.Element -> Return value of React.createElement
• React.ReactNode -> Return value of a component

 

Types or Interfaces?

 

TL;DR

Use Interface until You Need Type - orta.

More Advices

• 라이브러리 또는 타사 주변 유형 정의를 작성할 때 항상 공용 API 정의에 대한 Interface를 사용하십시오.
  이렇게 하면 일부 정의가 누락된 경우 소비자가 선언 병합을 통해 해당 정의를 확장할 수 있습니다.
• 일관성을 유지하고 더 제한적이기 때문에 React 구성 요소 Props 및 State에 Type을 사용하는 것을 고려해보세요.
  extends가 없어서 간결한 경우가 있습니다 (type MyType = TypeA | TypeB).

 

Functional Components

// 프롭스의 타입을 선언합니다 - 더 많은 예제는 "Typing Component Props" 참조
type AppProps = {
  message: string;
}; /* 내보내기할 경우 소비자가 확장할 수 있도록 `interface` 사용 */

// 함수 컴포넌트를 선언하는 가장 간단한 방법; 반환 타입은 추론됩니다.
const App = ({ message }: AppProps) => <div>{message}</div>;

// 실수로 다른 유형을 반환하는 경우 오류가 발생하도록 반환 타입에 주석을 달 수 있습니다.
const App = ({ message }: AppProps): React.JSX.Element => <div>{message}</div>;

// 타입 선언을 인라인으로 작성할 수도 있습니다. 프롭 타입에 이름을 지정하지 않지만 반복적으로 보일 수 있습니다.
const App = ({ message }: { message: string }) => <div>{message}</div>;

// 또는 `React.FunctionComponent` (또는 `React.FC`)을 사용할 수 있습니다.
// 최신 React 타입과 TypeScript 5.1에서는 주로 스타일적인 선택이며, 그렇지 않으면 권장되지 않습니다.
const App: React.FunctionComponent<{ message: string }> = ({ message }) => (
  <div>{message}</div>
);

오늘날 일반적인 합의는 React.FunctionComponent(또는 약칭 React.FC)이 필요하지 않다는 것입니다. React 17이나 5.1 미만의 TypeScript를 사용하고 있다면 오히려 말려주세요. https://github.com/gndelia/codemod-replace-react-fc-typescript 를 보면 알겠지만 이를 지우려는 노력도 있습니다.
우선 이유는 다음과 같습니다.

• children을 내포하고 있습니다. 그래서 모든 컴포넌트들이 children을 강제로 갖고 있게 됩니다.
• generic을 지원하지 않습니다.
• defaultProps(componentA.defaultProps = {...})와 정상적으로 호환되지 않습니다.

 

Hooks

useState

많은 경우에 null을 초기값으로 갖는 경우는 다음과 같이 정의할 수 있습니다.

const [user, setUser] = useState<User | null>(null);

// later...
setUser(newUser);

하지만 만약 초기값이 setup과 동시에 들어온다고 하고 값이 항상 있다고 생각된다면, 아래와 같이 사용할 수 있습니다. 대신 이후에 user가 User 타입을 갖도록 해야지 runtime 오류가 나지 않습니다.

const [user, setUser] = useState<User>({} as User);

// later...
setUser(newUser);

 

Troubleshooting Handbook: Types

Union Types and Type Guarding

{
    count: number | null;
}

union types는 간편하게 문제를 해결하는데 도움을 줍니다. 하지만 때로는 추가적인 안전 장치가 필요합니다.  A | B가 "A 또는 B"가 아니라 "A 또는 B 또는 둘다" 이기에 혼란스러운 경우가 존재합니다.

interface Admin {
  role: string;
}
interface User {
  email: string;
}

// 방법 1: use `in` keyword
function redirect(user: Admin | User) {
  if ("role" in user) {
    // use the `in` operator for typeguards since TS 2.7+
    routeToAdminPage(user.role);
  } else {
    routeToHomePage(user.email);
  }
}

// 방법 2: TS 2.7 이하 또는 in 으로 충분하지 않을 때
function isAdmin(user: Admin | User): user is Admin {
  return (user as any).role !== undefined;
}

 

Enum Types

typescript 에서도 공식적으로 인정했다는데요, 되도록이면 Enum 사용을 피하라는 말은 많이 나왔었습니다. (예시, 라인 Engineering) 말고도 다음과 같은 이유도 이야기합니다.

lit contribute guide에서도 enum을 금지합니다.

• Enum은 코드를 내보냅니다.

enum Direction {
  Up,
  Down,
  Left,
  Right,
}

var Direction;
(function (Direction) {
    Direction[Direction["Up"] = 0] = "Up";
    Direction[Direction["Down"] = 1] = "Down";
    Direction[Direction["Left"] = 2] = "Left";
    Direction[Direction["Right"] = 3] = "Right";
})(Direction || (Direction = {}));

모든 경우에 enum을 사용한다면 front-end와 back-end 파일이 비대해지고 번들이 생길 수 있습니다.

• 숫자 Enum은 안전하지 않습니다.

enum Direction {
  Up,
  Down,
  Left,
  Right,
}

declare function move(direction: Direction): void;

move(30);
// ☝️ This is totally ok! 😱

 

• 문자열 사용 또한 편하진 않습니다.

enum Status {
  Admin = "Admin",
  User = "User",
  Moderator = "Moderator",
}

declare function closeThread(threadId: number, status: Status): void;

closeThread(10, "Admin");
//              ^ 💥 This is not allowed!


closeThread(10, Status.Admin);
//              ^ You have to be explicit!

 
대안은 다음과 같습니다.

export declare type Position = "left" | "right" | "top" | "bottom";

const Direction = {
  Up: 0,
  Down: 1,
  Left: 2,
  Right: 3,
} as const;

const Status = {
  Admin: "Admin",
  User: "User",
  Moderator: "Moderator"
} as const;

 

Using Inferred Types

export 해서 내보낼 일이 없다면 inference는 정의하지 않아도 되서 최고의 선택이 될 수 있습니다.

const [state, setState] = useState({
  foo: 1,
  bar: 2,
}); // state's type inferred to be {foo: number, bar: number}

const someMethod = (obj: typeof state) => {
  // grabbing the type of state even though it was inferred
  // some code using obj
  setState(obj); // this works
};

const partialStateUpdate = (obj: Partial<typeof state>) =>
  setState({ ...state, ...obj });

// later on...
partialStateUpdate({ foo: 2 }); // this works

이미 사용하고 있던 타입들이 대부분이겠지만 조금이라도 가져갈 수 있던 정보가 있으면 좋겠습니다.