シングルページアプリケーションのエクスペリエンスに関する質問

---コンテンツの復元が開始---

##シングルページ アプリケーションとは何ですか? いわゆるシングルページ アプリケーションとは、システム全体でも 1 ページ (1 つの HTML) しかなく、すべてのビジネス機能が 1 つのページに統合されているものを指します。 -モジュール。 特定の方法でメインインターフェイスに接続します。

##なぜ単一ページのアプリケーションがあるのでしょうか? Ajax テクノロジーの出現の理由の 1 つは、Web ページにアクセスしたユーザーがページを更新せずにページ上のデータの変更を確認できるようにするためであることがわかっています。 ajax によってエクスペリエンスが向上すると言えます。

インターネットの発展に伴い、ブラウザーによって提供されるサービスはますます複雑になり、Web フロントエンドはもはや単純なページ、つまり ajax で部分的に更新できるガジェットではありません。数十のサブページを備えたアプリケーションは、市場のどこにでも見つかります。これらのサブページは多くの共有リソース (静的および動的) を共有しているため、それらのリソースを繰り返し読み込むことを避けたい場合は、それらのリソースを 1 つの HTML に入れるという明白な方法があります。

つまり、これは ajax テクノロジーをさらに昇華させたもので、ajax のリフレッシュフリーのメカニズムを極限まで高めたもので、デスクトップ プログラムに匹敵するスムーズなユーザー エクスペリエンスを生み出すことができます。

##シングルページ アプリケーションによって引き起こされる問題
HTML に 12 ～ 20 個のサブページ プログラムを配置する場合、カットアンドペーストでは解決できないことはわかっています。もともと無関係なプログラムをまとめた結果が、プログラミングの世界の質量エネルギー方程式です。 エラー = (その他のコード)^2

##シングルページ アプリケーションのエクスペリエンス
本題の操作エクスペリエンスを向上させる方法に戻ります。単一ページのアプリケーションをできるだけ多くするか?

次に、

1. ページの初期読み込み速度
2. ページデータの正確性 (特に異常なネットワーク条件下)
を含む、ユーザー エクスペリエンスに影響を与えるものを見てみましょう。
--
実際、最初の 2 つの点については多くの記事で詳しく説明されていますが、ここではできるだけ簡単に言及し、3 番目の点に焦点を当てます。

####初期ページ読み込み速度
- 静的リソースのオンデマンド読み込み (適切なモジュール化を前提として、webpack や systemjs などのモジュール バンドラー ツールを使用)
- 動的リソースのオンデマンド取得 (フロントが必要)エンドデータ層) 優れたアーキテクチャ)
- サーバー側レンダリング (ページ読み込みプロセス中に、フロントエンドがデータを「取得」してページを「生成」し、サーバー側で完了します。最初の画面が表示されるアプリケーションには適していません)複雑すぎます)

### #対話型応答
- 速度: バックエンド要求、フロントエンド キャッシュ、およびその後の同期によって返されるデータ。同じデータに対する繰り返しのリクエストを避けてください。
- 例外処理: 現在、モバイル オフィスが人気です。ネットワークの状態が良くないときに、ユーザーに十分な待ち時間を与えたり、UI にプロンプ​​トを表示したりする方法は、過小評価できません

####ページ データの正確さ
さらに話したいこと はい、私たちは実際に多くの問題に遭遇し、いくつかの解決策を試してきました。

これをうまくやりたいなら、次の言葉が必要だと個人的に思います: **「適切なキャッシュ管理」**、ここでのキャッシュはフロントエンド キャッシュ モデルを指します。

これらのいくつかの単語だけを見ないでください。それは非常に難しいです。なぜ？

#### まずメモリのソースについて話しましょう。次のタイプがあります:

- ブラウザキャッシュ (indexDB、localStorage など)
- http リクエスト
- webSocket プッシュ

異なるソースが同じデータに影響を与える適切な抽象化により、ビジネス層がデータ ソースの認識を保護できるようになります。この問題を解決するために広く使用されている既存のライブラリには、RxJ、CycleJS などが含まれます。MVI の概念も、すべてこの目的のために以前に提案されました。

