@fe4hazw

Are you sure you want to delete the question?

If your question is resolved, you may close it.

Leaving a resolved question undeleted may help others!

We hope you find it useful!

コンポーネント設計について

解決したいこと

コンポーネント設計について。
あるデータを表示するコンポーネントを作ろうとしています。
受け取ったデータを元に集計し、結果を表やグラフにする類のものです。

データは API から受け取ることになります。
そのとき、データの取得はどこですべきかというのが悩んでいる問題です。

方法1:
コンポーネントはデータを受け取って表示する。
APIとの通信は、このコンポーネントを使う親のコンポーネントに任せます。

方法2:
コンポーネントは id や key のようなものを受け取り、
コンポーネント内で API と通信し、受け取ったデータを表示する。

1 にすると、使うときに単純にこのコンポーネントだけを使うわけにはいかず、 API を呼び出す部分も行わないといけません。
使いやすさからすると 2 だと思います。
ウェブ標準の HTML タグである img や video を考えると、 URL を渡せば表示してくれるので、これも 2 だと思います。

しかし、 2 にすると外部通信も集計も 1 つのコンポーネントにまとまるので、複雑化しテストもしづらいように思います。

どちらのほうが良いでしょうか?

なお、フレームワークについては、特に固定しません。
WebComponent、 React、 Vue などどれかに固定せず一般的なコンポーネント化する際の考え方についてです。
もし、フレームワークによって最適解が異なるのであれば、それも合わせてお教えいただけると助かります。

0 likes

3Answer

いわゆる「使いやすさ」にはSimpleとEasyの2種類ありまして、方法1は単純化されているのでSimpleで使いやすい、方法2は一連の処理がまとまっているのでEasyで使いやすい、ということになりどちらも「使いやすい」に当てはまると思います。
テストについてもおっしゃるとおりなので「どちらの使いやすさを求めるか」になります。

私の回答ですが、基本的にViewコンポーネントは表示に関する責務だけにしておきたいですし、末端のコンポーネントはSimpleにして扱いやすくしたいので、だいたいは方法1を選択します。
Easyな使いやすさを求めるなら上位のレイヤーで処理をまとめたものを作ります。
そうしていくと「コンポーネント数が多くなって複雑」になりますが、そうしたトレードオフを考えて良し悪しを判断する、ということになりますね。

1Like

自分なら、方法1を選びます。
方法2の場合、「データ受け取り」を範囲に入れると、すぐ「データ加工」も視野に入ります。
また、「データ取得(select)」も次いできます。結局、業務要素が多いからうまく纏められないでしょう。
方法1は技術要素のみですから、コントロールしやすいです。以下のURLは、自分が経験したチャートモジュールの設計製造です。データと設定情報は全部テーブルタグから受け取ることでデータ通信は全部業務アプリに任します。まったく方法1そのものですね。
https://github.com/efwGrp/efw4.X/blob/master/help/tag.chart.md

0Like

API通信してデータ処理するライブラリを作る手もありますね。
私が作ったコンポーネントではそうしました。

0Like

Your answer might help someone💌