reactjs - Cómo organizar las definiciones de tipos en un proyecto de React usando Typescript

He estado usando TypeScript en mis proyectos durante un mes y hay algunas dudas con las que estoy luchando.

¿Existe un patrón/manera recomendada de organizar los tipos en la arquitectura del proyecto?

Supongamos que tenemos un contexto con las siguientes interfaces:

export type ToastMessageType = 'info' | 'success' | 'error';

export interface ToastMessageData {
  id: string;
  title: string;
  description: string;
  type: ToastMessageType;
}

export interface ToastsStateContextData {
  messages: ToastMessageData[];
}

export interface ToastsDispatchContextData {
  addToast: (message: Omit<ToastMessageData, 'id'>) => void;
  removeToast: (id: string) => void;
}

Y hay otro componente llamado ToastMessage que recibe una prop message y tiene el tipo de ToastMessageData:

interface ToastMessageProps {
  message: ToastMessageData;
  style: React.CSSProperties;
}

const ToastMessage: React.FC<ToastMessageProps> = ({ message, style }) => {

Siento que es extraño importar una interfaz desde un contexto dentro de un componente, así que algo está mal.

¿Qué me recomiendan?

Respuesta #1

Generalmente, si el alias de tipo/interfaz es específico solo para el componente, está bien escribirlo dentro del mismo archivo .tsx, ya que se pueden considerar como usados "localmente" para ese componente.

Sin embargo, puede haber escenarios en los que necesites reutilizar ese alias de tipo/interfaz en otros componentes u otros archivos de ayuda (por ejemplo, la interfaz del componente A extiende la interfaz del componente B). Para esto, será mejor almacenar el alias de tipo/interfaz en un archivo separado. Por ejemplo, podrías tener un directorio compartido que contenga todos los alias de tipo/interfaz comunes que se van a exportar.

- pages
  - ComponentA
  - ComponentB
- shared
  - interfaces
    - messages.interface.ts
    - geo.interface.ts
    // etc 
  - services
  - helper
  // etc

La principal ventaja de hacerlo es que podrás prevenir el riesgo de dependencias cíclicas, especialmente cuando descubres que estás escribiendo código en el que múltiples componentes están exportando e importando cosas entre sí.