URL・クエリパラメータ等の整理

[MaySoMusician]

時間割を見るだけのページ（生徒側を想定。以下「生徒役」ユーザー）と、時間割の編集が可能なページ（教員側を想定。以下「教員役」ユーザー）でURLを大別するとわかりやすいのではないか。

• ルートディレクトリ: 生徒役・教員役共通のページ
  • /: サービストップページ（兼 生徒役ログインページ）
  • /terms: 利用規約（閲覧のみ）ページ（現 /policy から /terms に変更予定 ）
  • /about: 紹介ページ？
• /student ディレクトリ: 生徒役用のページ群
  • /student: 時間割ページ（現 /classes ）
  • /student/lesson?id=: 各授業の詳細ページ（現 /lesson ）
• /teacher ディレクトリ: 教員役用のページ群
  • /teacher/login: 教員役ログインページ（現 /account/login ）
  • /teacher/signup: 教員役登録ページ（現 /user/signup ）
  • /teacher/signup/agree: 教員役 登録時利用規約同意ページ（現 /terms から /agree に変更予定 ）
    • ※ この階層構造が不可能そうなら /teacher/agree
  • /teacher/reset-password: 未使用・パスワードリセット（現 /account/resetPassword ）
    • ※ 名前の候補としては usernamerecovery forgotpassword reset など
  • /teacher/edit: 時間割を見て授業を登録したり編集したりするページ（現 /edit ）
  • /teacher/classes/new: 新クラス登録ページ（現 /user/registerClass ）
  • /teacher/classes/success: 新クラス登録完了ページ（現 /user/registered ）
  • /teacher/classes/select: クラス一覧・選択ページ（現 /user/classlist ）

各ページ名は

• 連結文字無し
• kebab-case
• UpperCamelCase(PascalCase)

が良いと思われる。lowerCamelCaseの例はあまり見られず、またnon-techなユーザーにはこのようなキャピタライズは自然に見えないだろう。
どのサイトでも、そもそも単語が複数にならないような工夫をしていた。

[MaySoMusician]

上記に伴い、ClassDataStoreも生徒役と教員役で別々のものを保持しておいたほうがよいのではないかと思われる

Edited: nuxt-link以外でのページ遷移で毎回初期化されるらしいので、生徒役と教員役でデータが混在することは無い模様。この観点としては今回は分離しなくても良さそう。（データ構造の観点からは別途議論）

[MaySoMusician]

新旧対応表

現在のルーティング	変更案
/	/
/policy → /terms	/terms
/terms → /agree	/teacher/signup/agree
/account/login	/teacher/login
/account/resetPassword	/teacher/reset-password (※他のページ名案: usernamerecovery forgotpassword reset)
/classes	/student
/edit	/teacher/edit
/lesson?lessonId=	/student/lesson?id=
/user/classlist	/teacher/classes/select
/user/registerClass	/teacher/classes/new
/user/registered	/teacher/classes/success
/user/signup	/teacher/signup

[F88]

現在までは Nuxt.js の Dynamic Routes に依存したURLになっており、実際のURLにはさほどの意味を持たせていないと言う認識です。整理するのは良いことだと思うのですが、悩ましいですね。

参考まで、 #140 対応時にはとりあえず /lesson(.index)?\?lessonId={id} にリンクするようにしたのですが、この際、なぜ /lessons/{id} にしなかったのかというと以下のような理由(というほどのものでもない)がありました。

• URLを意識しなければディレクトリ名としては lessons よりも lesson の方が良いと思った
• URLとしては /class(es)/lesson(es)/ とした方が利用者には分かりやすい気がしたが、とりあえずルーティングは暫定実装で良いと思ったのでわかりやすく/pages/lesson/index.vue とした
• そもそもユーザーに対してはこれまでも class_id, lesson_id のような値の存在は意識させていないため、あまりそこに意味を持たせたくなかった、が実装の都合上 this.$route.query を使うのが副作用が少なかったのでURLのqueryを使用した、結果URLが前述の通りとなった
• 今回 Nuxt PWA を利用していることもあり、特に理由が無い限り利用者側でのA2HSを制限することも無いと思っており、その場合基本的にはURLは見えないもの(とみなす)ので、ユーザーにURLを意識させないほうが良いと思っている、結果上記実装ではさほどURLに拘らなかった
  • とはいえQRコードやURL共有などにより例えば特定のクラスやページが直接表示出来れば良いと思うこともあり、URLをないがしろにしているわけでは無い。今回Firebaseを利用していることもあり、ついでにFirebase Dynamic Linksを使ってなにか出来るかもしれない

