テーブルコンポーネントのカプセル化ロジック:
Table コンポーネントの一般的な JS ロジックをコンポーネント内にカプセル化して、ロジックの再利用を実現します。
一部のインターフェイス (プロパティ) を外部に公開し、そのインターフェイスを介してデータまたはメソッドをコンポーネントに渡して、テーブル コンポーネントのレンダリングと機能を動的に制御し、コンポーネントの柔軟性と構成可能性を確保します。
テーブル列の構成は独立したモジュールにカプセル化され、テーブル コンポーネントで使用できるようにエクスポートされるため、コードの可読性と保守性が向上します。
ネットワークリクエスト:
- プロジェクト内のネットワーク リクエストを管理するにはどうすればよいですか?
リクエストの二次カプセル化: リクエスト タイムアウト、ベース URL、リクエスト インターセプタの設定、レスポンス インターセプタの設定をグローバルに設定します。
モジュールごとにリクエストを管理: js ファイルは機能モジュールの複数のリクエストを管理し、各リクエストは独立した関数にカプセル化され、コンポーネント呼び出し用にエクスポートされます。
- プロジェクト内のクロスドメインリクエストを解決するにはどうすればよいですか?
開発環境の場合: プロキシ proxy を使用します。
運用環境: バックエンド構成により、クロスドメイン アクセスまたはバックエンド nginx 構成プロキシが可能になります。
ビジネス機能:
- ログイン方法?ログインのロジックは何ですか?
- 初めてログインするとき、フロントエンド (クライアント) はバックエンド (サーバー) のログイン インターフェイスを呼び出し、ユーザー名とパスワードを送信します。
- バックエンド (サーバー) は (クライアント) リクエストを受信し、ユーザー名とパスワードを検証し、検証が成功した場合はフロントエンド (クライアント) にトークンを返します。
- フロントエンド (クライアント) はトークンを取得し、トークンを localStorage または vuex に保存し、ルーティング ページにジャンプします。
- フロントエンド(クライアント)はルートにジャンプするたびに、localStroageにトークンがあるかどうかを判断し、トークンがない場合はログインページにジャンプし、トークンがある場合は対応するルーティングページにジャンプします。
- フロントエンド (クライアント) がコンポーネント内のバックエンド (サーバー) インターフェイスを呼び出すたびに、リクエスト ヘッダーにトークンを追加する必要があります。
- バックエンド(サーバー)はリクエストヘッダーにトークンがあるかどうかを判断し、トークンがあればトークンを取得して検証し、検証が成功した場合はデータを返します。検証が失敗した場合(例: : トークンの有効期限が切れた場合)、401 が返されます。リクエスト ヘッダーにトークンがない場合は、401 が返されます。
- フロントエンド(クライアント)がステータスコード401を取得した場合、トークン情報をクリアしてログインページにジャンプします
- 権限管理の実装思想とは? ルートレベルの権限? ボタンレベルの権限?
フロントエンド権限管理の重要性:
- 不正操作の可能性を低減する
- 不要なリクエストを可能な限り排除してサーバーへの負荷を軽減します。
- ユーザーエクスペリエンスの向上
フロントエンド権限制御の考え方:
- メニュー制御: ログイン要求で権限データが取得されます。権限は複数のコンポーネント間で共有する必要があるため、データは vuex 経由で保存され、対応するメニューが表示されます。ページが更新されると、データが表示されます。失われるため、権限データは永続化されたストレージになります。
- インターフェイス制御: ユーザーがログインせずに URL アドレスを手動で入力した場合、そのアドレスはブロックされ、ログイン ページにリダイレクトされる必要があります。これは、ルーティング ナビゲーション ガードによって実現できます。動的ルーティングでは、権限のないインターフェイスがルーティング ルールに存在しないようにできます。
- ボタン コントロール: メタデータをルーティング ルールに追加でき、現在のルーティング ルールとルーティング ルールに保存されているメタデータはルーティング オブジェクトを通じて取得でき、カスタム命令でボタンのコントロールを実現できます。
- リクエストとレスポンスの制御: リクエスト インターセプトとレスポンス インターセプトの使用。401 タイプのリクエストの場合、一律にログイン ページにジャンプし、リクエスト メソッドは RESTful に同意します。
- シングル サインオン (SSO) を実装するにはどうすればよいですか?
シングル サインオン、SSO 英語のフルネーム Single Sign On。
複数のアプリケーション システムでは、相互に信頼されている他のアプリケーション サブシステムにアクセスするために一度ログインするだけで済みます。
Web サーバーがログイン ユーザーを認証するには 2 つの方法があります。
セッションクッキーに基づく
HTTP はステートレス プロトコルです。一部のアプリケーション シナリオでは、ログイン ユーザーのステータスを知る必要があるため、セッション メカニズムが使用されます。ユーザーのセッション情報はアプリケーションサーバーに保存され、セッション情報の一部(セッションID、セッションIDなど)はクライアントブラウザのCookieに保存されます。その後のサーバーとの通信では、ブラウザーが関連情報を伝達し、サーバーは保存されたセッション情報を照会することでユーザーのログイン ステータスを取得できます。
トークンベース
通常、JWT (JSON Web Token) と呼ばれるトークンは、JSON 形式で保存されたユーザー ID と関連情報であり、サーバー側でキーによって署名された後、base64 を使用して文字列にエンコードされます。JWT はサーバーによって署名されているため、クライアントはそれを検証することのみができ、変更することはできません。サーバーはユーザーを認証した後、トークンをクライアントに送信します。クライアントがサーバーと通信するとき、メッセージ ヘッダーにベアラー認証を含むトークンが含まれ、サーバーはそれを受信した後に検証します。Cookie ベースのセッション管理とは異なり、トークンはステートレスであり、サーバー自体はユーザーの状態を保存しません。トークンの自己完結型 ID 情報プロパティにより、そのアプリケーションがより柔軟になり、拡張が容易になります。
- ページにアクセスすると突然ログイン期限が切れてログインページに飛んでしまうのですが、ログイン成功後に前のページに飛ぶにはどうすればよいですか?
- アドレスがログイン ページにリダイレクトされる場合は、パラメータを使用してリダイレクト前にページ アドレスを保存します。例: redirect
- ログイン ページで、まず保存されたリダイレクト パスを取得します。
- ログイン成功後、リダイレクトアドレスの有無を判定し、存在する場合はリダイレクトアドレスにジャンプします。
パフォーマンスの最適化:
- プロジェクトのどこが最適化されていますか? コードの再利用、パフォーマンス、アクセス速度。
- v-if と v-show は使用シナリオを区別します。
(v-if は実際の条件付きレンダリングで、切り替えプロセス中に破棄されて再構築されます。v-show は CSS の表示属性切り替えに相当します)
-
- 使用シナリオを計算して監視します。
(Computed は計算された属性です。依存属性の値が変更された場合、次回 computed の値が取得されたときにその値が再計算されます。Watch はむしろ観察に重点を置いています。)
-
- ロングリストのパフォーマンス最適化:
コンポーネントが純粋なデータ表示である場合もありますが、変更はないため、Vue がデータをハイジャックする必要はありません。オブジェクトは Object.freeze メソッドで凍結できます。オブジェクトが凍結されると、変更されなくなります。
-
- イベントの破壊:
Vue コンポーネントが破棄されると、他のインスタンスとの接続が自動的にクリーンアップされますが、コンポーネント自体のイベントのみがクリーンアップされます。addEventListense などのメソッドが JS で使用されている場合、それらは自動的には破棄されません。手動で削除する必要があります。コンポーネント内のこれらのイベントのリスナーは、メモリ リークを回避します。
-
- 画像リソースの遅延読み込み:
画像が多すぎるページの場合、ページの読み込みを高速化するために、ページが表示される領域までスクロールされるまで待ってから読み込みます。プロジェクトで vue-lazyload を使用できます。次に、vue ファイル内の img タグの src を v-lazy に変更し、画像の表示モードを遅延読み込み表示に変更します。
-
- ルーティングの遅延読み込み ((3. Routing Vuex) で実装):
Vue はシングルページアプリケーションであり、多くのルートがインポートされるため、Webpack パッケージ化後のファイルは非常に大きくなりますが、ロードされるリソースが多すぎるとページが白画面になるため、異なるルートに対応するコンポーネントを分割することができます異なるコード ブロックに分割すると、ルートにアクセスすると、対応するコンポーネントがロードされます。
-
- サードパーティのプラグインはオンデマンドで導入されます。
babel-plugin-component の助けを借りて。プロジェクトのサイズを縮小するという目的を達成するために、必要なコンポーネントをオンデマンドで導入します。
-
- 無限リストのパフォーマンスを最適化します。
非常に長いリストや無限にスクロールするリストがある場合は、ウィンドウ処理テクノロジを使用してパフォーマンスを最適化する必要があります。これにより、領域のごく一部のコンテンツをレンダリングするだけで済み、コンポーネントの再レンダリングと dom ノードの作成にかかる時間が短縮されます。
-
- サーバーサイドレンダリング SSR/プリレンダリング:
より良いSEO
コンテンツの到着までの時間の短縮 (フォールド前の読み込みが高速化)