component のディレクトリ構成を変更する #5404

nard-tech · 2020-09-10T14:48:29Z

👏 解決する issue / Resolved Issues

非機能要件（可読性・拡張性・設計）問題点・改善点の整理 #2790 (comment)

📝 関連する issue / Related Issues

コンポーネントの統廃合 #5064, component のディレクトリ構成を変更 #2916, component のディレクトリ構成を見直し #4016

⛏ 変更内容 / Details of Changes

component のディレクトリ構成を変更 #2916, component のディレクトリ構成を見直し #4016 で断念した，component のディレクトリ構成を変更する PR の再作成版
- component のディレクトリ構成を変更する #5327 はいったん close し，development ブランチに rebase して再作成した．
コンポーネントの統廃合 (cf. コンポーネントの統廃合 #5064) も念頭に，コンポーネント間の依存関係を把握しやすくなるように努めた
変更後のディレクトリ構成は components/README.md に記載の通り

kaizumaki · 2020-09-13T06:54:38Z

@nard-tech 整理していただきありがとうございます！現在 #5293 がマージ待ちでして、そちらが終わったらこのPRを運営側で検討したいと思います。少しお時間ください 🙏

nard-tech · 2020-11-07T12:26:32Z

@kaizumaki #5293 が merge されましたので，最新の development ブランチに rebase し，force push しました．
こちらご確認ください．

#5632, #5654, #5656 などと conflict が発生するかと思います．申し訳ないですが，そのことを気にしすぎるとこの PR は永遠に merge されないと思いますので，いいタイミングで早めに merge して頂きたいです．

概して，荒れた設計を立て直すときには大きな変更をまとめて行わなければならないことがあると思います．
また，冬を迎えて情勢が変化する可能性もありますので，なるべく早めにコードの治安をよくしたいです．

kaizumaki · 2020-11-08T01:00:44Z

@nard-tech お待たせしてしまい申し訳ありません。ご対応ありがとうございます。

また，冬を迎えて情勢が変化する可能性もありますので，なるべく早めにコードの治安をよくしたいです．

これはまったくその通りだと思います。実際のところ、当サイトが立ち上がってからオールシーズンをまだ経ていないので、正直今後どうなるかわかりません。
早めに運営側でこちらのPRを検討いたします。

MaySoMusician · 2020-11-08T04:31:36Z

ディレクトリ構成については Vue.js 公式のスタイルガイド（BETA版）が存在し、ガイドの密結合コンポーネントの名前 - 強く推奨によれば、

親コンポーネントと密結合した子コンポーネントには、親コンポーネントの名前をプレフィックスとして含むべきです。

この問題を、子コンポーネントを親コンポーネントの名前を元に命名したディレクトリの中に入れることで解決したいと思うかもしれません。
(中略)
これは推奨されません。以下のような結果を生むからです:

同じような名前のファイルがたくさんできてしまい、コードエディタ上で素早くファイルを切り替えるのが難しくなります。

ネストしたサブディレクトリがたくさんできてしまい、エディタのサイドバーでコンポーネントを参照するのに時間がかかるようになります。

とあります。Nuxtでは pages と components が分離している事情もあるので、すべての命名規則を一律に当てはめられるとも限りませんが、ディレクトリに分けるよりも単一階層で並んでいるほうが、エディタやGitHub上でディレクトリを横断する手間が省けるのは一理あります。こちらのガイドに準拠してみるのはいかがでしょうか？うまく命名規則にあてはめられない場合、コンポーネントの結合の仕方がよくない = 新しいコントリビューターがソースを読むのに支障が出る可能性 → リファクタリングへのヒントになるかも？とも思っています。

nard-tech · 2020-11-08T08:27:09Z

@MaySoMusician
この PR の目的は

コンポーネント間の依存関係を把握しやすくなるようにする
現状は component/cards 以下の component が components 以下の component に依存しているケースがあり（例：components/cards/AgencyCard.vue が components/AgencyBarChart.vue を import している），明らかに構成がおかしいので修正する

ことです．

単一階層に component をまとめてしまうと，コンポーネント間の依存関係，階層が明確になりませんし，components 直下に 48，component/cards 以下に 20 の component が命名規則もなく無秩序に乱立している現状の方が余程

コードエディタ上で素早くファイルを切り替えるのが難しい

コンポーネントを参照するのに時間がかかる

新しいコントリビューターがソースを読むのに支障が出る

ことになり，開発のパフォーマンスを損ねることになると思っています．新しい機能を追加するときに既存の component が乱用される恐れもあります．

コードエディタ上で素早くファイルを切り替えるのが難しい

コンポーネントを参照するのに時間がかかる

であったとしても，よい設計，わかりやすいコードで開発のパフォーマンスを上げる観点からは無視できる程度かと思います．

エディタに関しては，VSCode のようなモダンなエディタであれば，

同一の名前のタブを開いたときにディレクトリを表示してくれる（cf. 画像）
import した component の定義箇所に移動できる

ということで，特に開発に困らないと思います．

また，TypeScript を導入して型のチェックをしているのでバグを仕込むリスクも少ないはずです．

MaySoMusician · 2020-11-08T08:40:02Z

単一階層での依存関係の表現については、先程のガイドの

親コンポーネントと密結合した子コンポーネントには、親コンポーネントの名前をプレフィックスとして含むべきです。
もし、コンポーネントが単一の親コンポーネントの中でだけ意味をもつものなら、その関連性は名前からはっきりわかるようにするべきです。一般的にエディタはファイルをアルファベット順に並べるので、関連をもつものどうしが常に隣り合って並ぶことにもなります。

で解決可能ですがいかがでしょうか

kaizumaki · 2020-11-08T09:32:44Z

components/README.md

+
+`components/index/_shared/DataView.vue` に関連して用いられるファイル群を配置している．
+
+**注意**: 旧 `components/DataViewCustomInfoPanel.vue` は「発症日別による陽性者数の推移」の描画のみに用いられているため，`components/index/CardsReference/PositiveNumberByDevelopedDate` 以下に配置した．


この注意についてですが、ちょっとわかりにくいような気がしますね。
たしかに現在 DataViewCustomInfoPanel.vue は「発症日別による陽性者数の推移」にしか使っていませんが、コンポーネントの性格としては汎用に使用できるように作られていますから、このディレクトリの下にあることに少し違和感を感じます。

kaizumaki · 2020-11-09T00:05:14Z

ご提案いただいているコードで以下のようなimportの書き方がありますが、これって一般的なのでしょうか...？

import TestedNumberChart from '@/components/index/CardsReference/TestedNumber/Chart.vue'

もちろん正常に動作することは理解できるのですが、コンポーネント名とimportしている名前が一致しない書き方はみなさん一般的にされているのだろうか？という素朴な疑問です。

nard-tech · 2020-11-24T12:55:37Z

@MaySoMusician
現状，component A が component B に依存し，component B が component C に依存し…というケースがあるので，

親コンポーネントと密結合した子コンポーネントには、親コンポーネントの名前をプレフィックスとして含むべき

という考えに素直に従って正確に階層を表現しようとするとファイル名が極端に長くなり不健全になることがあると思います．

極端な例では，この PR 内で components/index/CardsMonitoring/MonitoringItemsOverview/ValueWithTranslatableUnit.vue としているものを components/index/CardsMonitoringMonitoringItemsOverviewValueWithTranslatableUnit.vue などという名前にすることとなり，さすがにどうかと思います．

component の数が多いので，適切にディレクトリを区切り，

components/index/CardsMonitoring.vue
components/index/CardsMonitoring/MonitoringItemsOverviewCard.vue
components/index/CardsMonitoring/MonitoringItemsOverview/ValueWithTranslatableUnit.vue

という階層関係が見えやすくする方が保守性，可読性がよいのではないでしょうか．

例えば，VSCode のファイル一覧で

> components
  > index
    > CardsMonitoringMonitoringItemsOverviewValueWithTranslatableUnit.vue

と表示されるのと，

> components
  > index
    > CardsMonitoring
      > MonitoringItemsOverview
        > ValueWithTranslatableUnit.vue

と表示されるのとでは，後者の方が視認性が優れているはずです．

折衷案として，components/index/MonitoringItemsOverviewValueWithTranslatableUnit.vue 程度の名前に留めておく（CardsMonitoring を取る）という手もありますが，エディタ内での視認性が悪いこと，階層関係が十分に表現できていないことから得策ではないと思います．

補足: components/index/CardsMonitoring/MonitoringItemsOverviewCard.vue や components/index/CardsMonitoring/MonitoringItemsOverview/ValueWithTranslatableUnit.vue の細かい命名規則（例：「前者から Card をとった方がいいのでは」「後者のディレクトリ名に Card を付けたほうがいいのでは」）についてはいったん置いておくことにします．

nard-tech · 2020-11-24T12:59:23Z

@kaizumaki

たしかに現在 DataViewCustomInfoPanel.vue は「発症日別による陽性者数の推移」にしか使っていませんが、コンポーネントの性格としては汎用に使用できるように作られていますから、このディレクトリの下にあることに少し違和感を感じます。

どの component で何が使われている（何が使われていないか）かを明確にするために，汎用的に使われている component もあえて現状のコードに即して rename しました．

DataViewCustomInfoPanel.vue と同様の表示をする component が今後どんどん増加するのであれば汎用性を考慮しておくべきかと思いますが，そうは思いません．あまり汎用性を考慮すると，いわゆる「早すぎる最適化」となってしまって結局意味がなかったということにもなると思いますので，必要なときに refactor すればよいのではないでしょうか．

nard-tech · 2020-11-24T13:01:00Z

@kaizumaki

ご提案いただいているコードで以下のようなimportの書き方がありますが、これって一般的なのでしょうか...？

import TestedNumberChart from '@/components/index/CardsReference/TestedNumber/Chart.vue'

もちろん正常に動作することは理解できるのですが、コンポーネント名とimportしている名前が一致しない書き方はみなさん一般的にされているのだろうか？という素朴な疑問です。

これはご指摘の通りあまり一般的ではないので，

import Chart from '@/components/index/CardsReference/TestedNumber/Chart.vue'

となるように修正したいと思います．

当方の都合でこちらの PR も長く放置してしまい，conflict も発生しているので，#5690 の対応が済んだ頃にまた改めて対応します．

kaizumaki · 2020-11-25T01:12:00Z

@nard-tech

import Chart from '@/components/index/CardsReference/TestedNumber/Chart.vue'
となるように修正したいと思います．

ご提案の内容だと、Chart.vueというファイルが大量にできているのを懸念しています。エディタでのサジェストが上手くいきません。
ファイル名はプロジェクト全体で一意になるようにしたほうがいいと思うのですが、どうでしょうね？

kaizumaki · 2020-11-25T01:19:25Z

@nard-tech

あまり汎用性を考慮すると，いわゆる「早すぎる最適化」となってしまって結局意味がなかったということにもなると思いますので，必要なときに refactor すればよいのではないでしょうか．

たしかに仰るとおりなのですが、このプロジェクトのソースコードは多くの人々に参照されているということも考慮に入れていただければと思います。

ディレクトリ構造で言えば、nuxtを使用している時点でディレクトリ構成が決められているのですから、すでに最適化されていると言えると思います。

mcdmaster · 2021-03-23T05:53:32Z

こんな興味深いｽﾚ、もとい PR があったんですね。てんで気づきませんでした。

で、イキナリで恐縮ですけれども、私は @nuxt/components の利活用一択しかないと思っています。
@nuxt/components の実現要件を踏まえつつ、フォルダの整理を図るのがよさげです。
参考 https://nuxtjs.org/blog/improve-your-developer-experience-with-nuxt-components/

本 PR 最新コミット内容を、@nuxt/components に基づき拝見させてください。
特にフォルダ名などは、かなり整理したうえでコーディングの際の findability も損ねずにいけるのではないかと睨んでいます

nard-tech · 2021-03-24T06:54:39Z

@kaizumaki @mcdmaster こちらの PR も長らく放置してしまいましたが，

ご提案の内容だと、Chart.vueというファイルが大量にできているのを懸念しています。エディタでのサジェストが上手くいきません。ファイル名はプロジェクト全体で一意になるようにしたほうがいいと思うのですが、どうでしょうね？

多くの方が VSCode を使われていると思うのですが，VSCode では command + P でファイル名を名前で検索するときはディレクトリ名も表示されるので，間違ったディレクトリのものを選ばない限りは問題ありません．

この PR の目的は，ディレクトリで component 間の階層関係を表現し，開発者の理解を助けることにあります．「エディタでのサジェスト」は主に新しく component を追加するときにだけ使うことになると思いますが，「間違ったディレクトリのものを選ぶリスク」「最初の1回限りのエディタでのサジェストが効くこと」と「今後保守運用，機能追加をするときの開発者の理解のしやすさ」を比べると後者の方のメリットの方がが開発全体に与える影響が大きいのではないでしょうか．

このプロジェクトのソースコードは多くの人々に参照されているということも考慮に入れていただければと思います。ディレクトリ構造で言えば、nuxtを使用している時点でディレクトリ構成が決められているのですから、すでに最適化されていると言えると思います。

多くの人々に参照されているからこそ理解のしやすさは重要だと思います．
ディレクトリ構造については，components, pages... といったトップレベルのディレクトリのお話をされているのかと思いますが，私は components 以下の話をしています．

components 以下の同一階層にすべての component を配置するのが原則というご意見もありましたが，その原則をあてはめるのには無理があるレベルまでファイル数が増えているのでは？（これを書いている現時点で components 直下に53個，components/cards 以下に21個）というのは既に述べた通りです．そもそも components/cards` が存在している時点で原則は破られていますし．

@nuxt/components の利活用一択しかない

@nuxt/components は既に使用できるようになっていて，実際に遅延ロードなどで使われているようですが，これ以上の積極的な活用は難しいような気がしています．

いくつかドキュメントに目を通しましたが，設定が複雑になって新しく参加する開発者の参入障壁が上がってしまう気がしました．

私自身，このプロジェクトに参加するまで Vue の経験はほとんどなく，一般的な JavaScript, TypeScript の知識や React の経験があったので何とか追いつけたのですが，Vue の知識の他に @nuxt/components の知識まで求められるようになると新しく参加するのが難しくなってしまうと思います．

MaySoMusician · 2021-03-24T09:30:34Z

ああ、いつの間にか @nuxt/components が導入されていたんですね
@nuxt/components がオンの場合、componentsの手動インポートは全く不要になります（特に設定をいじらない場合）。

横に長いファイル名を避けるのは視認性向上につながって良いと思いました。一方で縦向きの視認性も気になります。すなわち、多くのエディタ（とGitHub）ではディレクトリとファイルを分けて一覧化するので、依存されているコンポーネントファイルと依存しているコンポーネント群のディレクトリが離れてしまいます（コンポーネントが増えれば増えるほど）。

ここで、

親コンポーネントと密結合した子コンポーネントには、親コンポーネントの名前をプレフィックスとして含むべき

を部分的に適用すると

一般的にエディタはファイルをアルファベット順に並べるので、関連をもつものどうしが常に隣り合って並ぶこと

が達成でき、 ConfirmedCasesDetailsCard.vue が何に依存されているかがよりわかりやすくなると思います。

また、ディレクトリは「開くまで何が入っているかわからない」「階層の上り下り自体に1操作を消費する」という課題があります（Windows Explorerやターミナル、GitHubのWebインターフェイスでも）。ディレクトリ内のファイル数が1～数個程度なら、よりフラットな階層構造を目指してもよいのではないでしょうか。

上図を例にすると、 UntrackedRateCard.vue を編集中にその子コンポーネントを参照したい場合、ディレクトリで分けていると9ファイル分を飛び越えて UntrackedRate にたどり着く必要があります。フラットな構造の場合、ひとつ下にある UntrackedRateCardChart.vue がすぐに発見できます。

他方で、フラットな構造にした場合、 UntrackedRateCard.vue と ConfirmedCasesDetailsCard.vue はより離れてしまうことになりますが、ディレクトリで分けた場合でも、離れていることに変わりありません。同系統のコンポーネントを参照する機会と、親子コンポーネントを参照する機会のどちらが多いかは定量的に判断できるわけではありませんが、「隣り合っているファイルを参照しさえすればよい」という恩恵は可能ながらあずかってもよさそうです。

もうひとつ気になっているのは、CardsMonitoring 内の子ディレクトリ内にある StackedTable.vue Chart.vue があまりにも汎用的な命名すぎる（i.e. 命名は汎用的だが中身は特定コンポーネントに特化している）ことです。もちろんフルパスで判断すればわかることではあるのですが...。

import時に

import UntrackedRateChart from '@/components/index/CardsMonitoring/UntrackedRate/Chart.vue'

と別名をつけるなら

import UntrackedRateCardChart from '@/components/index/CardsMonitoring/UntrackedRateCardChart.vue'

でも大差ないと感じます。

nard-tech · 2021-03-31T12:26:52Z

@MaySoMusician

よくよく考えてみると，以下のようなディレクトリ構造が

横に長いファイル名を避ける
縦向きの視認性も確保する

の両方を満たしていてよいのではないかと思いました．

> components
  > index
    > CardsMonitoring
      > ConfirmedCasesDetails
        > Card.vue
        > Table.vue
      > ConfirmedCasesNumber
        > Card.vue
      > MonitoringConfirmedCases
        > Card.vue
        > Chart.vue
      > MonitoringItemsOverview
        > Card.vue
        > InfectionStatus.vue
        > MedicalSystem.vue
        > ValueWithTranslatableUnit.vue

components/index/CardsMonitoring/ConfirmedCasesDetails（検査陽性者の状況）を例に取ると，「検査陽性者の状況」に関する component はすべて components/index/CardsMonitoring/ConfirmedCasesDetails の中に入っているということになります．

具体的なコードを示すと，components/index/CardsMonitoring.vue では

// 検査陽性者の状況
const ConfirmedCasesDetailsCard = () =>
  import('@/components/index/CardsMonitoring/ConfirmedCasesDetails/Card.vue')
// 報告日別による陽性者数の推移
const ConfirmedCasesNumberCard = () =>
  import('@/components/index/CardsMonitoring/ConfirmedCasesNumber/Card.vue')

のように，「components/index/CardsMonitoring より下のディレクトリ名 + ファイル名」=「template で使用する別名」として複数の Card.vue の区別をし，components/index/CardsMonitoring/ConfirmedCasesDetails/Card.vue では特に同名の複数のファイルの区別が必要ないので

import Table from '@/components/index/CardsMonitoring/ConfirmedCasesDetails/Table.vue'

とする形となります．

複数の Card.vue ができることについては #5404 (comment) でコメントした通り，さほど大きな問題ではないと思います．

依存されているコンポーネントファイルと依存しているコンポーネント群のディレクトリが離れてしまいます

ディレクトリは「開くまで何が入っているかわからない」「階層の上り下り自体に1操作を消費する」という課題があります（Windows Explorerやターミナル、GitHubのWebインターフェイスでも）。ディレクトリ内のファイル数が1～数個程度なら、よりフラットな階層構造を目指してもよいのではないでしょうか。

上記の案では，依存されているコンポーネントファイルと依存しているコンポーネントファイルを同じディレクトリに入れておくことになります．

component の依存関係は表現できませんが，「1つの図表の描画に必要な component が同じディレクトリの中に入っている」という状態が実現でき，「どのディレクトリも開いてみれば同じような名前のファイルが入っている（けれど，ところどころ違う）」という状態にもなるので，各図表（に必要な component）の共通点と相違点が明確になります．

1つのディレクトリの中で Card.vue が他のファイルを import しているという構造については，コードをしばらく眺めれば分かることですし，ドキュメントにも記載して初心者の理解を助けるようにすればよいことです．

ディレクトリ内のファイル数が1～数個程度なら、よりフラットな階層構造を目指してもよいのではないでしょうか。

先のコメントのスクリーンショットで示して頂いたように，ディレクトリ分けを components/index/CardsMonitoring のように第3階層までで止めておくというのも悪くないと思いますが，

> components
  > index
    > CardsMonitoring
      > MonitoringItemsOverview
        > ValueWithTranslatableUnit.vue

とできるものが

> components
  > index
    > CardsMonitoring
      > MonitoringItemsOverviewTableValueWithTranslatableUnit.vue

のようになってしまうので，「横向きの視認性」の点で劣ると思います．

上記の案では，Card.vue のみならず，複数の Chart.vue ができることにもなります．

ここで，

import { Chart } from 'chart.js'

となっている箇所との衝突が懸念されるかもしれませんが，これは

type Computed = {
  displayOption: Chart.ChartOptions
  displayOptionHeader: Chart.ChartOptions
  ...
}

といった形の型定義で使われているものがほとんど（plugins/vue-chart.ts 以外すべて）で，これらは

import { ChartOptions } from 'chart.js'

のように書き換えることができ，上記の案で発生することになる

import Chart from '@/components/index/CardsMonitoring/MonitoringConfirmedCases/Chart.vue'

などの import と名前が衝突することはなくなります．（余談ですが，chart という言葉と graph という言葉が混在しているので，各 card で使用している図表描画用の component は Graph.vue に統一するなどするとなおよいかと思います）

@nuxt/components がオンの場合、componentsの手動インポートは全く不要になります

components/xxxx/Chart.vue という形式のファイルが複数存在することになると，単に

<template>
  <chart>
  </chart>
</template>

と表記したときにどの component が自動で import されるかが保証できません．

@nuxt/components のドキュメントをよく読めば，「近いディレクトリから探索する」などと書かれているなどして実際には問題ないのかもしれませんが，直感的な理解ができず，コピペコードが量産された場合に意図しないバグを仕込むリスクもありますので，自動 import を前提としたコードよりは，素直に import するファイルを指定するコードの方が好ましいと思います．

import するファイルを指定するとき，

// 例1
import Chart from '@/components/index/CardsMonitoring/MonitoringConfirmedCases/Chart.vue'
// 例2
import MonitoringConfirmedCasesChart from '@/components/index/CardsMonitoring/MonitoringConfirmedCases/Chart.vue'

のどちらが分かりやすいかは議論が分かれるところではありますが，import しているファイルについて誤解の余地がないという点では自動 import より優れているはずです．

MaySoMusician · 2021-03-31T12:57:09Z

@nard-tech そうですね。同じディレクトリにCard.vueとTable.vueを入れるのはわかりやすそうですね。
取り急ぎ自動importの件ですがここやここにある通り、 components/ 以下のディレクトリがプレフィックスとして付くのが初期設定になります。
components/Aaa/Chart.vue components/Bbb/Chart.vue はそれぞれ <AaaChart> <BbbChart> でアクセスする形になります（ <Chart> ではアクセス不能）

kaizumaki · 2021-03-31T20:15:53Z

@nard-tech そうですね。同じディレクトリにCard.vueとTable.vueを入れるのはわかりやすそうですね。
取り急ぎ自動importの件ですがここやここにある通り、 components/ 以下のディレクトリがプレフィックスとして付くのが初期設定になります。

私はそれでいいんじゃないかなあと思いました。
ということは、

> components
  > index
    > CardsMonitoring
      > ConfirmedCasesDetails
        > Card.vue
        > Table.vue

という構成にして、自動importする、という感じでしょうか。

nard-tech · 2021-04-01T05:48:30Z

@MaySoMusician

components/ 以下のディレクトリがプレフィックスとして付くのが初期設定になります。

ご教示ありがとうございます．

@kaizumaki

> components
  > index
    > CardsMonitoring
      > ConfirmedCasesDetails
        > Card.vue
        > Table.vue

という構成だと，nuxt/components で何も設定しないと template 内で<IndexCardsMonitoringConfirmedCasesDetailsCard> といった形でアクセスすることになります．さすがにこれだと長過ぎますよね．

nuxt/components に設定を加えることで <ConfirmedCasesDetailsCard> といった形にすることができますが
(cf. https://github.com/nuxt/components#nested-components, https://github.com/nuxt/components#directories)，この場合は

設定の規約を明確にし，ドキュメントとしておく
- 新規の contributor にも理解してもらうように努める
規約にそぐわない新規 component はレビューで指摘して修正させる

といったことが条件になるかと思います．

自動 import を使わず愚直に import を書いていくスタイルだと，#5404 (comment) の末尾に書いたように，

import しているファイルについて誤解の余地がないという点では自動 import より優れている

と思われます．

たたき台として，nuxt/components に設定を加えて template 内で <ConfirmedCasesDetailsCard> といった形で component を使えるようにし，自動 import を前提とする形で書き直してみようかと思います．その上で懸念点が見つかれば自動 import はやめにして愚直に import を書いていくスタイルに切り替えればいいかな，と思います．いかがでしょうか．

kaizumaki · 2021-04-01T06:05:55Z

@nard-tech

ああーっと、

設定の規約を明確にし，ドキュメントとしておく

新規の contributor にも理解してもらうように努める

規約にそぐわない新規 component はレビューで指摘して修正させる

といったことが条件になるかと思います．

これは避けたいですねー。そもそも、私が極端な深い階層になるのを避けたかった理由がここだったりします。
nuxtのプロジェクトとして、当リポジトリがあまりに独自すぎるルールを持つのは回避したいです。

importの扱いについては @MaySoMusician さんの意見も伺いたく 🙏

mcdmaster · 2021-04-01T06:33:22Z

横割り失礼します。

個人的には、pages/cards/_cards.vue の物凄い行数の import を~~どげんか~~きれいに整理したいです(笑)

…azyRow.vue

…ow.vue

…rt.vue to components/index/_shared/MixedBarAndLineChart.vue

…rChart.vue

…hared/OpenDataLink.vue

…lector.vue

…ollableChart.vue

…sultation/StaticInfo.vue

…ndex/_shared/DataView/ExpantionPanel.vue

…ared/DataView/Share.vue

…d/DataViewDataSetPanel.vue

…iewTable.vue

nard-tech · 2021-05-25T07:29:17Z

@kaizumaki @MaySoMusician 他の関連 PR が merge されたので，この PR の確認をお願いします．
components/index/CardsMonitoring, components/index/CardsReference 以下のディレクトリ構成はここでの議論の結果をもとにしています．

nard-tech · 2021-05-25T07:30:56Z

utils/formatConfirmedCasesAttributesTable.ts

@@ -52,7 +52,9 @@ export type TableDateType = {
 *
 * @param data - Raw data
 */
-export function formatTable(data: DataType[]): TableDateType {
+export function formatConfirmedCasesAttributesTable(


formatTable では汎用的に使える印象を与えてしまうので，実態に合わせて改名した．

nard-tech · 2021-05-25T07:31:55Z

components/index/SiteTopUpper/InfectionMedicalCareProvisionStatus.vue

-  <div class="InfectionMedicalcareprovisionStatus">
-    <div class="InfectionMedicalcareprovisionStatus-heading">
-      <h3 class="InfectionMedicalcareprovisionStatus-title">
+  <div class="InfectionMedicalCareProvisionStatus">


可読性を考慮し InfectionMedicalcareprovisionStatus ではなく InfectionMedicalCareProvisionStatus とした．

nard-tech · 2021-05-25T07:32:34Z

components/index/SiteTopUpper.vue

-import StayingPopulation from '@/components/StayingPopulation.vue'
-import WhatsNew from '@/components/WhatsNew.vue'
+import Consultation from '@/components/index/SiteTopUpper/Consultation.vue'
+import InfectionMedicalCareProvisionStatus from '@/components/index/SiteTopUpper/InfectionMedicalCareProvisionStatus.vue'


InfectionMedicalCareProvisionStatus を明示的に import した．

kaizumaki

ありがとうございます！LGTMです！
ここに至るまで粘り強くご対応いただいたことに感謝です 🙏

y-chan · 2021-05-26T05:22:16Z

components/index/CardsMonitoring/HospitalizedNumber/Card.vue

    </client-only>
  </v-col>
 </template>

 <script>
-import DashedRectangleTimeBarChart from '@/components/DashedRectangleTimeBarChart.vue'


LGTM後にすみません、一部カードのimport時のネーミングルールがミスっている気がします....

フォローありがとうございます！ここは削除行のようですが、どうなんでしょう？

すみません、範囲選択ミスなんですが、Chartとしてimport、使用されています

私の理解では Card で Chart を配置する、というルールかと思っているのですが、どうなんでしょう？ @nard-tech

他では

import MonitoringConfirmedCasesNumberChart from '@/components/index/CardsMonitoring/MonitoringConfirmedCasesNumber/Chart.vue'

と言った形でimportされている箇所があるようです。
Chartと言った形でimportされているところと、このようにフルネームでimportされているところで、ネーミングルールのばらつきがあるのはどうなんだろう?といった指摘でした。

このコメントでは、区別する必要がなければChartとしてimportすれば良いというように結論づいているように見えましたが、どうなんでしょうか...(つまり、このコメントに従うなら私が指摘すべき所をミスってるわけ(Chartとしてimportしていない所を指摘すべき)ですが...)

そうですね！おそらく後者が修正もれですね。
また後日の修正でも大丈夫なので、いったんここでマージしますね！
@y-chan フォロー感謝です！！

@y-chan @kaizumaki キャッチアップできずすみません．merge ありがとうございます．後ほど確認して必要なら修正します．

@nard-tech ぜんぜん後日で大丈夫です！よろしくお願いします 🙏

@y-chan @kaizumaki #6368 を作成しました．ご確認ください．

nard-tech force-pushed the feature/#2790-change-directory-of-components branch from 6ac2078 to ea2e813 Compare November 7, 2020 12:14

nard-tech force-pushed the feature/#2790-change-directory-of-components branch 2 times, most recently from 68ef7fc to e9dfb0b Compare November 8, 2020 03:16

nard-tech mentioned this pull request Nov 8, 2020

ConfirmedCasesIncreaseRatioByWeekChart を削除 #5654

Merged

nard-tech force-pushed the feature/#2790-change-directory-of-components branch 2 times, most recently from 53d7923 to a2bb406 Compare November 8, 2020 03:44

nard-tech mentioned this pull request Nov 8, 2020

$emit の引数のイベント名を kebab-case とする #5657

Closed

kaizumaki reviewed Nov 8, 2020

View reviewed changes

nard-tech mentioned this pull request Nov 24, 2020

使用されていない component LinkToInformationAboutRoadmap の削除 #5724

Merged

nard-tech added 15 commits May 25, 2021 16:14

Rename components/CardsLazyRow.vue to components/index/_shared/CardsL…

8322ba3

…azyRow.vue

Rename components/cards/CardRow.vue to components/index/_shared/CardR…

a8e428e

…ow.vue

7119における発熱等相談件数，救急医療の東京ルールの適用件数: Rename components/MixedBarAndLineCha…

259db2c

…rt.vue to components/index/_shared/MixedBarAndLineChart.vue

Rename components/TimeBarChart.vue to components/index/_shared/TimeBa…

ad0d94d

…rChart.vue

オープンデータを入手: Rename components/OpenDataLink.vue to components/index/_s…

23b56a2

…hared/OpenDataLink.vue

Rename components/PageHeader.vue to components/_shared/PageHeader.vue

ab262e5

Rename components/DataSelector.vue to components/index/_shared/DataSe…

db2bfb1

…lector.vue

Rename components/ScrollableChart.vue to components/index/_shared/Scr…

4cc0f6a

…ollableChart.vue

Rename components/StaticCard.vue to components/_shared/StaticCard.vue

c987834

Rename components/StaticInfo.vue to components/index/SiteTopUpper/Con…

62cf468

…sultation/StaticInfo.vue

Rename components/DataView.vue to components/index/_shared/DataView.vue

d47b878

テーブルを表示: Rename components/DataViewExpantionPanel.vue to components/i…

75894c3

…ndex/_shared/DataView/ExpantionPanel.vue

情報をシェアする: Rename components/DataViewShare.vue to components/index/_sh…

d03c3dc

…ared/DataView/Share.vue

Rename components/DataViewDataSetPanel.vue to components/index/_share…

ff0d280

…d/DataViewDataSetPanel.vue

Rename components/DataViewTable.vue to components/index/_shared/DataV…

fdd9668

…iewTable.vue

nard-tech force-pushed the feature/#2790-change-directory-of-components branch from b1f0580 to fdd9668 Compare May 25, 2021 07:14

nard-tech changed the title ~~[WIP] component のディレクトリ構成を変更する~~ component のディレクトリ構成を変更する May 25, 2021

nard-tech commented May 25, 2021

View reviewed changes

kaizumaki approved these changes May 26, 2021

View reviewed changes

kaizumaki added the ready-for-merge コードレビューが終わり、マージができるもの label May 26, 2021

y-chan reviewed May 26, 2021

View reviewed changes

soutaito merged commit d8bd9d6 into Tokyo-Metro-Gov:development May 26, 2021

nard-tech deleted the feature/#2790-change-directory-of-components branch May 26, 2021 08:11

This was referenced May 29, 2021

component のディレクトリ構成を変更する MeditationDuck/covid19#1838

Closed

岩手版は @nuxt/components の auto import をやめる MeditationDuck/covid19#1852

Closed

This was referenced May 31, 2021

ディレクトリ構成を変更した際に import の書き方の修正漏れがあったので対応する #6366

Closed

同一ディレクトリ内の component の import の書き方を修正する #6368

Merged


		`components/index/_shared/DataView.vue` に関連して用いられるファイル群を配置している．

		注意: 旧 `components/DataViewCustomInfoPanel.vue` は「発症日別による陽性者数の推移」の描画のみに用いられているため，`components/index/CardsReference/PositiveNumberByDevelopedDate` 以下に配置した．

component のディレクトリ構成を変更する #5404

component のディレクトリ構成を変更する #5404

Conversation

nard-tech commented Sep 10, 2020

👏 解決する issue / Resolved Issues

📝 関連する issue / Related Issues

⛏ 変更内容 / Details of Changes

kaizumaki commented Sep 13, 2020

nard-tech commented Nov 7, 2020 • edited

kaizumaki commented Nov 8, 2020

MaySoMusician commented Nov 8, 2020

nard-tech commented Nov 8, 2020

MaySoMusician commented Nov 8, 2020

Choose a reason for hiding this comment

kaizumaki commented Nov 9, 2020

nard-tech commented Nov 24, 2020

nard-tech commented Nov 24, 2020

nard-tech commented Nov 24, 2020

kaizumaki commented Nov 25, 2020

kaizumaki commented Nov 25, 2020

mcdmaster commented Mar 23, 2021

nard-tech commented Mar 24, 2021

MaySoMusician commented Mar 24, 2021

nard-tech commented Mar 31, 2021

MaySoMusician commented Mar 31, 2021

kaizumaki commented Mar 31, 2021

nard-tech commented Apr 1, 2021

kaizumaki commented Apr 1, 2021

mcdmaster commented Apr 1, 2021

nard-tech commented May 25, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaizumaki left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

y-chan May 26, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nard-tech commented Nov 7, 2020 •

edited

y-chan May 26, 2021 •

edited