PageとView

UIを何らかの要素にモジュール分割したい場合に、よくPageとViewという概念を使います。 UIを書く際にどのような単位でモジュール化するかを予め決めておくと、〇〇Pageや〇〇Viewなどサフィックスをつけて書くだけでコードを整理できるので便利ですよね。

Page

あるルーティングのルートとなるようなUI単位のことをPageと呼んでいます。

例えば、/signinでアクセスされるような画面はSignInPageとして設計します。

Pageはルーティングを適切に管理する責務を持っており、SignInPage内でサインインされた場合に、ホーム画面等に適切に画面遷移を行う必要があります。

View

ルーティングに関係なく、機能単位で区切れるようなUI単位の場合はViewと呼んでPageと区別しています。

例えば/authのようなルートがあって、そこにサインイン画面とサインアップ画面を表示したい場合、AuthPageという画面を設計して、SignInView, SignUpViewというViewを表示できるようにします。

SignInViewには、サインインするために必要な機能を実装します。 サインインした後にどのページに遷移するかなどの実装はAuthPageの責務になります。

なぜPageとViewを分けるのか

最初のうちは、PageとViewに分割するのは一見すると無駄な分割に思えるかもしれません。 しかしコードが大きくなってきて、UIを何らかのルールに従って分離したいとなった場合に、PageとViewはいい分割点となります。

Pageの関心はルーティングにあります。ここのViewの動きに従って適切なルーティングを実行することが主な役割です。 Pageがルーティングに集中することで、Viewのあちこちにルーティングのコードが散らばるのを防いでアプリの動きを追跡しやすくします。

またViewはPageに依存しないようなコードにすることで、Viewの再利用可能性が向上します。 例えば、スマホサイズのページとタブレットサイズのページを表示させる場合に、ViewのレイアウトをPageによって切り替えるような実装をすることも可能になります。