ということで、これまであまりURLは意識していなかったのですが、APIサーバーというわけでも無いのでURLは簡潔な方が良いのかなとは思っています。

[F88]

変更案 > teacher / student

これについてはPJ初期から個人的には強く意識しているように、ユーザーはいわゆる先生だったり生徒である必要性が無い為、 parent / child でも良いと思っている位です。ただどちらにせよ反対意見が出て来るとおもうので、クラスの管理者と利用者という意味で admin / user程度とか、さすがに固いですが。

[mamisada]

かなり先の話ですが、スタディログなどが発生した場合は、子ども側にもある種の編集・管理は発生しうるので、 admin / user は避けたいです。

[mamisada]

parent に関しては、保護者・養育者が親だけではないので、こちらも避けたい形です。

[F88]

ということで、個人的には、単語による種々の制約を受けにくいという意味では、現在の

/account
/classes
/user/*
lesson

というのは結構(モデリング)センスあると思っていて、単数形/複数形の整理はしておいた方が良いかとは思います。
で、これは変えた方が良いかなと思うのは、
/edit -> /lesson/edit
程度でしょうか。 /edit/ も実装時にとりあえず編集用の index.vue 置き場として edit というディレクトリを作ったのだと推測しますので、深い意味は無かったのでは無いでしょうか。

[MaySoMusician]

行為に着目して 何かの行為をする人という意味で editor(s) / viewer(s) という案もあります。
... が viewer(s) の方は、個人としては認証（広義）していない（クラスIDを知っている人達、ぐらいの緩さ）なので、単に /view でも良い気がします

この場合、 /editor と /view となって「人」と「行為」の二項対立になってしまいますが、そもそも生徒側のログインページが現状 / なので

• editor専用のページを /editor 配下に置く
• 登録処理不要で見られるページを / 配下に置く
  • その一部としての /view 。クラスIDは認証・認可ではなく単にアクセス先を指定しているだけという意味付け

と解釈できるかなと思います

[MaySoMusician]

/classes は開発者側が混乱を生む命名だと思います。
そこで表示されるのは「ひとつのclassに結びつけられた複数のlessons」なので、データの内容に着目するなら /lessons 、表示形態に着目するなら /timetable などが考えられます。
/classes が意味する「いくつかのクラス」が表示されるページはクラス選択ページであり、現在は既に /user/classlist が担当しています。

時間割表示に /classes を割り当てるのは強く避ける べき だと思います

[F88]

editor/viewer に関してはまさに

スタディログなどが発生した場合

など、他の理由などにより、現在はアカウントを必要としない利用者が将来的に編集機能を利用する可能性が発生した場合不自然になるので避けた方が無難かなとは思います。

余談ですが、丁度昼間たまたま pinterest/ktlint: An anti-bikeshedding Kotlin linter with built-in formatterを一読したところで、自転車置き場議論について少し考えたところでした。名付けは本当難しいですね。

[MaySoMusician]

人を限定しないギリギリな属人的表現を攻めると educator / learner が可能に思われます（どっちも比較的馴染みのない単語ですが）

[MaySoMusician]

/account 以下については、生徒役と教員役でログインページ等が異なるのだろうと想定していたので、当初案では /teacher 以下に分類していたのですが、もし今後の拡張でも「同一ページでタブ切り替え等によって生徒役ログイン・教員役ログインを分ける」とかなら、ルートディレクトリに配置してもいいような気がします

でもsignupの入力事項が異なる可能性があるからやっぱり何か階層分けが必要...？