aspidaのエンドポイントが返すUserとかArticleのような型をReact/Vueのファイルでimportしたい場合のベストプラクティス的なものを2パターン紹介します。
~がプロジェクトルートのパスエイリアスとして登録されてる前提で書きます。
前提
Userに関するエンドポイントのファイルが二つ
-
/apis/users/index.ts(GETでUserのリストが得られる) -
/apis/users/_userId.ts(パス変数userIdで特定のUserが得られる)
※/apis/users.tsと/apis/users/_userId.tsの組み合わせで作ると/apis直下に同名ファイルとディレクトリが出来てしまってエンドポイント名のusersに変更があった際2か所変更が発生するので/apis/usersディレクトリにまとめるのが良い
Userを描画するtsxファイルが一つ
/pages/example.tsx
1.リストを返すエンドポイントのファイルでexport
リストを返すエンドポイントのファイル/apis/users/index.tsでUser型をexportします。
/apis/users/index.ts
export type User = {
id: number
name: string
}
export type Methods = {
get: {
resBody: User[]
}
}
/apis/users/_userId.ts
import { User } from './'
export type Methods = {
get: {
resBody: User
}
}
/pages/example.tsx
import { FC } from 'react'
import { User } from '~/apis/users'
type UserProps = { user: User }
const App: FC<UserProps > = ({ user }) => <h2>ユーザー名：{user.name}</h2>
export default App
メリット
- エンドポイントと一緒に型を書いていくのでラク
- エンドポイントを削除したときに不要になった型を消し忘れることがない
デメリット
- エンドポイントが増えるとtsxでimportしたい型を探すのが面倒
- 定義ファイルがバラバラなので型ごとにimportが必要
小～中規模はこの方法が楽だと思います。
2.typesファイルにまとめてexport
aspidaが変換対象から無視する/apis/@types.tsでまとめてexportも出来ます。
/apis/@types.ts
export type User = {
id: number
name: string
}
/apis/users/index.ts
import { User } from '~/apis/@types'
export type Methods = {
get: {
resBody: User[]
}
}
/apis/users/_userId.ts
import { User } from '~/apis/@types'
export type Methods = {
get: {
resBody: User
}
}
/pages/example.tsx
import { FC } from 'react'
import { User } from '~/apis/@types'
type UserProps = { user: User }
const App: FC<UserProps > = ({ user }) => <h2>ユーザー名：{user.name}</h2>
export default App
メリット
- 複数の型をまとめてimportできる
- さらに増えても
/apis/@types/ディレクトリに複数ファイルを置いて/apis/@types/index.tsでまとめてexportできる
デメリット
- 使われなくなった型を消し忘れる
- エンドポイントを定義するときにファイルの行き来がちょっと面倒
中～大規模はこの方法がおすすめ。
/types.tsではなく/apis/@types.tsが良い理由は、API由来の型であることがわかりやすくなることと、aspidaの隠し機能と相性が良いからです。
aspidaの隠し機能まとめ - Qiita