MVVMに基づいて通知コンポーネントを作成したいのですが、すべてのデータはjsonになります。一覧ページにはフィルタリング機能や検索機能があります。通知の詳細により、前の通知が表示され、次の通知に切り替わります。
フィルタリング条件や検索条件がない場合は、詳細ページでグローバルの前の項目と次の項目を直接切り替えることができ、フィルタ条件または検索条件がある場合は、前の項目と次の項目を切り替えることができることを期待します。検索結果リスト。
これは私が自分で考えた計画です。
コンポーネント全体が初期化されると、このユーザーの下にあるすべての通知 (ID) がローカルに取得され、グローバルに記録されます [store.list.all]。その後、詳細ページがクリックされると、フロントエンドはクリックされるアイテムの ID を取得します。 ajax リクエストをパラメーターとして使用すると、詳細ページに現在の通知 ID とすべての通知 ID のリストが表示されます。このようにして、詳細ページでは、前のアイテムの ID と次のアイテムの ID を簡単に知ることができます。
フィルタリングまたは検索条件がある場合、グローバル [store.list.filter] を忘れないでください。方法は上記と同じです。
利点: 前と次の項目の実装が非常に簡単になり、リスト ページをめくるたびにデータをリクエストする必要がなくなります。
短所: このユーザーの通知リストが非常に長い場合、初期化と検索中に、[store.list] にリクエストして記録する必要があるデータが非常に大きくなり、ホームページが非常に遅くなる可能性があります。パフォーマンスは悪くなります。
会社の以前の製品のプロジェクト。
リスト ページでページング クエリを実行するには、各リクエストで page+row をパラメーターとして使用し、クエリは行アイテムのページをクエリすることによって実行されます (たとえば、page=3、row=10、つまりアイテム 31 ～ 40 をクエリすることを意味します) ）。フィルタリングと検索機能は同じです。
以前の製品では、前の項目と次の項目の切り替えが実装されていませんでした。
しかし、この考えに従い続けると、おそらく次のようになります:
フィルターされていない検索条件の下で、現在の ID をパラメータとして送信し、次または前のパラメータを持ってくるので、select * from foo where id = (select min(id) from foo where id > 4)このメソッドを利用して次のことを行うことができます。データベースにクエリを実行します。
フィルタリングされた検索条件では、これはかなり嫌なものでした。おそらく、リスト ページから詳細ページをクリックしたときに検索ステータスを保存しました (これは実行できます。戻るボタンを押すとこのステータスが保存されます)。 ) を実行し、前の項目または次の項目に移動する場合、クエリには id と next に加えて検索条件も含まれます。 Ajax リクエスト API を書くのはうんざりするだけです。
利点: リストページはページ分割されており、ユーザーは通知の数を気にする必要はありません。
デメリット: リストページをめくるとリクエストやクエリが必要になり、クエリ条件が複雑になり、詳細ページのネクストホップに対するajaxリクエストを書くのが難しくなります。
現時点では 2 つのアイデアしかなく、それぞれに長所と短所があります。
他に何かアイデアはありますか？
MVVMに基づいて通知コンポーネントを作成したいのですが、すべてのデータはjsonになります。一覧ページにはフィルタリング機能や検索機能があります。通知の詳細により、前の通知が表示され、次の通知に切り替わります。
フィルタリング条件や検索条件がない場合は、詳細ページでグローバルの前の項目と次の項目を直接切り替えることができ、フィルタ条件または検索条件がある場合は、前の項目と次の項目を切り替えることができることを期待します。検索結果リスト。
これは私が自分で考えた計画です。
コンポーネント全体が初期化されると、このユーザーのすべての通知 (ID) がローカルに取得され、グローバルに記録されます [store.list.all]。その後、詳細ページをクリックすると、フロントエンドがアイテムの ID を取得します。 ajax リクエストをパラメータとしてクリックすると、詳細ページに現在の通知 ID とすべての通知 ID のリストが表示されます。このようにして、詳細ページでは、前のアイテムの ID と次のアイテムの ID を簡単に知ることができます。
フィルタリングまたは検索条件がある場合、グローバル [store.list.filter] を忘れないでください。方法は上記と同じです。
利点: 前と次の項目の実装が非常に簡単になり、リスト ページをめくるたびにデータをリクエストする必要がなくなります。
短所: ユーザーの通知リストが非常に長い場合、初期化と検索中に [store.list] にリクエストして記録する必要があるデータが非常に大きくなり、ホームページが非常に遅くなる可能性があり、パフォーマンスが低下する可能性があります。もっと悪くなります。
会社の以前の製品のプロジェクト。
リスト ページでページング クエリを実行するには、各リクエストのパラメーターとして page+row を使用し、行アイテムのページをクエリします (たとえば、page=3、row=10、つまりアイテム 31 ～ 40 をクエリすることを意味します)。フィルタリングと検索機能は同じです。
以前の製品では、前の項目と次の項目の切り替えは実装されていませんでした。
ただし、この考えを続けると、おそらく次のようになります:
フィルターされていない検索条件の下で、現在の ID をパラメータとして送信し、次または前のパラメータを持ってくるので、select * from foo where id = (select min(id) from foo where id > 4)このメソッドを利用して次のことを行うことができます。データベースにクエリを実行します。
フィルターされた検索条件では、これはかなりうんざりします。リスト ページから詳細ページをクリックしたときに検索ステータスを保存したいと思います (これは実行できます。戻るボタンで保存されます)。このステータス) を取得し、前の項目または次の項目に移動するときに、id と次の項目に加えて、検索条件もクエリに含まれます。 Ajax リクエスト API を書くのはうんざりするだけです。
利点: リストページはページ分割されており、ユーザーは通知の数を気にする必要はありません。
デメリット: リストページをめくるとリクエストやクエリが必要になり、クエリ条件が複雑になり、詳細ページのネクストホップに対するajaxリクエストを書くのが難しくなります。
現時点では 2 つのアイデアしかなく、それぞれに長所と短所があります。
他に何かアイデアはありますか？
オプション 1 の致命的な打撃: ユーザーが 100,000 件の通知を使用した場合。
オプション 2 の致命的な打撃: クエリ条件の複雑さが継続的に増加すると、ストレージの負荷が増大します。
======
中程度のソリューション
一度に N 日分のデータを読み取ります (N 日分のデータ量が基本的に制御可能である場合、そうでない場合、このソリューションは実装されません)。
信頼できるソリューション
Elasticsearch を使用する
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
