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の入力事項が異なる可能性があるからやっぱり何か階層分けが必要...？

[F88]

educator / learner

そうですね、もちろん冗談半分ですが英単語ではなくドマイナーな言語の単語とかを使えばあるいは、と思いきや、その単語は他の言語で酷い意味を持つみたいなこともあるのが世の常でしょうか... 😿

[F88]

実装上のことを考えると
Unknown Dynamic Nested Routes
https://nuxtjs.org/guide/routing/#unknown-dynamic-nested-routes
のようにトリッキーな方法で誤魔化すという手もありますかね... (ちょっとつらい)

[MaySoMusician]

よく考えると、現在の /lesson は教員役編集画面からも飛ぶ可能性があるので、 /student (or learner )以下には配置できないですね

[F88]

実装やシステムアーキテクチャを無視して考えれば、アカウントはいわゆる先生だろうが生徒だろうがアカウント、それぞれ権限が異なれば出来ることが違うだけ、アカウント不要なものは認可フリーというだけの話と考える事も出来ますかね。 lessonにしてもどの画面から遷移しようがそれはlessonに他ならないのでいっそ /lesson の方が思考が整理しやすいですかね?

[MaySoMusician]

実装上のことを考えると
Unknown Dynamic Nested Routes
https://nuxtjs.org/guide/routing/#unknown-dynamic-nested-routes
のようにトリッキーな方法で誤魔化すという手もありますかね... (ちょっとつらい)

「the depth of your URL structure」は全て開発者の想定内で済むはずなので、Unknown Dynamic Nested Routesまでは使わなくても済むかなと

---

本件に関しては「利用者がわかりやすい」も追求したいですが、それよりも個人的には「開発者がわかりやすい」の方を重視したいところでもあります。

---

lessonにしてもどの画面から遷移しようがそれはlessonに他ならないのでいっそ /lesson の方が思考が整理しやすいですかね?

そうですね。各時間割表ページから /lesson に飛ぶみたいなのが良さそうですね
（つまり授業詳細ページについては現状のまま）

[MaySoMusician]

そうすると、時間割表を見るだけ・編集もできるの二項対立に落ち着くので

• 現 /classes を /view に
• 現 /edit は /edit のまま

ですっきりしますかね。ここを揃えたい理由（ /edit を /lesson/edit 等にしない理由）として、上記2ページはどちらも初期ビューが「時間割表の表示」なので同階層にあった方が開発者がわかりやすいかなと思います

この案では、その他のアカウント関連はどっか別階層を用意する想定です（ /educator とか /learner とか ）

[MaySoMusician]

アカウント関連は、「教育者」「学習者」の訳語にそれぞれ teacher / student も出てきてしまうので（再逆引きすれば教員と生徒にはなるが）

• 教える側の人（親も「教える側の人」になり得る） → teach + er = teacher

生徒側は用語の一般さでいえば student、 逆に もしくは -er で押韻を意識して learner で良いのではないかと思います。

整理すると teacher アカウントと learner アカウント、みたいな感じになるかと

[F88]

だれにとってのわかりやすさか問題

URLを設計する上では、REST API Naming Conventions and Best Practices – REST API Tutorial のような考えもあり、また example.com/1/fo-bar-baz (/foo-bar-baz はURIとして無意味で単にヒトが理解しやすくするための表現)のようなものもあり、なにに注目するか次第だと思うのですが、開発者にとって分かりやすいものというのもまた開発者によって異なると思います。例えば、開発者にとって /せんせい/lesson と せいと/lesson の lesson は同じものか違うものか、違うものかと思いきや同じものだったとした場合、それが分かりやすさなのか、とまさに終わらない話ですね。「開発者にとってわかりやすい」ってのはちょっと無理がある気がします。

[mamisada]

①ユーザーの視認性・理解しやすさ（混乱を招かない）
②開発者・プロジェクト側が区別しやすい（混乱を招かない）
上記踏まえて、teacher / student でお願いしてもいいですか？

[F88]