#### 記憶の変化について話しましょう

言うまでもなく、ここで紹介する異常状態はほんの数種類です。

#####httpリクエストが失敗しました

ここで**「操作補償」**という言葉について言及する必要があります

操作補償とは何ですか?

論理的に言えば、インターフェースを操作してタスクを作成するとき、新しいタスクはすぐに表示されるべきではなく、サーバーが成功を確認するまで待ってからインターフェースに追加する必要があります。ただし、ネットワークが良好ではない可能性が非常に高く、ユーザーはこのステップで長時間待たなければなりません。ユーザー エクスペリエンスの観点からすると、これは良くないので、最初にインターフェイスを作成し、作成が成功したというメッセージが返された後に、いくつかの一意の識別子などをメモリ データに埋め戻すことができます。

単一ステップの操作の補正はそれほど難しくありません。たとえば、ユーザーが新しいタスクを追加しても、サーバーがすぐにサブタスクを作成しない場合、非常に面倒になります。このタスクの下にありますが、この時点ではサブタスクには親タスクの ID がありません。この手順を補う必要がある場合は、さらに面倒になります。いくつかの連続した操作を行った後に、前の操作が失敗していたことがわかり、その後の処理が非常に複雑になるということさえあります。

当社の製品でもこの問題が発生します。私たちのアプローチは、**「妥協」**、重要なデータについては 1 段階補正または 2 段階補正を行うことです。フロントエンドモデルの依存関係が複雑で上位モデルの書き込み操作が失敗した場合、または補正の手順が多すぎる場合は、事前にユーザーに通知され、UI上でユーザーのインタラクション入口がロックされます。後続の書き込み操作は避けてください。

ここで引き続き実行する場合も、操作の結果はクライアント上でローカルに記録され、その後、データがバックグラウンドで同期されます。 。


#####切断と再接続

ネットワークのジッター、ネットワークの切り替え、コンピューターの休止状態と再起動などにより、ユーザーが再びインターネットに接続するときに、アプリケーションはより複雑なネットワーク状況に直面する必要があります。再リンクに進みます。

現時点では、理想的な単一ページ アプリケーションは、再接続時に、以前のすべてのイベントの最終結果、つまり最新のステータスを同期して戻します。

私たちのアプリケーションは共同ビジネスです。同じ企業内のユーザーが同じモデルを共有し、webSocket を通じて同期して、モデルの即時性と正確性を確保します。したがって、これは私たちにとって大きな挑戦でもあります。私たちの解決策は、webSocket を再送信することです。

#####ホットアップデート

前述したように、ユーザーはアプリケーションを開いたまま長時間放置し、途中で更新しない可能性があります。通常の状況では、すべてのビジネス変更は延期される必要があり、インターフェイスによってフィードバックされるステータスは常に最新であり、現在の状況と一致しています。しかし、別の問題を考慮する必要があります。システムのアップグレードについてはどうでしょうか?

もちろん、通知をプッシュすることもできます: このシステムはアップグレードされました。更新をクリックしてください。しかし、もっと良くできるでしょうか？この目標を達成するには、ホット アップデートを使用して、コードの究極のモジュール化と変更管理を達成する必要があります。更新された各コード モジュールも、システム上の現在のコードにプッシュされ、適用されます。このメカニズムには、開発チームの高い基準が必要です。

#####最後に
「単一ページの製品の技術レベルをどのように判断するか?」という格言を聞いたことがあります。
数日間オンにしても、アプリケーションは正常に、正しく、スムーズに使用できます。

シングルページの申請書を作ったことのある学生ならこの意味が分かると思います。

##まとめ

たくさんお話しましたが、まとめさせていただきます。シングルページアプリケーションのエクスペリエンスを改善するためのいくつかの問題点と方法について述べてきましたが、実装されればユーザーは間違いなく非常に満足しますが、理想と現実のギャップを冷静に検討する必要があります。私たちがやっていることはソフトウェアエンジニアリングなので、美学を適切に放棄し、限られた人間のエネルギーを要所要所に投資する必要があります。

---リカバリコンテンツの終了---

以上がシングルページアプリケーションのエクスペリエンスに関する質問の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。