2 年前、私は alovajs という JavaScript リクエスト戦略ライブラリを設計、開発しました。 2023 年 4 月のプロモーション以来、世界中の開発者から高く評価され、大手企業の専門家からの評価を含む 2700 以上の星を獲得しています。
現在、alova@3.x がリリースされており、「ワークフローを効率化する次世代リクエストツール」と位置付けられています。
30ヶ月間無償保守を続けており、バージョンは3.xになりました。この間、反省、拒絶、再考を繰り返しながら、他のリクエストツールができていないことを実現し、真にフロントエンド開発を支援できるツールを目指しました。確実な方向性を見つけられたと思います。
つまり、API 統合プロセスの合理化においてフロントエンド開発を最大限に支援する、「ワークフローを合理化する次世代リクエスト ツール」を作成することです。
以下は alovajs の探索ストーリーであり、オープンソース プロジェクトの開始当初からのストーリーでもあります。
alovajs に興味がある場合は、コミュニティに参加して一緒に進歩することを心からお勧めします。
2022年3月のある日、とある事情から「目標のコン」というアプリを開発することを思いつきました。いくつかのアプリに触発されて、私は「目標の目標」が、ネットワークが弱い、またはネットワークがない状況でも、遅延のないデータ要求と送信、つまり即時応答モードを実現できることを期待しました。しかし、オンラインで検索しても適切なソリューションが見つからず、同様の楽観的な更新ソリューションもニーズを満たしていなかったため、共有したいという私の強い欲求に駆られ、リクエスト ライブラリの形式で実装することにしました。これが alovajs の出発点でした。しかし、当時は名前がありませんでした。
ライブラリの始まりは設計でも開発でもなく、ニーズを明確にすることです
プロ向けのヒント: 以下の内容をよりよく理解するために、最初に alovajs の概要セクションを簡単に理解することを強くお勧めします。
当時は製品の位置付けはなく、自分のニーズを満たす JavaScript ライブラリを作成するだけでした。既存のリクエスト ライブラリを調査し、次のニーズをリストしました:
その後、ニーズに基づいてライブラリの API が設計されました。
ニーズ 2 では、useRequest、useWatcher、useFetcher の 3 つのコア useHook が設計されました。 ahooksのuseRequest、vueuseのuseAsyncState、react-query、swrなどおなじみの機能で、言うまでもなく非常に便利です。
useHook 設計を使用しているため、フレームワークごとに状態管理が異なりますが、react-query のようにフレームワークごとに JavaScript ライブラリを作成したくありません。そこで、ニーズ3については、stateHookアダプタ、リクエストアダプタ、ストレージアダプタの仕様を設計し、その仕様に応じて異なるアダプタを記述し、フレームワーク環境とランタイム環境関連のロジックを別モジュールに分離しました。
ニーズ 4 では、メソッド インスタンス プロキシ パターンが設計されており、メソッド インスタンス プロキシが異なるアダプターのフック関数を呼び出すため、どのようなアプリケーションを開発する場合でも、慣れ親しむことなく alovajs を始めることができます。シームレスに移植することもできます。
ニーズ 5 の場合、同様の JavaScript ライブラリはカスタム キーの形式でキャッシュを実装しますが、私の考えはリクエスト情報に焦点を当てることです。よくあるシナリオは、同じリクエストメソッドとパラメータで同じインターフェースをリクエストする場合、前回のレスポンスデータをヒットする必要があるということです。これらのリクエスト情報をキャッシュキーとして使用してはどうでしょうか?したがって、alovajs は、GET リクエストでデフォルトで有効になる自動キャッシュ メカニズムを設計しました。
ニーズ 6 については、axios を参照して学習してください。
これらのデザインは、時間の経過とともに実際に証明されています。 alovajs は、アダプター方式により Vue、React、Svelte フレームワークと完全互換であり、一貫した使用方法を維持しながら、ブラウザ、React Native、UniApp、Taro などのさまざまな JavaScript 環境でも動作するため、一瞥しました。希望します。
その後数か月間、alovajs がリリースされましたが、プロモーションは行われていませんでした。一方で、それは「ゴールのコン」プロジェクトで使用したためです。今回のプロジェクトでは鍛え上げられ改良されてきましたが、まだまだ不完全で、位置づけも明確ではありません。初期バージョンの紹介はこんな感じです
その後、「ゴールのコン」プロジェクトは中止されましたが、alovajs はまだ存続しています。
私はかつてインターネット プロダクト マネージャーだったという執念を持って、alovajs を差別化された製品にしたいと今でも願っています。私はよく自問しますが、alovajs と他のリクエスト ライブラリの違いは何でしょうか?なぜユーザーはalovajsを使用する必要があるのでしょうか?確かに他のライブラリとは設計が異なりますが、すぐに答えられる質問ではありません。その後、私はリクエスト ライブラリの方向性を「軽量リクエスト ライブラリ」と「マルチエンド統合リクエスト ライブラリ」と位置付けようとしましたが、これらは開発者に実質的な支援をもたらせず、また、開発者に実質的な支援をもたらさないため、いずれも私自身によって否定されました。利点と呼ばれます。
2022 年 9 月、あるきっかけで、Vue をベースにした優れたリクエスト ライブラリである vue-request を知りました。 usePagination と useLoadMore にすぐにインスピレーションを受けました。この形式のページネーションの実装は、これが私が望んでいることでもあることに気づきました。同時にuseHookの威力を実感しました。リクエストのシナリオに応じてモジュールを分割し、シナリオごとに異なる useHook を使用できます。以前に実装されたシームレスなデータ対話も実際にはシナリオの 1 つです。この方向であれば、開発者はさまざまなリクエスト シナリオに応じてさまざまな useHook を選択できます。これにより、開発効率が向上し、コーディングの複雑さが軽減されるだけでなく、ジュニア フロントエンドが非効率的なコードを作成するのを防ぎ、コア機能をより有効に活用できます。 alovajs を使用すると、パフォーマンスが向上し、サーバーの負荷が軽減されます。リクエスト機能では、これまでのところ、「軽量リクエスト戦略ライブラリ」を私が選択しました。
次に、alovajs の将来の設計方向を導くために、alovajs のリクエスト シナリオ モデル (RSM) を洗練および抽象化し、主に次の 4 つのプロセスに分けました。
Request timing -> Request behavior -> Request event -> Response processing
やってみよう、この位置付けに従ってalovajs 2.0の再構築を開始し、シームレスなデータインタラクション機能を1.0から分離し、より多くのリクエストシナリオ戦略useHooksの開発に適応するミドルウェア機構を設計しました。ページネーション戦略とシームレスなデータ対話戦略を研究し、開発しました。
alovajs のページネーション戦略は、Pagination の使用が最も便利だと思います。 alovajs のキャッシュ機能を使用して、表裏ページ データのプリロード、ページネーション データ検索、リクエスト レベルのデバウンスを実現し、新しい編集機能と削除機能の自動管理を提供するだけでなく、指定されたページ コードのデータを更新します。リセットせずに。
シームレスなデータ インタラクション戦略には 4 か月かかり、常に行き詰まりに遭遇し、結果を常に再設計しました。脆弱なネットワーク環境や切断されたネットワーク環境でも、ユーザーが遅延なくデータを操作できる戦略を実現し、リクエストの成功をより安定して保証することもできます。私は、応答前に応答データのプレースホルダーとして使用できる仮想データを設計して、ユーザーに即時の応答であると感じさせ、応答が成功した後に仮想データを実際のデータに置き換えることができます。現在の調査結果によると、その使用シナリオは、エディターのようなアプリケーション、システム設定モジュール、およびいくつかのより単純なリストである可能性があります。
その後、useForm、useAutoRequest、useSSE などのリクエスト戦略モジュールも追加されましたが、これでは十分ではありません。
2023 年 5 月 13 日に、github でこのような問題を受け取りました
最初はこの問題にはあまり注目せず、openAPIのリクエストコードを自動生成する機能を単純に理解し、とても良いと思っていましたが、エネルギーが限られていたため、深く考えていませんでした。その時はまだalovajsの方向性については考えていませんでした。しかし最近、alovajs の方向性について時折考えることがあり、まだ未解決のこの問題が常に頭に浮かび、この問題のラベルを "feature-request" から "feature-request:confirmed" に静かに変更しました。 .
同時に、この問題は、alovajs がフロントエンドとバックエンド間のコラボレーションの距離を狭め、フロントエンドの開発ワークフローをさらに簡素化できることにも気づきました。これは私が alovajs 3.0 に設定した開発の方向性です:
alovajs は、開発者が API 統合ワークフローを最大限に簡素化するのに役立ちます。使用する API を指定するだけで済みます (これも 3 か月間考えた結果です)
私の具体的な計画は次のとおりです:
上図のステップ 1、2、3、4、6 は API コードを自動生成することで解決されますが、私たちの生成計画は、openapi-generator などのツールと比較してさらに進んだものになります。 js プロジェクトであろうと ts プロジェクトであろうと、完全な ts タイプ、完全な説明のリクエスト関数を自動的に生成します。導入する必要はありません。開発者は location.reload を直接呼び出すのと同じくらい便利に呼び出すことができ、リクエスト関数は直接参照できます。完全な説明とリクエストパラメータタイプのプロンプトが表示されます。
自動生成されたリクエスト関数には完全な説明と入力プロンプトがあるため、vscode プラグインは必要な API を迅速に取得する対話型の方法を完成させ、API ドキュメントを参照する必要はなくなりました。
フロントエンドとバックエンドのコラボレーションギャップの問題を解決し、インターフェイスの変更をフロントエンドに自動的に通知できます。プロジェクトの構築中に変更が見つかった場合、エラーがスローされて構築が停止されます。 ts プロジェクトの場合、コンパイル中にエラーもスローされ、変更レコードは vscode プラグインを通じて表示することもできます。
これは vscode 拡張機能のデモビデオです。
ステップ 6「複雑なリクエスト ロジックを作成する」を解決するにはどうすればよいですか?もちろん、高性能かつシーンベースの特徴を持つリクエスト戦略モジュールを使用するためであり、ユーザーは非常に少ないコードを使用してさまざまなシーンリクエスト機能を実装できます。
2024 年 3 月に alova@3.0 の開発計画が策定され、コアメンバー MeetinaXD とともにプロジェクトのほぼ全体を再構築するのに 4 か月かかり、多くの最適化が行われました。
基礎となるアーキテクチャが再設計され、一連のフックを Vue、React、Svelte、さらには Vue オプション スタイルで同時に使用できるようになりました。
サーバー側で利用可能な範囲が拡張されました。 Express、koa、nestjs などのサーバー側フレームワークで alova を使用でき、新しいサーバー側リクエスト戦略サーバーフックが追加されました。
alova@2.x の 10 個の構成が非推奨となり、9 個の設計が最適化されました。
さらに、3.0 の最も重要な部分である、コアメンバー czlin が担当する vscode プラグインも利用可能になり、当初設定した目標はほぼ達成されました。
これまでのところ、alova@3.0 はベータ期間を過ぎており、実稼働環境で安定して使用できます。
当時、批判を受けた記事「It's time to replace your axios」がホット検索にランクインしました。
発売されたばかりの頃は確かにそれほど良いものではありませんでしたが、どの製品も一夜にして完成するものではなく、完成するには時間が必要であることを私は知っています。
Apple 1 コンピューターには最初はケースすらありませんでした
Vue の開発過程は、継続的な探索と進歩のプロセスでもあります
私はこのような製品の取り組みにただただ感動しており、一つのことをやり続けることが成功への最も簡単な方法です。良い製品は数年間テストする必要があり、ましてや alovajs は誕生して 1 年半ほどしか経っておらず、一部の人からの問い合わせも 8 か月しかありません。この期間中、同社はより良いソリューションを模索し、一歩ずつ前進してきました。
alovajs は、最初に useRequest、useWatcher、useEffectWatcher、useManual、useController を含む useHook を設計しましたが、その後徐々に 3 つのコア フック (useRequest、useWatcher、useFetcher) のみに削減されました。
コミットアドレス
並列リクエストの設計では、Promise.all に似た形式を実装するか、onSuccess 関数へのバインディングの現在の形式を実装するかにかかわらず、いくつかのバージョンに絡み、前後に変更されてきました。以下はその年に放棄されたレスポンダーのデザイン。
コミットレコードが見つかりません
IndexedDB などの非同期キャッシュ スキームと互換性を持たせるために、最初はストレージ アダプターを非同期機能として設計しようとしましたが、一連の問題が発生するため、StorageConnector を介してイベント メカニズムを実装しようとしました。まだ完全ではありませんが、最終的には現在のカスタム localCache 非同期関数メカニズムになります。
コミットアドレス
alovajs をサポートし貢献してくれた友人にも感謝します。以下はいくつかのスクリーンショットであり、含まれていない投稿も多数あります。
そして、継続的にドキュメントの詳細を補足し、ベスト プラクティスを改善し、キャッシュ回復モードのキャッシュ バージョン計画を大胆に試し、alovajs に完全な ts 型プロンプトを提供するために、自動型推論を使用して、開発者は型を定義する手間がかかり、最適化やさまざまな UI フレームワークとの互換性などに多大な労力を費やしています。
そのうち、文書は2～3回大きく変更されました。最初の文書変更意見を提供してくれた @Orange Peel と、2 回目の文書変更意見を提供してくれた @Well に感謝します。そして、私たちの文書はこれほどの評判を得ました。
@green Tree は、alova の新しいアイデアを広げるのに役立ちました。
多くのことがもはや明確ではありませんが、npmjs の記録によると、146 のバージョンがリリースされていることがわかります。
github にはバグを上げている人もたくさんいて、私も初めて返信して修正しました。本当に感謝しています。すぐに問題を判断できない場合は、codesandbox 上でも再現し、このデモをユーザーとのコミュニケーションの架け橋として使用します。
読んでいただきありがとうございます?、たとえそれがどんなに困難であっても、道はまだ続く必要があります。
alovajs を認識した場合は、Github にアクセスしてスターを付けてください。
alova について理解したい場合は、公式 Web サイトにアクセスしてください。そこでは、このツールをよりよく理解して使用するのに役立つ、より詳細なドキュメントとサンプル コードが見つかります。
ご質問がある場合は、次のグループ チャットに参加して相談することも、github リポジトリにディスカッションを投稿することもできます。問題が発生した場合は、github の問題に送信してください。最速で解決します。
また、あなたの力の貢献も歓迎します。貢献ガイドにアクセスしてください。
以上が数か月にわたるオープンソース: 次世代リクエスト ツールのメンテナンス方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