これまで話には出てきていないですが、ありうるユースケースとして、学校のクラスのだれかがこのシステムで時間割を作って、友達が使うといったこともあっても良いなと思ったことはあります。
例えば本日の掃除当番を管理する為に使うことも出来ます。そういう観点から捉えると、まさにクラスというモノの管理者と利用者と言うロールで成り立っているのが今回のユーザーモデルだと思っています。
管理者も利用者も編集権限の有無などは問いません。いわゆる組織向けのモデルではほぼ必ず登場する概念ですね。

[MaySoMusician]

とりあえずアカウント関連の前に、他のページについて整理すると、アカウント関連以外は基本現状のままで

• /classes → /view

だけ変える、というところに異論はありませんか？

[F88]

①ユーザーの視認性・理解しやすさ（混乱を招かない）
②開発者・プロジェクト側が区別しやすい（混乱を招かない）

の結果が

teacher / student

なのだとすると、 view は却下では無いでしょうか...

単語選定は本Issueの本来の目的では無いので、要請があればそれにあわせれば良いでしょうし、それまではかりに foo bar でも当てておいて構造の検討を優先した方が良いのでしょうね。個人的には既に自転車置き場議論に陥っていると思うので、1階層でまとめる案を推したいですが、特に拘りはありません。

[MaySoMusician]

ふむ... どうしましょうか
実は当初案は

現在の /lesson は教員役編集画面からも飛ぶ可能性があるので、 /student (or learner )以下には配置できないですね

なので上手く機能しないんですよね

（自転車置き場議論って何かの時事的話題かと思っていたけど、そういう法則があるのか）

[F88]

整理すると teacher アカウントと learner アカウント、みたいな感じになるかと

ちょっと気になったのでコメントさせて下さい

アカウントはアカウントだと思います。あえて言うなら 「(teacherが使う)アカウント」「(leanerが使う)アカウント」、それぞれ異なるのは権限など認可により制御されるだけのもので、やはりアカウントに他ならないです。役割でも無いです。

例えば銀行の口座があって、A先生が開設した口座と、X仙人が開設した口座があっても、ヒトはどちらも単なる「口座」として捉えている(でろう)ように、アカウントはアカウントで良いと思います。

[MaySoMusician]

あぁ、 teacherが使うアカウント用のページが詰まってるディレクトリ → /teacher ぐらいの意味合いでした

[kaizumaki]

このスレをずっと見ていましたが、あまりに未来の可能性のことまで広げすぎているかなという感じがしました。
私は、v0をリリースした後に各ページのurlが変わることがあっても問題ないと思っています（ログインして利用するページにおいては尚更）。
現段階では目の前の用途に合わせて決めるのがいいような気がしています。v0をリリースして、ユーザーの利用動向をみて変えるのもアリかなと（v1までに決まればなおよし）。
で、目の前の用途とはなんでしょうね...？

[MaySoMusician]

あくまで開発者的視点で個人的な観点ですが、「teacherでログインしてないと見られないページ」は「middlewareがteacherログインページに追い返す」という挙動があるので、その挙動が起きるページを何かしらのディレクトリにまとめたいという思惑があります（ /edit が例外になりかけてますが）
自分が言いたかった「開発者のわかりやすさ」はこれだったと思います。もちろん各pageのmiddlewareを見れば把握可能なのでよく考えると必須では無いです。

しかもよくみると /edit 以外は /user にまとまってるのでそもそも問題が発生していなかったともいえるかもしれませんが

[MaySoMusician]

当初の提案に関して提案者としては、利用者について考慮していたのはキャピタライズの部分だけで、残り99%は開発者目線でした

[NEKOYASAN]

/userと/accountに分かれちゃってますが、ここについては別に分ける必要がないので #159 の対応と共にuserに統一しようと思っています。

/edit、/lessonについても必ずしもその階層になくてはいけないわけではない（/user/editなどにしてもOK）です！

[mamisada]

再検討案件

[MasaGon]

このあたり、認証系（ガードのあり方）も絡めて議論したい感じです。