在《フロントエンドエンジニアのキャリアにおける 3 つの問題》という記事で、「ツール」の重要性が言及されました。今日は、昨年開発した実際に仕事で使用されているブラウザプラグインを例に、これに関する具体的な実践を簡単に説明します。
1. 背景#
仕事の場面において、報告書は一般的なビジネス形態の一つです。上司は報告書を通じて会社の経営状態を把握し、財務は報告書を通じて収支の詳細を把握し、製品運営は報告書を通じてユーザーデータを理解します。抽象的な観点から見ると、さまざまな報告書はデータと表示形式の組み合わせの産物です。その中で、
| 概念 | 説明 |
|---|---|
| データ | その名の通り、バックエンドから返される構造化データ |
| 表示形式 | データの種類や報告書の目的に応じて、一般的な表、円グラフ、折れ線グラフ、棒グラフなどの形式で差別化される必要があります |
つまり：
以下の図のように：
実装の観点から見ると、クライアントはユーザーがインターフェースで設定したフィルタ条件を特定のクエリ文にフォーマットし、バックエンドに具体的なデータ処理を依頼します。データがクライアントに返された後、クライアントは構造化データを表示の必要に応じて特定のフォーマットに整形し、ユーザーの前に表示します。
クライアント側では、技術モデルはそれほど複雑ではありません。クライアントが直面する複雑さは以下から来ています：
- 一般的なビジネスプロセスモデルをどのように抽象化するか
- 報告書の種類が多岐にわたるため、ページ数が膨大になる
- フロントエンドとバックエンドのインタラクションで伝送されるデータが多く、形式が異なり、データ処理のプロセスが個別化されている
数量が増えると、例えば 100 以上の報告書があり、時間の経過とともに人員が交代する中で、現在のメンテナンス担当者はしばしばフロントエンドとバックエンドのデータ交換プロトコルの詳細やフォーマットルールを把握していないことが多く、これはフロントエンドページの後期メンテナンスコストにとって急激に上昇する要因となります。パラメータの渡し方や取得値のタイプのエラーを調査するために、多くの人力コストがかかりました。したがって、もしツールがあれば、フロントエンドがバックエンドに送信するデータや、ページがレンダリングされる際に取得する値を一目で確認できることで、問題の調査コストをある程度削減できるでしょう。
2. 目標#
現在直面している問題を明確にした後、次のステップは具体的な目標を設定することです。上記の小さな問題について、目標は非常に明確です：開発者が現在の報告書の具体的なリクエストパラメータとレンダリング取得値を迅速に確認できるツールまたはプラットフォームを提供すること
3. 方案#
まず最初に思いつくのは、ページコンポーネントに特定の識別子を侵入的に追加するか、何らかの合意に基づいて命名し、その後外部で対応する情報を読み取ることです。しかし、この方法は侵入性が強すぎて、バグが頻発するビジネスページや脆弱な開発者にとっては、まさに雪上に霜を加えることになります。したがって、コードの侵入なしが方案の最初の前提となりました。
Reactを使用している方は、React Devtoolsに精通しているはずです。Componentパネルでは、ページのコンポーネント階層と各コンポーネントに対応するpropsを明確に見ることができます。これがインスピレーションの源です。DOMとReact Componentの間には何らかの接続が存在し、DOMからComponent、そしてComponentからDOMへのマッピングができるはずです。もしComponentを取得できれば、コンポーネントに関するすべての情報を取得できることになります。そして、コードの侵入はありません。
その後、React のソースコードで、ランダムな文字列を生成してkeyを作成する操作を見つけました。コンソールを開くと、確かにこのマッピング関係を見つけました。
上の図のように、各React DOM要素には__react（ReactDOMのバージョンによって異なる）で始まる属性が含まれており、そこには現在のDOMのVirtualDOM、すなわちFiberNode情報が格納されています。FiberNodeの定義に基づくと、memoizedPropsには現在の要素をレンダリングするために使用されるpropsが格納されています。
このマッピング関係があれば、外側ではビジネスやReactの処理プロセスを気にする必要はなく、最終的に生成されたDOMの結果にのみ注目すればよいのです。結果の正誤が私たちが最も関心を持つ問題だからです。そして、残りのことは具体的なビジネスシーンを処理することになります。
例えば：
- 最終的には無侵入を実現するために、ブラウザ拡張を通じて実現しますが、ブラウザ拡張はページとは異なる実行環境にあり、
DOM属性を読み取ることができません。この場合、拡張を通じてページにJSスクリプトを注入し、イベントメカニズムを通じてデータを伝達することを選択します。 Reactの異なるバージョンで若干の違いがある処理- テーブルヘッダーを取得する際、ヘッダーがネストされたグループになっているため、ヘッダーのネスト問題を処理する必要があります。
- 実行タイミングの問題、データが変化するたびに
React Componentの最新インスタンスを再取得して最新の値を取得する必要があります。ページ内でデータの変化を引き起こすのはリクエストであるため、拡張内でネットワークリクエストを監視し、データの同期を実現します。
最終的な効果は以下の通りです：
ここでは具体的な思考を説明しました。このような思考と具体的な実践があったことで、この思考は現在主導している自動化テストにも応用されています。後日、時間があればさらに詳しくお話しします。