React Native × React Router v7 API通信の共通化で考えるべきこと

本スライドは、React NativeとWeb（React Router v7）間でのAPI通信の共通化について、その課題と解決策を解説。

一見、共通化は可能に思えるが、実際にはWebとNativeの環境の違い（SWR利用時の挙動、キャッシュの永続化、localhostの扱い、認証トークン保存場所など）により、共通化を深く進めるとhooksが肥大化するなどの困難に直面する。

結論として、共通化の目的は「同じコードにすること」ではなく「変更に強くすること」。
解決策としてOpenAPIを挟んだAPIクライアントとAtom Componentの「薄い共有」から始めると良いかも。

Transcript

1. Progress Map スー React Native × React Router v7 API通信の共通化で考えるべきこと
2. Progress Map スー React Native × React Router v7 API通信の共通化で考えるべきこと
3. 突然ですが、 Web Frontend 書いてますか？✋
4. 突然ですが、 Native App 書いてますか？✋
5. 突然ですが、 時代はAI Native ! 検証したいことも多くあるでしょう!
6. 突然ですが、 Web ←→ Native 同じ事業に見ることも増えてきました
7. 突然ですが、 APIは1つ クライアントは複数
8. 一見・・・ 色々共通化できそうに 見える世界ですね！
9. 一見・・・ • 共通化できそうに見えるもの ◦ fetch ◦ hooks ◦ cache ◦ UI Component etc…
10. 一見・・・ Web(ReactRouter)とNative(React Native) で RouterもAPI通信もかけるはずだ・・・
11. 一見・・・ それ本当か・・・？？？
12. 一見・・・ それ本当か・・・？？？ →だめでした
13. 一見・・・ それ本当か・・・？？？ →だめでした
14. 一見・・・ それ本当か・・・？？？ →だめでした →Remixと統合したため
15. 一見・・・ 救世主はいてですね・・・ Expo Routerさん
16. 一見・・・ 利用できる場合は 次のようなアーキテクチャに整理できる
17. 一見・・・ 救世主はいてですね・・・ Expo Routerさん
18. 一見・・・
19. 一方、現実は難しい • 起きやすい課題 ◦ 両者で欲しいカラムが微妙に異なる ◦ 共通化しようとして肥大化するhooks ◦ Nativeのみ必要な処理に対する if (isNative) ◦ ここまで深く共通化はしたくない
20. 一方、現実は難しい • 起きやすい課題 ◦ 両者で欲しいカラムが微妙に異なる ◦ 共通化しようとして肥大化するhooks ◦ Nativeのみ必要な処理に対する if (isNative) ◦ ここまで深く共通化はしたくない
21. では、どうするか？
22. 一見・・・ 救世主はいてですね・・・ Expo Routerさん 分離 Shareしない 腐敗防止層を挟んで利用 CaseByCase Atomなどのみ共有
23. 一見・・・ 救世主はいてですね・・・ Expo Routerさん 分離 Shareしない 腐敗防止層を挟んで利用＝ OpenAPIを挟む CaseByCase Atomなどのみ共有
24. 薄く共有する際の重要事項 • API Client（OpenAPI挟む） • Atom Component くらいで留めることになる
25. 薄く共有する際の重要事項 • API Client（OpenAPI挟む） • Atom Component くらいで留めることになる
26. OpenAPI を挟むなら Orval が便利 今回はMOSHの環境を前提とするため 元々利用していた Orvalも 活用することにした
27. Orval って何？ 元々利用していた Orvalも 活用することにした
28. Orval って何？ 元々利用していた Orvalも 活用することにした OpenAPIから方安全な APIクライアントを 自動生成するツール
29. Orval って何？ 対応しているクライアント • `swr` - SWR フック生成 • `react-query` - TanStack Query フック生成 • `axios` / `axios-functions` - Axios ベースのクライアント • `fetch` - Fetch API ベース • その他（vue-query, svelte-query, angular 等）
30. OpenAPI を挟むなら Orval が便利 Web側ではSWRが利用されている
31. OpenAPI を挟むなら Orval が便利 共通化したろ・・・！！！
32. 地味に躓く箇所 - SWR利用の場合 revalidateOnFocus, revalidateOnReconnect: Web専用
33. 地味に躓く箇所 - SWR利用の場合 →A. 公式ドキュメントに手動設定の回避ハンドリングがある →B. @nandorojo/swr-react-native を利用する revalidateOnFocus, revalidateOnReconnect: Web専用
34. 地味に躓く箇所 - SWR利用の場合 →A. 公式ドキュメントに手動設定の回避ハンドリングがある →B. @nandorojo/swr-react-native を利用する revalidateOnFocus, revalidateOnReconnect: Web専用 A
35. 地味に躓く箇所 - SWR利用の場合 →A. 公式ドキュメントに手動設定の回避ハンドリングがある →B. @nandorojo/swr-react-native を利用する revalidateOnFocus, revalidateOnReconnect: Web専用 ツライ
36. 地味に躓く箇所 - SWR利用の場合 →A. 公式ドキュメントに手動設定の回避ハンドリングがある →B. @nandorojo/swr-react-native を利用する revalidateOnFocus, revalidateOnReconnect: Web専用 B
37. 地味に躓く箇所 - SWR利用の場合 →A. 公式ドキュメントに手動設定の回避ハンドリングがある →B. @nandorojo/swr-react-native を利用する revalidateOnFocus, revalidateOnReconnect: Web専用 ツライ
38. 地味に躓く箇所 - SWR利用の場合 →@react-native-async-storage/async-storageで永続化 →providerにコードを書く必要はある デフォルトでインメモリキャッシュを使っている
39. 地味に躓く箇所 - SWR利用の場合 →@react-native-async-storage/async-storageで永続化 →providerにコードを書く必要はある デフォルトでインメモリキャッシュを使っている
40. 地味に躓く箇所 - SWR利用の場合 →@react-native-async-storage/async-storageで永続化 →providerにコードを書く必要はある デフォルトでインメモリキャッシュを使っている ツライ
41. 地味に躓く箇所 - SWR利用の場合 →react-native-mmkvで永続化 →providerにコードを書く必要はある いまならMMKVのほうがおすすめ 30倍早い
42. ReactQuery 利用の場合はどうか？
43. ReactQuery 利用の場合はどうか？
44. ReactQuery 利用の場合はどうか？ ま、マシなんじゃない・・・？
45. ReactQuery 利用の場合はどうか？
46. 地味に躓く箇所 ▪ localhostの扱い（Handling localhost'） • Web: localhost • iOS Simulator: 'localhost' OK • Android Emulator：'10.0.2.2' を使用
47. 地味に躓く箇所 ▪ localhostの扱い（Handling localhost'） • Web: localhost • iOS Simulator: 'localhost' OK • Android Emulator：'10.0.2.2' を使用
48. 地味に躓く箇所 ▪ localhostの扱い（Handling localhost'） • Web: localhost • iOS Simulator: 'localhost' OK • Android Emulator：'10.0.2.2' を使用 ツライが仕方ないね・・・
49. 地味に躓く箇所 ▪ 環境変数のプレフィックス （Environment Variable Prefixes） • Web (vite): 'VITE_'（ない場合はないが・・・） • Expo: 'EXPO_PUBLIC_'
50. 地味に躓く箇所 ▪ 認証トークンの保存場所（Auth Token Storage） • Web: 'httponly Cookie' (HE) • Native: 'Expo SecureStore"
51. Progress Map まとめ
52. なぜ起きるのか・・・？ Web と Native は大きく環境が違う という ”非情” な現実と戦う必要がある
53. まとめ 共通化＝同じコードにすることではない 本当の目的は 変更に強くすること
54. Progress Map その共通化で将来の工数 本当に下がりそう？
55. Progress Map 事業検証から入るなら 別リポジトリで 始めてみても良いかもよ？
56. Progress Map その上で考えるなら Orvalなどを使って APIクライアントを薄く 共有するところから始めよう